It's not clear what exactly you're saying. Could you upload a simple example in a worksheet, and clear mark what you think is a 2D Math literal subscript within it, and note the actions that undermine that aspect?

If you are working with summations (function calls to `Sum`, or unevaluated function calls to `sum`) then how can a literal subscript be of any special use? If a name that looks like x-subscript-i is a name with a literal subscript then it will not change as `i` changes. And, inside a `sum` that uses `i` as the index of summation then such an x-subscript-i would be equivalent to a constant.

It is not at all true that the whole point behind literal subscripts is to "make the equations visual." Such a claim makes it unclear whether your understanding of the term agrees with how it is used in Maple. If I misunderstand you then I apologize -- it's hard without an example worksheet. The purpose of a literal subscript is to provide a distinct name which is wholly independent of the base-name. In other words, the purpose is to provide a visually subscripted name which is acted upon as if it were a unique name with no relationship to either the unsubscripted base name or the subscript.

For example, suppose that  was a name with a literal subscript. That means that it is not equal to  when i=0 since that  is its own unique identifier and depends upon neither x nor i, in both a mathematical and a syntactical way. Such a subscripted name is not useful in the usual way if used inside a sum indexed by `i`.

Indexed names, on the other hand, change identity as the value of the index changes. If  is the 2D Math input representing the 1D Maple Notation name x[i] then it changes identity as `i` changes. Just as in 1D, this indexed name is like what usually gets used within a sum indexed by `i`. The whole point of making indexed names be marked up to appear as subscripted names when displayed as 2D Math input is so that some indexed formula is visual (ie. 2D).

acer

Some might find interesting the arXiv.org paper, Two-term recurrence formulae for indefinite algebraic integrals, and this usenet thread.

acer

@Markiyan Hirnyk I worked it out with Analytic approximately 12 hours ago, after quite a bit of digging inside `fsolve/polyill`, and then decided to wait to see whether he really needed all the nonreal roots. My answer coincided primarily with... lunch time.

I don't track the Recent pages here; just use a feed to google Reader which often has quite a delay in auto-freshing. It's not as if it were any great accomplishment to figure it out.

I'm more interested in what's going on in the hang by`fsolve/polyill` and RootFinding:-Isolate (only 72 roots found?... but why?) than I am in competing.

@Markiyan Hirnyk I worked it out with Analytic approximately 12 hours ago, after quite a bit of digging inside `fsolve/polyill`, and then decided to wait to see whether he really needed all the nonreal roots. My answer coincided primarily with... lunch time.

I don't track the Recent pages here; just use a feed to google Reader which often has quite a delay in auto-freshing. It's not as if it were any great accomplishment to figure it out.

I'm more interested in what's going on in the hang by`fsolve/polyill` and RootFinding:-Isolate (only 72 roots found?... but why?) than I am in competing.

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

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.