I'm not sure whether any of this might be useful to you.

restart:

`diff/E`:=proc(t) K(t); end proc:

diff(E(y),y);

                                    K(y)

`D/E`:=t->K:

D(E);

                                      K

D[1](E)(y);

                                    K(y)

(D@@2)(E);

                                    D(K)

(D@@2)(E)(y);

                                   D(K)(y)

acer

This looks like a regression bug to me. I've submitted a bug report (SCR).

I'm guessing that you already know that you can use the strings ["1,"10","100"] and parse, to get it to work in both versions. But that's just a workaround; it should still work with numeric values.

acer

As Carl mentions, you are being bitten by premature evaluation. Note that sum and Sum adhere to Maple's usual evaluation rules for procedure calls: first the supplied arguments are evaluated, and only after that are they passed to the called procedure.

You can search this site, or the web, and find lots of similar examples.

The problem is one of usage -- that the new user has not yet learned how the system normally works.

And it comes up for lots of other commands too (again, especially for new users, until they learn how Maple works). You can find examples for plot, fsolve, Optimization:-Minimize, and so on.

Carl mentions two ways to make things work, but in fact there are sometimes more than just those two. Some commands like plot, fsolve, and Minimize also accept a so-called operator form for the first argument. For example plot(f,0..1) instead of plot(f(x),x=0..1), where there is no dummy variable and hence no function call to be accidentally prematurely evaluated.

And for some other commands, such as sum and product there are related commands add and mul with special evaluation rules. The basic idea is that add follows a special rule: it receives its first argument without that having being evaluated. For this and a few other reasons using add is often suggested for finite summation, over using sum.

If you want to see what the call sum(pdf4(i),i=3..3) is actually sending to the sum procedure then call pdf4(i) alone, outside of a call to sum or anything else, and see what result is returned.

I won't repeat the two ways that Carl mentioned in his good Answer. Both those approaches often suffice with both the commands like plot as mentioned above, and also with the commands like sum as mentioned above. However I often prefer using the approaches I've mentioned above, if possible, rather than having to rewrite my custom procs to return unevaluated on nonnumeric input.

What you've shown is a (mostly new user related) usage problem. But there are indeed flaws. 2D Math Input allows for the typeset summation (Sigma) symbol only for sum and Sum. There is no good hook between the typeset summation symbol and add, unless you make your code convoluted by utilizing special exports of the Physics package. Yet add would often serve better than sum. And 2D Math Input is the default for new users. And the documentation pushes palette use big time. And combined that is all quite unfortunate because it make this issue arise far more than ought to be necessary.

Note that new users to Mathematica often have equivalent or similar problems, until they learn to use NumericQ.

acer

Matrix(5,5,(i,j)->i+j)

