@TommySnowman Thanks for clearing that up. I misunderstood which you expected.

@Markiyan Hirnyk Markiyan Hirnyk's interpretation looks like a match for the (slightly unclearly asked) question.

And Maple provides some tools, in case someone doesn't wish to rely on their own math in order to effect the change,

expression, dfl := x, 1/x:

G := Int(expression, dfl);

                              /     
                             |     1
                             |  x d-
                             |     x
                            /       

IntegrationTools:-Change(algsubs(dfl=t, G), t=dfl);

                             /       
                            |    1   
                            |  - - dx
                            |    x   
                           /         

value(%);

                             -ln(x)

G := Int(f(x), dfl);

                            /        
                           |        1
                           |  f(x) d-
                           |        x
                          /          

IntegrationTools:-Change(algsubs(dfl=t, G), t=dfl);

                           /          
                          |    f(x)   
                          |  - ---- dx
                          |      2    
                         /      x     

@Markiyan Hirnyk Markiyan Hirnyk's interpretation looks like a match for the (slightly unclearly asked) question.

And Maple provides some tools, in case someone doesn't wish to rely on their own math in order to effect the change,

expression, dfl := x, 1/x:

G := Int(expression, dfl);

                              /     
                             |     1
                             |  x d-
                             |     x
                            /       

IntegrationTools:-Change(algsubs(dfl=t, G), t=dfl);

                             /       
                            |    1   
                            |  - - dx
                            |    x   
                           /         

value(%);

                             -ln(x)

G := Int(f(x), dfl);

                            /        
                           |        1
                           |  f(x) d-
                           |        x
                          /          

IntegrationTools:-Change(algsubs(dfl=t, G), t=dfl);

                           /          
                          |    f(x)   
                          |  - ---- dx
                          |      2    
                         /      x     

It looks a little funny to be plotting evalf(sum(...)) of something whose symbolic sum won't evaluate to a closed form result.

Why not plot evalf(Sum(...)) intsead? Why use twice as much memeory and wait three times as long, for an attempt at a symbolic sum which will fail symbolically (while succeeding numerically) at every plotted value?

If you want it with 2D Math of summation sign, for inert Sum, use command completion instead of getting it from the palette.

@alex_01 Just so that it is clear, the bugs mentioned here so far are entirely within SReg:-Reg and how it is coded, and not in Maple.

@alex_01 Looking at names appearing in u2, and uneval quoting them there, is not enough. What of name `a` used in the first argument to Fit? What of name `B`?

Look:

restart:

p:=proc(x,y) Statistics:-Fit(a+b*t+c*t^2, x, y, t); end proc:

X := Vector([1, 2, 3, 4, 5, 6], datatype=float):
Y := Vector([2, 3, 4.8, 10.2, 15.6, 30.9], datatype=float):

p(X,Y);
                                                                   2
         6.62999999999999 - 5.37464285714286 t + 1.53392857142857 t 

a:=1.23:

p(X,Y);

                                                      2       
              -2.08401785714286 t + 1.11205357142857 t  + 1.23

For some names which mint reports as being misused as if they were globals, having a previously assigned value can result not in an error message but in an undesirable or wrong result. This might not always happen in this instance, but it shows the potential danger.

And just as we'd usually classify such behaviour in Maple Library routines as bugs, we should consider it similarly in our own code. Exceptions are documented side-effects on some arguments, which are central to the functionality, like for optional third agument of `iquo`.

@PatrickT You ask, "Is there anything mathematically interesting about the magic Rubik cube?"

See this old web item on some of the group theory behind the cube.

It might be easier to superposition lines (with thickness of your choice) along the displayed portion of the axes, than to move all your DE plotting from maple over to matlab.

p:=plot3d(x^2+y^2,x=-8..8,y=-9..9,axes=box):

xlo,xhi,ylo,yhi,zlo,zhi:=-10,10,-10,10,-250,250:
xaxis:=plottools:-line([xlo,0,0],[xhi,0,0],color=black,thickness=2):
zaxis:=plottools:-line([0,0,zlo],[0,0,zhi],color=black,thickness=2):

plots:-display([p,xaxis,zaxis],axes=normal,view=[xlo..xhi,ylo..yhi,zlo..zhi]);

I left the y-axis untouched, to show the contrast.

@alex_01 How does this 2-stage method perform in time and memory, compared to using QPSolve in the best way?

Does it give you way to get those other special constraints, mentioned elsewhere, for some variables to take only certain values? Integers?

The timings are not accurate. If you change the order of the three timed calculations then the opposite conclusion seems to hold: that the regular computation (plain old eval) is faster than what you've compiled.

