@Kitonum When y<0 this is not real-valued (by Maple).

@mmcdara Your original question did not mention that the solutions you were interested in had to be purely real.

If you apply the evalf command to sols you will get float approximations which might make the nonreal nature of the computed results more immediately clear to you.

You mentioned spheres. If you complete the square wrt to x, y, and z then you can put the equations into a form where that is more easily recognizable. For example,

cs:=Student:-Precalculus:-CompleteSquare:

eq1 := x^2+y^2+z^2-134*x+800*y-360*z+31489=2:
eq2 := x^2+y^2+z^2-934*x+900*y-370*z+321789=2:
eq3 := x^2+y^2+z^2-614*x+1350*y-1110*z+70048=97:

cs( (lhs-rhs)(eq1) );
                                                 2            2           2
                                        (z - 180)  + (y + 400)  + (x - 67)  - 165402

cs( (lhs-rhs)(eq2) );
                                                2            2            2
                                       (z - 185)  + (y + 450)  + (x - 467)  - 133027

cs( (lhs-rhs)(eq3) );
                                                2            2            2
                                       (z - 555)  + (y + 675)  + (x - 307)  - 787948

Note that the results from eq2 and eq3 agree with the radii you mentioned, but the result from eq1 does not agree with your claim of a radius of 2042. Recall that your original question had commas instead of equal signs. Perhaps the integer values you used to write eq1 were not all written down as you intended. Of course it's possible that there are only nonreal solutions, according to your actual data (but it's hard to comment, without knowing the intended data).

@Lola I don't see any link to an uploaded sheet.

You may need to ensure that the accuracy attained for the numerical integration is at least as fine as the optimality tolerance requested by the NLPSolve call, so that the optimization method can be convinced that the result is converging.

The accuracy of the numerical integration is controlled by Int's `epsilon` option (and sometimes its digits option needs to be adjusted as well). In the trickiest case you may need to raise working precision of the numerical integration while keeping the working precision used by NLPSolve coarser.

This is just a guess as to what may be causing you issues. If you have difficulty with applying vv's suggestion then please upload a full worksheet to reproduce.

acer

@vv That's quite close to what I had in mind. Sorry if I was fuzzy in my description -- I couldn't recall exact details of evaluation in my earlier description.

On my 64bit Maple 2016.1 for Linux I see a speed of 8 sec versus 12.5 sec when I compare it for n=10000 and 100 frames, in the attached worksheet.

The difference seems to get more pronounced as the number of frames increases, for that n. The bytesused shows a large difference in garbage-collected memory.

I forced the Compile, to make sure that step was ok (otherwise I sometimes got an in-memory compilation failure similar to something Carl mentioned last week in a separate Question).

I executed the whole sheet together, using the !!! triple-explcam from the main menubar.

I included a trivial Compile operation after restart, to try and eliminate overhead of initial use of the compiler's runtime.

cup.mw

