Carl Love

Carl Love

26488 Reputation

25 Badges

12 years, 268 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are answers submitted by Carl Love

Given any ordering method for the remaining numbers on the board, and always combining the two largest or smallest under that ordering, the following procedure will quickly do it:

Fold:= proc(F, Ord, S::list)
local H:= heap[new](Ord, S[]);
    while heap[size](H) > 1 do 
        heap[insert](F(heap[extract](H), heap[extract](H)), H)
    od;
    heap[extract](H)
end proc
:   
F:= (x,y)-> 2*(x+y):
S:= [$1..2012]:

#Always pick the smallest 2 on the board:
CodeTools:-Usage(Fold(F, `>`, S));
memory used=9.95MiB, alloc change=0 bytes, 
cpu time=125.00ms, real time=125.00ms, gc time=0ns

                           3824690176

#Always pick the largest 2 on the board:
CodeTools:-Usage(Fold(F, `<`, S));
memory used=14.05MiB, alloc change=0 bytes, 
cpu time=157.00ms, real time=154.00ms, gc time=0ns

1418347387677553313827317733274373678617112653618997135212777674
  45156292376960567975595418039524675996632392882224586249204388
  28179304345106762174341933572125246097295862244822305888580038
  32730960812621013120919610414498768312349924004282984603838560
  56831782756113528753265460383973338290176438801802249571096171
  90072202315894651966512360194115388181951500037005049331036358
  83526253873661443899326202202911140127193485603216130264869237
  36726405401250743309372911301588481095805522276395748222142610
  57027695712811438803469660157535887649849298471803461222298792
  49120720001817791639485679807485997324175761473538

#Choose two at random:
R:= rand(0..1):
CodeTools:-Usage(Fold(F, ()-> (R()=0), S));
memory used=12.05MiB, alloc change=0 bytes, 
cpu time=188.00ms, real time=176.00ms, gc time=0ns

                         1210322911272

 

If e is your expression, do 

eval(e, Units:-Unit= 1)

Change 
for tmp in op(THE_SUMS) do
to
for tmp in THE_SUMS do

What you've shown is not a bug. If M is a module, then using the statement for x in M do implies that has a ModuleIterator or has some form of indexing implemented. Thus, the thing after the in needs to be a list, set, or other indexable structure. If THE_SUMS is a 1-element list of modules, then op(THE_SUMS) is just a module, not a sequence of modules.

The problem has nothing to do with scoping, name spaces, or whether the code is in a worksheet or library. Your attempt at making a MWE worked because you used instead of op(L).

Like this:

solve(x^(1/x)=y, x);
subsindets(%, specfunc(LambertW), L-> LambertW(k, op(L))); 
Sol:= unapply(%, [k,y]):
Sol~([-1, 0], 1.2);

                 
 [14.76745838, 1.257734541]

The two functions are simple enough that Maple can solve your problems for arbitrary coefficents (this means using convert(..., FormalPowerSeries) rather than commands series or taylor). Note that sin(x)*cos(x) = sin(2*x)/2, by standard trig identities. This means that the ratio of the coefficients of the degree-d terms will be (2^d)/2. We can get Maple to verify that directly:

f:= [sin(x)*cos(x), sin(x)];
S:= convert~(f, FormalPowerSeries);

#Taylor polynomials: Degree 9 corresponds to k=4:
value(eval(S, infinity= 4));

#Ratio of coefficients: x^d corresponds to k = (d-1)/2:
simplify(`/`(eval(op~(1, S), map2(op, [2,1], S)=~ (d-1)/2)[]));

 

The problem with using unevaluation quotes is that you still need to know the name to put in those quotes. And if you know the name, you might as well put it in string quotes in the first place. So, I don't see much practical value in unevaluation quotes for this.

On the other hand, suppose that you want to list, as strings, all the locals in the current procedure, regardless of whether they have been assigned values. In that case, you can do this:

P:= proc() 
local a:= 2, b:= 7, x;
    convert~([op](2, thisproc), string)
end proc:
P();
                        ["a", "b", "x"]

 

There are two places in your code where you should've put a multiplication sign after w(y,z) but you didn't.

As you may have expected, many of your steps were unnecessary. All that's needed is:

