It was pretty easy to get 32bit Classic to work with 64bit Maple 14, under 64bit Windows 7 Professional. I followed this (but did it ever so slightly more simply).

Everything worked as expected from a usual Classic perspective, except the Help system. (Even the Help used to work fine in this way, for some earlier versions of Maple.) But that's ok with me, since the Help system is a separate executable in Maple 14 and can now be invoked as a stand-alone process.

I set it up so that &? acted as a prefix operator and launched the stand-alone Help system. And I also set interface(helpbrowser=text), not because it worked (it doesn't, prettily) but so that regular prefixed ? calls would not crash the session.

Here's a screenshot. Ask, if you want a screenshot of it doing something else.

That is fascinating. That web reference cites 2048 items as being B(2,5). Would it be easy to generate them all, using GraphTheory?

I subsequently halved the run-time of the edited code I posted above -- though I haven't reposted. But it still took a Core2 Duo thirty minutes to compute the 2048 solutions for its n=32 case. Anything grander than such brute force might be... grand.

Oh, maybe the links should be followed. Eg, maybe here?

That is fascinating. That web reference cites 2048 items as being B(2,5). Would it be easy to generate them all, using GraphTheory?

I subsequently halved the run-time of the edited code I posted above -- though I haven't reposted. But it still took a Core2 Duo thirty minutes to compute the 2048 solutions for its n=32 case. Anything grander than such brute force might be... grand.

Oh, maybe the links should be followed. Eg, maybe here?

On reflection, it seems to me that there may not be a need to sort S explicitly.

As each S[j+1] is produced, determine which slot it lies in (in order that S[1] is accepted into K). Mark an Array entry Q[j] by assigning it as 1, to denote that S[j+1] lies in the jth slot (one of the k subranges from (k-1)/n to k/n). But before marking Q[j], test whether it is already 1. If it's already 1, then a second entry cannot go into it. And the loop of generating the S[j+1] must be broken out of.

In this way, you don't have to compute all the S[j+1] for all j from 1 to n-1. You break out (of computing S) early at the first duplicate use of a subrange by a pair of entries of S. If all S[j+1] are produced right up to S[n], without duplicate use of a subrange, then S[1] gets added into K. No need for any further checks on that S[1].

You can re-use Q for each different initial S[1]. Just zero all entries of Q, before beginning with the new S[1]. That should avoid some garbage production & collection. This idea also lets you get rid of the sort(S) and the looped check that comes after it, which is just production of more collectible garbage.

Sorry, I don't have time to code up this suggestion.

On reflection, it seems to me that there may not be a need to sort S explicitly.

As each S[j+1] is produced, determine which slot it lies in (in order that S[1] is accepted into K). Mark an Array entry Q[j] by assigning it as 1, to denote that S[j+1] lies in the jth slot (one of the k subranges from (k-1)/n to k/n). But before marking Q[j], test whether it is already 1. If it's already 1, then a second entry cannot go into it. And the loop of generating the S[j+1] must be broken out of.

In this way, you don't have to compute all the S[j+1] for all j from 1 to n-1. You break out (of computing S) early at the first duplicate use of a subrange by a pair of entries of S. If all S[j+1] are produced right up to S[n], without duplicate use of a subrange, then S[1] gets added into K. No need for any further checks on that S[1].

You can re-use Q for each different initial S[1]. Just zero all entries of Q, before beginning with the new S[1]. That should avoid some garbage production & collection. This idea also lets you get rid of the sort(S) and the looped check that comes after it, which is just production of more collectible garbage.

Sorry, I don't have time to code up this suggestion.

Preben's original Answer and methodology looks acceptable (to me).

> g := 1+2/sqrt(x+sqrt(7));

                                 2        
                     1 + -----------------
                                     (1/2)
                         /     (1/2)\     
                         \x + 7     /     

> op(map2(op,1,indets(g,{algebraic^(1/2),algebraic^(-1/2)})));
                                 (1/2)
                         7, x + 7     

Preben's original Answer and methodology looks acceptable (to me).

> g := 1+2/sqrt(x+sqrt(7));

                                 2        
                     1 + -----------------
                                     (1/2)
                         /     (1/2)\     
                         \x + 7     /     

> op(map2(op,1,indets(g,{algebraic^(1/2),algebraic^(-1/2)})));
                                 (1/2)
                         7, x + 7     

@lemelinm Here's a link to what is only an opinion, concerning `assign` versus `eval`.

I don't think that you should take down-votes personally. It's probably more about the answer, than it is about you yourself as a person. It's a mechanism to cast a vote on how Answers should be presented, for those who feel that some Answers are more helpful to the general (eg. nonexpert) reader.

@lemelinm Here's a link to what is only an opinion, concerning `assign` versus `eval`.

I don't think that you should take down-votes personally. It's probably more about the answer, than it is about you yourself as a person. It's a mechanism to cast a vote on how Answers should be presented, for those who feel that some Answers are more helpful to the general (eg. nonexpert) reader.

How about abs(x) for x on a range that crosses x=0, such as x=-2..2 ?

I see no significant speed advantage of this over Preben's Method 1). But the memory allocation is lower by about 33%, and it certainly looks tidier (and is easier for people to understand, I expect).

restart:
X:=[$1..10^5]:
t:=[$1..10^3]:
st,ba,bu:=time(),kernelopts(bytesalloc),kernelopts(bytesused):
subs([seq(t=NULL, t in t)],X):
time()-st,kernelopts(bytesalloc)-ba,kernelopts(bytesused)-bu;
                     0.344, 982860, 816964

Of course, it ought to be no slower as it essentially just does one less eval.

I see no significant speed advantage of this over Preben's Method 1). But the memory allocation is lower by about 33%, and it certainly looks tidier (and is easier for people to understand, I expect).

restart:
X:=[$1..10^5]:
t:=[$1..10^3]:
st,ba,bu:=time(),kernelopts(bytesalloc),kernelopts(bytesused):
subs([seq(t=NULL, t in t)],X):
time()-st,kernelopts(bytesalloc)-ba,kernelopts(bytesused)-bu;
                     0.344, 982860, 816964

Of course, it ought to be no slower as it essentially just does one less eval.

@hirnyk A complex-valued function can have a real (one-sided) limit at a point, if the imaginary component tends to zero there. I mean with x=A+B*I approaching 0+0*I purely along the real axis from the left; approaching along B=exp(A) say is quite different. But your `limit` call in question implied x real.

f:= (1+a*x^2)^log(x):
plot3d([Re(f),Im(f)],x=-2..0,a=-1..1,axes=boxed);

The exciting part may be in showing it analytically (was this an assignment question, I wonder? No cheating with `series`?). But that's not really here not there, and just a question to the side.

The original Post mentioned a real-valued f. Now, a=0 gives f=1^(ln(x)). Do you not think that 1^(ln(x)) equals 1, for all x<0?

No other value of `a` except 0 is going to give f as a real-valued function for x<0.

@icedragon You cut and pasted all that code, including the restart and with(plots), into Maple 14, and executed and got nothing at all?

@icedragon You cut and pasted all that code, including the restart and with(plots), into Maple 14, and executed and got nothing at all?