This is not surprising. The Compiler does not actually do anything to unevaluated lowercase int calls, or even evalf/Int. All that may happen is a callback into regular Maple to evaluate it.

Here are the timings I see in 64bit Maple 15.01 on Windows 7, when I do the three calls with your original order:

CodeTools:-Usage(CompiledH(1.0, 0.001, 3.0));
memory used=0.88MiB, alloc change=0.56MiB, cpu time=31.00ms, real time=31.00ms
                      11.9983264989999992

CodeTools:-Usage(eval(H, [y=1.0, a=0.001, b=3.0]));
memory used=0.55MiB, alloc change=383.93KiB, cpu time=0ns, real time=0ns
                          11.99832650

CompiledHGlobalEvalCover:=(y,a,b)->eval(CompiledH(y,a,b)):
CodeTools:-Usage(evalhf(CompiledHGlobalEvalCover(1.0, 0.001, 3.0)));
memory used=70.82KiB, alloc change=63.99KiB, cpu time=0ns, real time=0ns
                      11.9983264989999992

And here is what happens when I change the order, and do a complete session relaunch and restart:

CompiledHGlobalEvalCover:=(y,a,b)->eval(CompiledH(y,a,b)):
CodeTools:-Usage(evalhf(CompiledHGlobalEvalCover(1.0, 0.001, 3.0)));
memory used=0.88MiB, alloc change=0.56MiB, cpu time=32.00ms, real time=31.00ms
                      11.9983264989999992

CodeTools:-Usage(CompiledH(1.0, 0.001, 3.0));
memory used=2.64KiB, alloc change=0 bytes, cpu time=0ns, real time=0ns
                      11.9983264989999992

CodeTools:-Usage(eval(H, [y=1.0, a=0.001, b=3.0]));
memory used=0.55MiB, alloc change=383.93KiB, cpu time=0ns, real time=0ns
                          11.99832650

So it does look like regular evaluation of H at those values of a,b,y performs much the same at the same speed as what you've done specially, in a fresh session. You can also check that nothing very special has been accomplished by setting a trace on `evalf/int` before calling CompiledHGlobalEvalCover.

Yet another way is:

restart:

H := y^2+a^2+b^2 + Int(x->exp(x^6), 0..a,method=_d01ajc)+LerchPhi(y/(y+1),a,b):

CodeTools:-Usage(evalf(subs([y=1.0, a=0.001, b=3.0],H)));
memory used=0.76MiB, alloc change=0.56MiB, cpu time=31.00ms, real time=33.00ms
                          11.99832650

As far as I can tell, mosty what you've done is notice and use (in an overcomplicated way) the fact that evalhf and the Compiler'd runtimes can call back into Maple for things that they otherwise do not handle specially. (In evalhf's case, this can be done by wrapping with eval). In the Compiler's case, it can be done using lexical scoping, but then it'd be much easier to simply do it as:

restart:

H := y^2+a^2+b^2 + int(exp(x^6), x=0..a) + LerchPhi(y/(y+1),a,b):

Hfun := unapply(H,[y,a,b]):
Hfuncomp := Compiler:-Compile((y,a,b)->Hfun(y,a,b)):
Warning, the function names {Hfun} are not recognized in the target language

CodeTools:-Usage(Hfuncomp(1.0,0.001,3.0));
memory used=0.88MiB, alloc change=0.56MiB, cpu time=31.00ms, real time=32.00ms
                      11.9983264999999992

@lgault I'm having trouble following what exactly you want.

The original worksheet you uploaded had all that select(...,positive) stuff in it, and so I was trying to go along with that.

I was hoping that you'd be able to take the worksheet I uploaded as a starting point, to see some techniques, and adjust as required.

Here's another one. Note that if you just want to plot both of the two solutions for r3dot then a procedure r3dotfunc like I've included is not necessary (or efficient!).   jelinekmod2.mw

@lgault I'm having trouble following what exactly you want.

The original worksheet you uploaded had all that select(...,positive) stuff in it, and so I was trying to go along with that.

I was hoping that you'd be able to take the worksheet I uploaded as a starting point, to see some techniques, and adjust as required.

Here's another one. Note that if you just want to plot both of the two solutions for r3dot then a procedure r3dotfunc like I've included is not necessary (or efficient!).   jelinekmod2.mw

If he wants to round, I wonder whether it's to the nearest.

> solve(3*k-8=0,k):

> round(%), floor(%);
                              3, 2

If he wants to round, I wonder whether it's to the nearest.

> solve(3*k-8=0,k):

> round(%), floor(%);
                              3, 2

I expect that Robert is on the right tack to correctly guess the intention, with floor.

But I'll submit a joke answer, because the way the question was asked is terribly unclear.

> msolve({3*k-5=0},2);

                            {k = 1}