It's an interesting give and take, between speed and memory allocation, with the combinat:-nextcomb command (new in Maple 16).

At (m,n)=(21,10) it can take only half the time to generate all combinations up front, but three times the allocation. Up at (m,n)=(26,10) the timing ratio is about the same (on my i7) but the memory for storing all combinations gets to about 30 times more than with using nextcomb (on 64bit Maple 16 on Windows 7).

restart:
st,ba:=time(),kernelopts(bytesalloc):
A:=[a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u]:
L := combinat:-choose(21, 10):
for B in L do testthis:=A[B]; end do:
time()-st,kernelopts(bytesalloc)-ba;

                        5.351, 325607424

restart:
with(combinat):
st,ba:=time(),kernelopts(bytesalloc):
A:=[a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u]:
M,N := nops(A), 10:
B := [$1..N]:
testthis:=A[B]:
for ii from 1 to numbcomb(M, N)-1 do
   B:=[nextcomb(B, M)[]];
   testthis:=A[B];
end do:
time()-st,kernelopts(bytesalloc)-ba;

                        11.248, 99635200

restart:
st,ba:=time(),kernelopts(bytesalloc):
A:=[a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z]:
L := combinat:-choose(26, 10):
for B in L do testthis:=A[B]; end do:
time()-st,kernelopts(bytesalloc)-ba;

                       84.927, 3847241728

restart:
with(combinat):
st,ba:=time(),kernelopts(bytesalloc):
A:=[a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z]:
M,N := nops(A), 10:
B := [$1..N]:
testthis:=A[B]:
for ii from 1 to numbcomb(M, N)-1 do
   B:=[nextcomb(B, M)[]];
   testthis:=A[B];
end do:
time()-st,kernelopts(bytesalloc)-ba;

                       168.559, 99635200

Using nextcomb might strictly require even less memory than gets allocated in practice, since the Maple 16 kernel is more generous with allocating itself memory resources (...leading up to the amounts at which initial garbage collection happens).

acer

What the Document contains in its calls to ShowCal are terms whose underlying structure (represented in 1D syntax) is actually 3345+`&+-`(10). In the Document this is displayed in 2D Math Input just as if it were a 2-argument call to the infix operator `&+-`.

And so DJKeenan has coded the type-check in his `ShowCal` routine. (Let's not get sidetracked on whether it was ganz korrect. The key thing is that it matches the form.) And the worksheet runs OK, off the bat.

But if you try and copy and paste such an expression then the GUI and Typesetting mechanism can turn it into the more familiar postfix function call `&+-`(3345,10). And so when pasted into a call to `ShowCal` then execution leads to the argument failing the type-check.

And it seems more complicated still. Once such a pasting mixup occurs in the session it may be that all subsequent uses of the +- syntax in 2D Math Input may produce the alternate form. Hot restarts of the worksheet, without closure of the sheet, may reset internal Typesetting tables which may be storing the parsed meaning.

I'm not sure why the 2D Math parsing that resulted in A+`&+-`(B) was ever allowed or implemented. In 1D Maple Notation the plus-minus notation denotes `&+-`(A,B), and that is pretty much that.

It would be good if DJKeenan's code continued to work ok, and so cut and pasting his A+`&+-`(B) objects should preserve their structure. But I think that the palette items, and command completion of `plusmn` or `pm`, should all produce `&+-`(A,B) alone.

acer

@Christopher2222 Yes, I understand what you mean, thanks. But which Apps are these, in particular?

@Alejandro Jakubi 

A few words from Max Von Sydow.

@Alejandro Jakubi 

A few words from Max Von Sydow.

@senthil36yours In your wprksheet you execute evalf@allvalues, to examine the results. Does this mean that floating-point approximations to the (real) roots is good enough?

Maybe some real root-finding technique like repeatedly calling fsolve with its `avoid` option, or RootFinding:-Isolate(..,numeric) would suffice?

You said this was an iterative process. Does that mean that each new EQ1,EQ2 is somehow built up from the preceding iteration's found roots? Where do those long integer coefficients come from?

Are the roots expected to be in the same general bounded area, at each iteration? (I ask because fsolve can be quite fast here, but may need to be passed suitable ranges in order to easily find all real roots, since the expressions become so steep.)

@senthil36yours In your wprksheet you execute evalf@allvalues, to examine the results. Does this mean that floating-point approximations to the (real) roots is good enough?

Maybe some real root-finding technique like repeatedly calling fsolve with its `avoid` option, or RootFinding:-Isolate(..,numeric) would suffice?

You said this was an iterative process. Does that mean that each new EQ1,EQ2 is somehow built up from the preceding iteration's found roots? Where do those long integer coefficients come from?

Are the roots expected to be in the same general bounded area, at each iteration? (I ask because fsolve can be quite fast here, but may need to be passed suitable ranges in order to easily find all real roots, since the expressions become so steep.)

What you've described seems to be like the functionality of the DocumentTools[Retrieve] command.

But why not just savelib the data to an .mla Library archive file, when it first gets computed in the original worksheet? 

acer

What you've described seems to be like the functionality of the DocumentTools[Retrieve] command.

But why not just savelib the data to an .mla Library archive file, when it first gets computed in the original worksheet? 

acer

@Markiyan Hirnyk See here for the source.

@Markiyan Hirnyk See here for the source.

@serena88 The seq command takes an optional third argument, for the increment, which can be negative.

> j[[seq(i,i=13..4,-1)],1];

                    j[[13, 12, 11, 10, 9, 8, 7, 6, 5, 4], 1]

@serena88 The seq command takes an optional third argument, for the increment, which can be negative.

> j[[seq(i,i=13..4,-1)],1];

                    j[[13, 12, 11, 10, 9, 8, 7, 6, 5, 4], 1]

@Brettski If you lprint that  atomic-identifier name then you'll likely see something like `#msub(mi("P"),mn("0"))`.

And that is a name (because it is wrapped in single-left name quotes). But the Maple Standard GUI knows to display it as a subscripted name.

@Brettski If you lprint that  atomic-identifier name then you'll likely see something like `#msub(mi("P"),mn("0"))`.

And that is a name (because it is wrapped in single-left name quotes). But the Maple Standard GUI knows to display it as a subscripted name.