eq1:= c__1^2 = (c__0 + 2*c__1 + 2*c__2)/5:
eq2:= c__1*c__2 = (2*c__1 + 2*c__2 + c__3)/5: 
eq3:= c__1*c__3 = c__2:
eq4:= c__2*c__3 = c__1:
eq5:= c__2^2 = (c__0 + 2*c__1 + 2*c__2)/5:
eq6:= c__3^2 = c__0:
simplify(c__1^11, {eq||(1..6)}, mindeg);
coeff(%, c__0, 1);

 

I agree that that help is poorly worded. What the option actually means is close to what you said. Giving continuous= true (or simply continuous) means "Assume, without checking, that the integrand f(x) in int(f(x), x= a..b) is continuous on [a,b], so the result is F(b)-F(a) where is a symbolic antiderivative of f. Either I know that it's continuous, or whether it is doesn't matter to me at the moment."

So, yes, continuous= false (the default) means to check for discontinuities (akin to plot's discont= true (or simply discont), as you said). The continuous= true option is often used when the default int returns unevaluated due to symbolic limits of integration such that it can't be determined whether there's a discontinuity between them.

In the following, assuming n::posint leads to the messy sum that you mentioned, and assuming n > 0 leads to a simple form in terms of Psi. But I can't convert those Psi to hypergeom.

restart:
evalindets(convert(1/(1+`x^n`), FormalPowerSeries), name, parse);
                      infinity           
                       -----             
                        \               k
                         )        k / n\ 
                        /     (-1)  \x / 
                       -----             
                       k = 0             

simplify(value(subsop(1= int(op(1, %), x= 0..1, continuous), %)))
    assuming n > 0;  #Assuming n::posint makes it too complicated.
                        /n + 1\      / 1 \
                     Psi|-----| - Psi|---|
                        \ 2 n /      \2 n/
                     ---------------------
                              2 n         

#Verify:
evalf(eval(%, n= 9) = Int(1/(1+x^9), x= 0..1));
                  0.9320304240 = 0.9320304242



If you use axesfont= [12, 12], the first 12 is assumed to be the name of a font, and the second 12 is the size of that font. You'd get exactly the same results using axesfont= [foo, 12]. A font specification in a plot command is always a list. Apparently, sometimes it's willing to ignore that the specified font 12 doesn't exist and just use some default font, and other times it's not willing to do that. Anyway, your usage of [12, 12] is simply nonsense.

I'm guessing that when you specified xk as the 2nd argument to solve, you were expecting it to infer that the solution variables were meant to be "all variables whose names begin xk." There is a (slightly advanced) way to do that, using a type called suffixed:

eq1 := xdot = (xk - xk1)/dt;
eq2 := xdot2 = (xk - 2*xk1 + xk2)/dt^2;
eq3 := c*xdot + k*xk + m*xdot2 = F;
eq:= {eq||(1..3)}; V:= indets(eq, suffixed(xk));
sol := solve(eq, V);

 

I assume that you mean that you want to find the index pairs [a,b] such that there exists an index x such that R[a,x] = 1 and S[x,b] = 1. Is that correct? In that case, you just need to multiply R.S and extract the index pairs of the nonzero entries of the product. This is amazingly easy in Maple. All that's needed is

[lhs]~(op(2, R.S))

Making an assignment to an essential predefined global variable such as constants is a little bit scary. I think that the preferred way to do what you want is to use the inert form of eval, named Eval:

mydiff:= Eval(diff(y(x,t), [x$3]), {x= a}) = V  # [...] is optional

That'll display the vertical evaluation bar in gray, which indicates the inertness. To display it in the usual blue:

InertForm:-Display(mydiff, inert= false)

 

I'd also prefer more automation, abstraction, and formalism for this. So, here it is:

restart:
Orth:= V-> [1,-1]*~V[[2,1]]:  #an orthogonal complement of a 2-vector
X:= [x,y](t):  P:= [r, theta](t):  #define variables
sys:= diff(X,t) =~ Orth(X);  #Cartesian-coordinate ODE system
#Use of a well-known and predefined transformation:
Tr:= X=~ changecoords(X, X, polar, P);
solve(eval(sys, Tr), diff({P[]}, t));

As you'd expect, PDEtools:-dchange works just as well for this, but I think it's overkill when working with a well-known predefined coordinate transformation.

First 47 48 49 50 51 52 53 Last Page 49 of 382