For 3D plotting there may be an additional wrinkle: I sometimes see the GUI itself slow down as the GUI (not the kernel) leaks a little memory on (large?) 3D (point?) plots. As the java process's resident memory increases the GUI may get slower to render.

 [edited[ I should mention that one likley could not make a a traditional animation with the appliable module (which used the inplace techniques) in the attached worksheet unless calls to it were wrapped in a call to copy. Because otherwise all frames might appear the same.

And to address Carl's question about VIEW -- Explore doesn't do any special to combine or expand the VIEW, but simply displays each frame as is. An expanding VIEW mechanism could be made part of a smart module, though, augmenting the total VIEW by comparing a running local to what each subsequently generated frame demanded.

@Thomas Richard Did you intend something more like this?

Download inertnumerdenom.mw

As usual, vv is correct on all fronts. Thank you, sir.

Have you tried declaring n as a local and assigning it appropriately? Or passing it in, if the dimensions of the rtable will depend upon it? And (long shot) without the option autocompile?

How about the inmem=false option for Compile:-Compile, assuming that you have a MSVC++ that allowed Compiler:-Compile to work on your older Maple versions for your 64bit Windows.

It compiles and works for me on my 64bit Maple 2016.1 on 64bit Windows 7 Pro, using suitable local n assigned to the right value, or picking up a global n assigned the integer value used to build the rtables. It also works for me with or without the inmem=false option.

I could only get it to produce an error if n had no value for it to access. But it was a related error message. I haven't been able to reproduce the error message you show.

acer

@Carl Love For fun. Adjust to taste.

clexplore.mw

@vv The delay property of a Plot Component relates to playing a "traditional" animation within the component. But Explore plays (renders) the individual plots only as fast as it can generate them, and does not precompute a sequence of frames (traditional animation). So Explore is creating the plots and playing them on demand, so to speak. As far as I know the delay property of a Plot Component does not affect the rendering when the value property is simply set to a particular plot (which is what Explore does, repeatedly).

Above I was talking about inserting a call to Threads:-Sleep, inside the procedure P which is Explored.

If, on the other hand, you have a traditional animation (seq of plots, in say a _PLOTARRAY structure, the kind that can be played using say plots:-display and option insequence=true) you can alternatively play it programatically by setting it as the value property of an embedded Plot Component and then setting the component's play property to true. If you do that then you could also set the component's delay property programmatically. See here for an example of that.

Another way to play a traditional animation within an embedded Plot Component is to programatically embed the whole thing into a worksheet. See a relevent example in the ?examples,ProgrammaticContentGeneration help page of Maple 2016, where it defines (in a code-edit region) and then calls an appliable module named EmbedAnim. I suppose that command could be enhanced to also provide a dial for the embedded Plot Component's delay property.

As Carl mentions in this thread, a traditional animation (plots:-animate(...) or plots:-display(..,insequence=true)) has the virtue that it can be readily exported to animated .gif file. And, with all the frames being precomputed it can usually play them quite quickly. Another benefit is that, with the frames all computed in advance, the total view is known (but sometimes that's a drawback, that the view is fixed). With Explore the view option must be supplied, or else it can change.

In Maple 2016 the Explore command has new options to "record" plots it generates to a supplied global name, used as a table. So, once one obtains desirable values of various fixed parameters then a traditoinal animation can be computed by "playing" the exploration on the remaining animated parameters. The global name of the table used to record the explored plots can then be converted to a traditional animation.

@Markiyan Hirnyk To make it slower you could add a call to Threads:-Sleep, inside `P`. The duration to sleep could even be a parameter of `P` and itself a non-animated Explore parameter. It might be nicest if the mechanism was as fast and efficient as possible, to give any sleep-delay control even more power and choice. 

@Carl Love Yes, thanks, I've seen it. I like the name Starlings.

It reminds me of another acceleration trick that might be possible with that Explore above.

vv's code acts inplace on `x` and `v`. It should be possible to create a 2D `PLOT` structure with a (uneval'd?) reference to a named n-by-2 float[8] Matrix whose columns are the x and y Vectors. And the first two arguments to `step` could instead be that single n-by-2 Matrix.

Basically, I mean that my procedure P could return PLOT(M,...) or whatever. So the kernel wouldn't have to garbage collect each plot structure's data rtables. Just an idea. And nothing else changes in the PLOT structure, so there's little need to have to call the Library `plot` command each time. It's only the data that changes -- updated inplace by `step`.

I used that technique once in an old mapleprimes thread, which I can't find now. I don't think it was this, because I hazily recall Joe Riel commenting.

Also, if I recall the Statistics:-Sample command now offers inplace re-use of a Vector container. So F and E might be re-used as well.

Just ideas. I'm not sure how much speedup there might be.

@Markiyan Hirnyk I haven't made Carl's suggested adjustments.

Also, certain parameters like n and mu could be made other (non-animated) parameters of the call to Explore.

The key thing is that this doesn't have `num` a fixed number of distinct frames, as does a looping (cycling) traditional animation.

It could also be all put into a single appliable module. As an exploration is could be easily made into a so-called "MathApp".

restart;

FE:=proc() global F,E; #friend,enemy
  F,E:='LinearAlgebra:-RandomVector(n,generator=1..n,datatype=integer[4])' $2;
end proc:

step:=proc(x::Vector(datatype=float[8]),y::Vector(datatype=float[8]),
      E::Vector(datatype=integer[4]),F::Vector(datatype=integer[4]))
local i::integer[4],ex::float[8],ey::float[8],ed::float[8],
                    fx::float[8],fy::float[8],fd::float[8];
for i to n do
  ex:=x[E[i]]-x[i];ey:=y[E[i]]-y[i]; ed:=sqrt(ex^2+ey^2);
  fx:=x[F[i]]-x[i];fy:=y[F[i]]-y[i]; fd:=sqrt(fx^2+fy^2);
  x[i] := 0.995*x[i] - 0.01*ex/(ed+0.01) + 0.02*fx/(fd+0.01);
  y[i] := 0.995*y[i] - 0.01*ey/(ed+0.01) + 0.02*fy/(fd+0.01);
od;
end proc:
cstep:=Compiler:-Compile(step):

P:=proc()
  to mu do cstep(x,y,E,F) od;
  if rand(1..10)()=1 then FE() fi;
  plot(x,y,style=point,background="#333333",axes=none,view=[-2..2,-2..2],
       symbolsize=2,color="DarkOrange");
end proc:

n:=1000: mu:=10:
x,y:='LinearAlgebra:-RandomVector(n,generator=-1.0 ..  1.0,datatype=float[8])' $2:
FE():

Explore(P(xx),parameters=[[xx=0..1,shown=false,animate]],autorun,loop);

@Carl Love Is not view a global plot option, and thus covered on the ?geometry,draw help page by the bullet point about globalopts in the Description section?

I find it poor that the Calling Sequences section on that help page don't show the general forms like

  draw([ obj_1( localopts_1 ), ..., obj_n( localopts_n )], globalopts)

as mentioned in the second bullet point of the Description section.

My first attempt too was to try and pass the double default view, and it seems a bug that doesn't work.

Are you separating them by a comma?

If you separate them by a space, in 2D Input, then that will get interpreteted as multiplication.

acer