Also if you intend on indexing into this Matrix (let's suppose you assigned it to the name A) later on then use the syntax such as A[i,j] and not A[i][j] which can be quite inefficient.

In this particular case that you've asked about you can also do simply Matrix(5,5,`+`) , but the way above shows how you can construct more generally.

acer

I use Maple 18.02 below, as this Question is marked as related to Maple 18.

Here are a few ways that work with your approach of using double pairs of unevaluation quotes around each of the plot calls.

restart;
with(plots):
with(plottools):
Parab1 := ''plot(a*x^2, x = -1 .. 1, y = -3 .. 3)'':
Parab2 := ''plot(a*x^2+1, x = -1 .. 1, y = -3 .. 3)'':
L:=Array(1..2):
L[1]:=Parab1:
L[2]:=Parab2:

Explore((unapply('display'(L),a))(A), parameters = [[A = -1.0 .. 1.0, label=a]]);

And here is another way that also works with that approach,

restart;
Parab1 := ''plot(a*x^2, x = -1 .. 1, y = -3 .. 3)'':
Parab2 := ''plot(a*x^2+1, x = -1 .. 1, y = -3 .. 3)'':
L:=Array(1..2):
L[1]:=Parab1:
L[2]:=Parab2:

F:=proc(A)
     plots:-display(eval(L,a=A));
end proc:
Explore(F(a), parameters=[a=-1.0 .. 1.0]);

And here is another way that also works with that approach,

restart;
with(plots):
with(plottools):
Parab1 := ''plot(a*x^2, x = -1 .. 1, y = -3 .. 3)'':
Parab2 := ''plot(a*x^2+1, x = -1 .. 1, y = -3 .. 3)'':
L:=Array(1..2):
L[1]:=Parab1:
L[2]:=Parab2:

eval('Explore'('display'(L), parameters = [[a = -1.0 .. 1.0]]));

Here is a way which doesn't use unevaluation quotes.

restart:
H:=proc(a)
     plots:-display(Array([plot(a*x^2, x = -1 .. 1, y = -3 .. 3),
                           plot(a*x^2+1, x = -1 .. 1, y = -3 .. 3)]));
end proc:  
Explore(H(a), parameters=[a=-1.0 .. 1.0]);

acer

[This answer has been edited: see comments below for modifications, obtaining 16 solutions with all of t,t1,t2,t3 between 0 and 2*Pi]

Here I'm getting 128 solutions with all of t,t1,t2,t3 between -2*Pi and 2*Pi.

(I used Maple 18.02 on 64bit Linux.)

restart:
f1 := -8100+(-30+70*cos(t1)-40*cos(t2))^2
      +(-70*sin(t1)+40*sin(t2))^2:
f2 := (-20-80*cos(t3))^2+(-15+70*cos(t1)+10*cos(t1+t))^2
      +(-70*sin(t1)-10*sin(t1+t)+80*sin(t3))^2-5625:
f3 := (-20-80*cos(t3))^2+(15+40*cos(t2)+10*cos(t1+t))^2
      +(-40*sin(t2)-10*sin(t1+t)+80*sin(t3))^2-5625:
f4 := 10*cos(t1+t)*(30-70*cos(t1)+40*cos(t2))
      -10*sin(t1+t)*(70*sin(t1)-40*sin(t2)):
origsys := {f1,f2,f3,f4}:
sys := map(expand,origsys):
T := [indets(sys,function)[]]:
Tsub := [seq(x=freeze(x),x=T)]:
extra := {seq(sin(r)^2+cos(r)^2-1,r=[t,t1,t2,t3])}:
Digits,oldDigits := 20*Digits,Digits:
raw := thaw(RootFinding:-Isolate(eval(sys union extra,Tsub),eval(T,Tsub))):
Digits := oldDigits:
gen := proc(cand)
  local c, v;
  c[t]:=select(has,cand,t);
  c[t1]:=select(has,cand,t1);
  c[t2]:=select(has,cand,t2);
  c[t3]:=select(has,cand,t3);
  [seq(seq(seq(seq([e,f,g,h],e=c[t3]),f=c[t2]),g=c[t1]),h=c[t])];
end proc:
sols := {seq(seq(
      `if`(evalf[2*Digits](max(map(abs,eval(origsys,eq))))<10^(-Digits+1),
           eq, NULL),
      eq=evalf[2*Digits](gen(
map(eq->select(u->is(abs(rhs(u))<=2*Pi),
    [seq(lhs(eq)=rhs(eq)+k*Pi,k=-4..4)])[],
    (map(eq->fsolve(eq,indets(eq,name))[],raw[i])))
))),
    i=1..nops(raw))}:

sols := evalf[15](sols):
nops(sols);
                                     128

max(seq(max(map(abs,evalf[2*Digits](eval(origsys,s)))), s in sols));
                                          -11
                                6.02316 10   

#seq(print(evalf[10](s)), s=sort(sols));

@Petra Heijnen Yes, in Maple 18 you can insert a PlotComponent from the palette, and then in your looping code update that component by using SetProperty to give it a new value.

For example, insert a PlotComponent from the palette. Right-click on it and discover that its name/identity is, say, PlotComponent0. Then, in your looping code, whenever you wish to update the component to show a new plot you can use the SetProperty command. Your code might look something like this,

for i from something to whatever do

  if some_condition_of_yours then
    P := plot(...);
    DocumentTools:-SetProperty("PlotComponent0", ':-value', P, ':-refresh'=true);
  end if;

end do:

Now, it's up to you where you insert the component. You might want it close to the place from which you execute your code, but that's up to you.

Apply the evalf command to obtain floating-point approximations.

Eg,

evalf( ln(3) )

evalf( exp(5) )

acer

I'm supposing that this is homework of some sort, and that the goal is for you to figure out how and why (and whether) it can be done.

Create column Vectors of the coefficients in g1 and g2, both with respect to all of the terms present, ie., [x,x^2,y,y^2]. Concatenate those as columns of a Matrix M. Create a similar Vector V, for f. Then call LinearSolve(M,V) and the result if it exists will be a 2-element Vector whose entries are the coefficients of the linear combination.

If you have any constant terms then make the Vectors one row taller, and use them in the extra row. 

acer

Here is a hack for 2D display. I expect that someone could also do similarly for 3D.

Of course, it's not ideal to try and turn boxes into disks. The ideal would be support for customized appearance in the GraphTheory package itself.

Improvements welcome, but please remember that it was just written as a quick hack. I used a disk, as it was simplest to code. It could look better with an ellipse, depending on the length/height ratio of a vertex label.

restart:

quad2disk := proc(P::specfunc(anything,:-PLOT))
  subsindets(P,
             And(specfunc(':-POLYGONS'),
                 satisfies(p->nops(p)>0
                           and op(1,p)::[[numeric,numeric],[numeric,numeric],
                                         [numeric,numeric],[numeric,numeric]])),
             proc(p) local t,r;
               (t,r):=selectremove(type,[op(p)],list(list(numeric)));
               ':-POLYGONS'(seq(op(plottools:-disk([(op([1,1],pp)+op([3,1],pp))/2,
                                    (op([1,2],pp)+op([2,2],pp))/2],
                                   (op([1,1],pp)-op([3,1],pp))/2)),
                                pp in t), op(r)); end proc);
end proc:

with(GraphTheory):
W := Graph(undirected, {{0, 1}, {0, 2}, {0, 3}}):
HighlightEdges(W, W, black):
HighlightVertex(W, [1, 2, 3, 0], gray):
DrawGraph(W);

quad2disk(DrawGraph(W));

with(SpecialGraphs):
G := SoccerBallGraph():
HighlightVertex(G, Vertices(G), cyan):
HighlightEdges(G, G, gray):

DrawGraph(G);

quad2disk(DrawGraph(G));

with(RandomGraphs):
T := RandomTree(10):
HighlightVertex(T, Vertices(T), gold):
HighlightEdges(T, T, COLOR(RGB,0.2,0.2,0.7)):
DrawGraph(T);

quad2disk(DrawGraph(T));

with(GraphTheory):
G := Graph({{1,2},{2,3},{3,1},{3,4},{4,5},{5,6},{6,4}}):
A := ArticulationPoints(G):
HighlightVertex(G,A,magenta):
DrawGraph(G);

quad2disk(DrawGraph(G));

acer

Sorry this took a while. Hopefully it is still of some use to you.

I was able to compute smaller/shorter/simplified results for your problematic expressions, for which simplify(...) and simplify(...,size) was failing you. And using the same technique I was also able to compute smaller/shorter results for your earlier expressions which had previously been simplified. See the attached worksheet. I get similar results in Maple 18.02 and Maple 2015.1, but notice that timings are higher in 64bit Windows than 64bit Linux on comparable hardware.

The problems seem to boil down to a few things. Don't evaluate some of the unknowns to floating-point values before simplifying, if you can avoid it. It can lead to a variety of severe problems. Also, simplification of huge expressions containing trig function calls is tricky. In this case it seems that restraining the combining of trig terms to just a few of the relevant unknowns may be key.

I also tried to avoid final results with this kind of ugly and suspicious form, which you might normally hope would produce saner coefficients but which in fact gets returned by some simplification call:

(1.2349876*10^(-9)) * ( ...+ (5.6781234*10^11)*subexpr ... + anotherexpr/(3.4568762*10^(-8)) ... )

This particular run was in 64bit Maple 18.02 on Windows 7.

Download Example_modif2_1802.mw

If you want to see the module definition "shell" then you can still get that printed by querying for the 2nd operand of the module.

op(2,eval(sqrt));

      module() local ModuleApply, Nested, Product, Primes; end module

The above was done in Maple 2015.1, and is also what Maple 18.02's Standard GUI prints when eval(sqrt) is called.

acer

You seem to have used "basis" in two ways. At the end you mention a basis {C}, apparently in the mathematic sense. At the beginning you mentioned the A,B,C,D for a "basis" for your computations, apparently using the term in a non-technical sense. The inconsistency may confuse some people.

I'll use DD rather than D which is a protect Maple name with special meaning as the differential operator.

If you want to express the Matrix A+B in terms of the "basis" of Matrices {C,DD} then you can turn everything into column Vectors, concatenate the new column-Vector elements of your "basis" into a Matrix, and use LinearSolve.

Note that {C} or {C,DD} aren't enough to form a basis for the 4-dimensional space that spans the space. So for some candidate Matrix other that the Matrix A+B your set {C,DD} might not suffice.

Taking your trivial example,

restart:                                                       

DD:=Matrix(2,symbol=d):                                        
C:=Matrix([[i,i],[-i,i]]):                                     

A:=Matrix([[1,0],[0,1]]):                                      
B:=Matrix([[0,1],[-1,0]]):                                     

with(LinearAlgebra):                                           

f:=m->convert(m,Vector[column]):                               

sol:=LinearSolve(<f(C)|f(DD)>,f(A+B)):                         

A+B=add(`if`(sol[j]=0, 0, sol[j].[C,DD][j]), j=1..Dimension(sol));

                         [ 1    1]           [i     i]
                         [       ] = (1/i) . [       ]
                         [-1    1]           [-i    i]

In other words the problem solved above is to express A+B as a linear combination of the entries of {C,DD}. (...and the solution of that might be done using 4x1 column vectors rather than 2x2 Matrices.) Is that close to what you want? For other examples you might need to use values rather than just symbols for the entries of Matrix DD. In your trivial example is turns out not to have mattered...

You can change the above example to have C = Matrix([[0,i],[-i,0]]) instead, and then use f(A.B) instead of f(A+B) in the call to LinearSolve. The result of coefficients, sol, would happen to be the same.

acer

Fun := Diff(f(x), x):           

int(Fun, x = 2 .. 7, continuous);

                                 -f(2) + f(7)

acer

If you assign that expression to a name, say ee, then try,

simplify(ee, size)

acer