Carl Love

Carl Love

28095 Reputation

25 Badges

13 years, 100 days
Himself
Wayland, Massachusetts, United States
My name was formerly Carl Devore.

MaplePrimes Activity


These are answers submitted by Carl Love

Most of the information that you need to understand this can be found at ?rtable_eval. You may need to read that page slowly and carefully 10 to 20 times (like I did) to understand it. Also read the seventh and twelfth paragraphs of Description at ?eval. What you also need to know to understand this:

  • Most expressions fully evaluate when used at the command line (in any GUI).
  • Most expressions evaluate to only one level (equivalent to eval(..., 1)) when they're used in a procedure.
  • rtables never evaluate unless that's forced with a specific evaluation command.

To avoid obfuscation, first understand what is happening without the list conversion. To answer your Question about intention: yes, this behavior (before list conversion) is certainly intended. Whether the behavior after the list conversion is intended or correct or should be considered a bug: I don't know---it's a very fine judgement call. Certainly that behavior can be removed by adding an eval to `convert/list`.

A few examples:

 

restart:

A:= <a>:
a:= 1:

A;

Vector(1, {(1) = a})

rtable_eval(A);

Vector(1, {(1) = 1})

A;

Vector(1, {(1) = a})

rtable_eval(A, inplace);

Vector(1, {(1) = 1})

A;

Vector(1, {(1) = 1})

Procedure CL1 is an abbreviated version of how convert(..., list) actually works when applied to a Vector (see line 15 of showstat(`convert/list`)). Procedure CL2 is an alternative version that unintentionally applies another level of evaluation. I really can't say which is better. Procedure CL3 is a very slight variation of CL2 that shows that round-bracket indexing doesn't evaluate the entry whereas square-bracket indexing does. Procedures CL4 and CL5 show that the results of CL3 and CL2 (respectively) remain the same if the indexing type (round bracket or square bracket) is expressed in prefix form.

CL1:= proc(A) local i; [seq(i, i= A)] end proc:

CL2:= proc(A) local i; [seq(A[i], i= 1..numelems(A))] end proc:

CL3:= proc(A) local i; [seq(A(i), i= 1..numelems(A))] end proc:

CL4:= proc(A) local i; [seq(`?()`(A, [i]), i= 1..numelems(A))] end proc:

CL5:= proc(A) local i; [seq(`?[]`(A, [i]), i= 1..numelems(A))] end proc:

B:= <b>:
b:= 2:

CL1(B);

[b]

CL2(B);

[2]

CL3(B);

[b]

CL4(B);

[b]

CL5(B);

[2]

``

 

Download rtable_eval.mw

But I still don't understand this: What is the difference between rtable_eval(A, inplace) and map[inplace](eval, A)?

 

You're probabaly better off using LinearAlgebra:-LinearSolve as in Preben's Answer, but this is possible using solve as in your Question. But your multiply is meaningless, and solve deals with sets or lists of algebraic expressions or equations but not with matrices. However, converting between the forms is straightforward. Additionally, your construction of the matrices could be simplified. This works:

restart:
A1:= Matrix((3,3), symbol= a);
A2:= <A, B, C>;
A3:= <15, 0, 0>;
solve(convert(A1.A2 - A3, set), {A,B,C});

(Of course, this solution is only valid when the determinant is nonzero.)

You don't show the results of your second attempt. When I do it (in Maple 18), I get your desired result:

restart:
sol:= solve(combine(sin(x)^2)=1/4, x, AllSolutions);

     sol := -(1/3)*Pi*_B1+(1/6)*Pi+Pi*_Z1

This procedure will expand any positive integer power of any Sum.

 

Raising arbitrary Sums to positive integer powers

Carl Love 2015-Aug-7

 

restart:

The procedure NestedSum is to allow nested Sums to be specified as a single function call with the indices in a list, just as can be done with Int.

NestedSum:= proc(E, Ind::list(name = range))
local r:= E, ind;
     for ind in Ind do r:= Sum(r,ind) end do
end proc:

For example,

NestedSum(sin(m*x)*cos(n*x), [m= 1..n, n= 1..4]);

Sum(Sum(sin(m*x)*cos(n*x), m = 1 .. n), n = 1 .. 4)

The main procedure:


SumPower:= proc(S::Sum(anything, name= range), power::posint, {prefix::symbol:= _k})
uses C= combinat;
local
     p, part, perm,
     K, Ks:= [seq(cat(prefix,p), p= 1..power)],
     Es:= [seq(subs(op([2,1],S)= K, op(1,S)), K= Ks)],
     Inds:= [seq(Ks[p]= op([2,2,1],S)..Ks[p-1]-1, p= power..2, -1), Ks[1]= op([2,2],S)]
;
     add(
          C:-multinomial(power,part[])*
               NestedSum(
                    add(`*`((Es[..nops(part)]^~perm)[]), perm= C:-permute(part)),
                    Inds[power-nops(part)+1..]
               )
         ,part in C:-partition(power)
     )
end proc:

Example of use:

S:= Sum(E[n], n= 1..N):
S^5 = SumPower(S, 5, prefix= k);

(Sum(E[n], n = 1 .. N))^5 = 120*(Sum(Sum(Sum(Sum(Sum(E[k1]*E[k2]*E[k3]*E[k4]*E[k5], k5 = 1 .. k4-1), k4 = 1 .. k3-1), k3 = 1 .. k2-1), k2 = 1 .. k1-1), k1 = 1 .. N))+60*(Sum(Sum(Sum(Sum(E[k1]^2*E[k2]*E[k3]*E[k4]+E[k1]*E[k2]^2*E[k3]*E[k4]+E[k1]*E[k2]*E[k3]^2*E[k4]+E[k1]*E[k2]*E[k3]*E[k4]^2, k4 = 1 .. k3-1), k3 = 1 .. k2-1), k2 = 1 .. k1-1), k1 = 1 .. N))+30*(Sum(Sum(Sum(E[k1]^2*E[k2]^2*E[k3]+E[k1]^2*E[k2]*E[k3]^2+E[k1]*E[k2]^2*E[k3]^2, k3 = 1 .. k2-1), k2 = 1 .. k1-1), k1 = 1 .. N))+20*(Sum(Sum(Sum(E[k1]^3*E[k2]*E[k3]+E[k1]*E[k2]^3*E[k3]+E[k1]*E[k2]*E[k3]^3, k3 = 1 .. k2-1), k2 = 1 .. k1-1), k1 = 1 .. N))+10*(Sum(Sum(E[k1]^3*E[k2]^2+E[k1]^2*E[k2]^3, k2 = 1 .. k1-1), k1 = 1 .. N))+5*(Sum(Sum(E[k1]^4*E[k2]+E[k1]*E[k2]^4, k2 = 1 .. k1-1), k1 = 1 .. N))+Sum(E[k1]^5, k1 = 1 .. N)

Verify that that's correct.

is(value(eval(%, N= 3)));

true

The sum doesn't need to start at 1. Indeed, it could start at a variable.

 

 

Download SumPower.mw

You simply need to include the option maxfun= 0 in the dsolve call. This actually sets the maximum allowed number of function evaluations to infinity.

The command is member(c, A), which is built-in and returns type truefalse.

The problem with Kitonum's Answer is that the solve is executed for each iteration. The (potential) problem with Tom Leslie's Answer is that it isn't a single statement. The solution to both problems is the oft-neglected sequencing operator. It works very much like seq except that, like most Maple commands (but unlike seq), its arguments are evaluated before being passed.

{b=j, eval(solve({x+b*y=0, b*x-y=10}, {x,y}), b= j)[]} $ j= 10..20;

     {b = 10, x = 100/101, y = -10/101}, {b = 11, x = 55/61, y = -5/61}, {b = 12, x = 24/29, y = -2/29},
     {b = 13, x = 13/17, y = -1/17}, {b = 14, x = 140/197, y = -10/197}, {b = 15, x = 75/113, y = -5/113},
     {b = 16, x = 160/257, y = -10/257}, {b = 17, x = 17/29, y = -1/29}, {b = 18, x = 36/65, y = -2/65},
     {b = 19, x = 95/181, y = -5/181}, {b = 20, x = 200/401, y = -10/401}

The example structure C that you showed is not a set: it's a sequence: its order matters, and members may be repeated. If you want to subtract a member from a set, then use the Answer by Thomas Dean. If you want to remove all occurences of a member B from a sequence C, then use

remove(`=`, [C], B)[];

Note that the is not enclosed in { } in the solve command below.

Sol:= [solve(f, omega)];
min(select(`>`, Sol, 0));

Here's a procedure that will cancel the lowest floating-point power of 10 (positive or negative) in any fraction:

Cancel10s:= (E::algebraic)->
     `if`(
          hastype(E,And(float,Not(identical(0.)))),
          `/`((numer,denom)(E)/~10^ilog10~(indets(E,And(float,Not(identical(0.)))))[1]),
          E
      )
;

(Note that ilog10 also works for negative floats.) If the input is not a single fraction, it'll be rearranged to one. An expression mathematically equivalent to the input is returned in all cases, although it may not be the desired result if the expression contains nested floats. 

 

@smith_alpha 

Here are five methods for creating and filling a list. I've listed them in increasing order by the amount of computational resources that they take. Never use #5: It's very wasteful and never necessary. I only include it because it's the way that most people come up with on their own instead of #3 or #4. There are many situations where you can't use #1 or #2 and must resort to #3 or #4.

#1
f:= [seq(i, i= 1..3)];

#2
f:= ['i' $ 'i'= 1..3];

#3
f:= Vector():
for i to 3 do f(i):= i end do:
f:= convert(f, list);

#4
f:= table():
for i to 3 do f[i]:= i end do:
f:= convert(f, list);

#5
f:= []:
for i to 3 do f:= [op(f), i] end do;

There must be something additional known about (other than about its degree of differentiability) in order for the identity to be true. Proof: Suppose u(x,y,z,w) = x. This u satisfies any possible degree-of-differentiability requirement. Since there are no derivatives taken with respect to x3 or y3, we can ignore any factors that depend only on those variables. (Alternatively, we could suppose, without loss of generality, that x3-y3 = 1.) Then the expression that you're taking the derivatives of is equivalent to w below. Execute the following Maple code:

u:= (x,y,z,w)-> x:
w:= add((x||k - y||k)^2, k= 1..3)^(-1/2)*u(x3*y1-x1*y3+x2-y2, 0, 0, 0):
diff(w,x1,y2)-diff(w,y1,x2):
eval(%, [x1=1,x2=2,x3=3,y1=4,y2=5,y3=2]);

Maple returns a number other than 0.

So, what are the assumptions made on u in the paper?

First do the permutations of the lists, then convert the lists to Arrays, for example like this:

Array~(combinat:-permute([1,2,3]));

Never use array (with a lowercase a); it's deprecated. Use Array instead. Likewise for matrix and vector.

 

Yes, it certainly seems like a bug. Here's a quick workaround:

fsolve(evalf(P), complex);

evalindets(eq, fraction, evalf);

First 253 254 255 256 257 258 259 Last Page 255 of 395