@Kitonum It may be worth noting that the optional second argument to `combine` may be useful in such cases, in order to restrict what kinds of combining are done if additional kinds of terms are present. Eg,

combine(y(x) = 1/3/2^x+_C1/(3^x)^2 + cos(x)*sin(x));   
    
                               x  (2 x)                   x      (2 x)   (-x)  (-2 x)
                y(x) = 1/6 (3 2  3      sin(2 x) + 6 _C1 2  + 2 3     ) 2     3

combine(y(x) = 1/3/2^x+_C1/(3^x)^2 + cos(x)*sin(x), power);

                                     (-x)
                                     2            (-2 x)
                              y(x) = ----- + _C1 3       + cos(x) sin(x)
                                       3

@samira moradi 

I suspect that the "rsquared" result may only be available when the target expression is linear in the parameters. Additional computed results and statistics may be obtained using the `solutionmodule` output (or, with a list of strings as the rhs of the `output` option). Also see the help page for the Statistics:-Fit command.

restart;

X := a * (-0.6356560300e-1*ln(Y+200.+17.54410643*Y^(2/3)+102.5985568*Y^(1/3))+
          0.6356560300e-1*ln(Y+200.)-.2201977080*arctan(.1974510146*Y^(1/3)
          -.5773502693)+.1096187623);

vx := <1500, 1340.00, 1135.00, 982.00, 884.15, 704.72, 520.00, 287.00, 70.00, 0.>:
vy := <0., 4.28, 7.77, 7.30, 9.00, 13.00, 25.85, 28.91, 38.48, 50.00>:

f:=Statistics:-Fit(X, vy, vx, Y, output=solutionmodule):

f:-Results("parametervalues");

f:-Results("leastsquaresfunction");

f:-Results("residualsumofsquares");

f:-Results("residualmeansquare");

f:-Results("rsquared");

f:-Results("rsquaredadjusted");

#f:-Results();

p1:=plot(vx,vy,style=point):
p2:=plot( [f:-Results("leastsquaresfunction"),Y,Y=0..50],color=red):
plots:-display(p1,p2);

@Traruh Synred Why not upload the xxx_MAS.bak file (or whatever) that is non-empty?  I mean, if it does not open properly, even after renaiming the file's extension from .bak to .mw say.

@Annonymouse I don't see a way to get the slightly larger asterisk that is tighter against the `y` (as Carl showed), without the subscript being set too far to the right. That leaves mostly the examples where the asterisk is slightly smaller and higher (as an exponent), but at least not too far right. It's tricky because the asterisk gets a higher baseline.

restart;
with(DEtools):
NLC := diff(y(t), t) = k*(Am-y(t));
Am := 20; k := .1;
ivs := [y(0) = 10, y(0) = 30, y(0) = 50];

DEplot(NLC, y(t), t = 0 .. 20, ivs,
       tickmarks = [default,
                    [10 = `y*__1`,
                     15 = `y*`[1],
                     20 = `#msubsup(mi("y"),mn("1"),mo("*"))`,
                     30 = y[1]^`*`,
                     40 = y[1]^`∗`,
                     50 = y[1]^`*` ]],
       font = [default, default, 15], view=7..50);

You could try using the entity lowast instead of ast, as I did above at tick y=40. But on my Linux that doesn't look pretty.

An additional wrinkle is that the y-view is not automatically expanded below to fit the y-tickmarks. So if your specified font makes the tick at y=10 too large then it may not get displayed unless you force a taller y-view.

Use the Big Green Arrow icon in the mapleprimes responses editor's menubar, to upload a copy of the corrupted worksheet.

acer

@tomleslie This is not the first post by this member with a mish-mash of incorrect usage (including improper use of MTM:-diff ).

Since the member does not seem capable of grasping that some of the problems start with the line with(MTM) then I don't see why anyone would bother to struggle more to help.

@Christopher2222 If the compiled proc cfix gives you problems you could use the slower evalhf(fix(...)) call instead.

I'm not sure that the success is so remarkable. The uniformly distributed noise is likely to leave quite a bit of local information (when it exists before the noise is added...).

Here is a refinement, where the width of the subarea used for interpolation is a supplied option. Also, if a pixel appears undamaged (value<1.0) at a particular layer then accept that value.

fiximgwidth.mw

With 90% damaged pixels, a slightly blurred reconstruction looks pretty good, using 4 for the width (ie, the 9x9 subarea around each pixel as opposed to width 1 for a 3x3 subarea).

Also, the process may be repeated. Ie, compare,

cfixed4:=Array(1..n,1..m,1..3,datatype=float[8],order=C_order):
CodeTools:-Usage( cfix( damaged2, cfixed4, n, m, 4 ) ):
Embed([img,damaged2,cfixed4]);

with,

cfixed4:=Array(1..n,1..m,1..3,datatype=float[8],order=C_order):
CodeTools:-Usage( cfix( damaged2, cfixed4, n, m, 4 ) ):
CodeTools:-Usage( cfix( copy(cfixed4), cfixed4, n, m, 4 ) ):
Embed([img,damaged2,cfixed4]);

or,

cfixed4:=Array(1..n,1..m,1..3,datatype=float[8],order=C_order):
CodeTools:-Usage( cfix( damaged2, cfixed4, n, m, 2 ) ):
CodeTools:-Usage( cfix( copy(cfixed4), cfixed4, n, m, 2 ) ):
Embed([img,damaged2,cfixed4]);

@Don_Caraota Note that DirectSearch:-SolveEquations can return local minima which are not actual roots (say, in the case that no roots are found). You may have to take care to proprocess and analyze residuals yourself, in order to ensure that you avoid this case.

@Earl If I had two lists N and M representing out-of-order pairs then I'd be tempted to use simple angle-bracket notation to make them into an n-by-2 Matrix, which could still be re-ordered by indexing with [sort(N, output= permutation)] where N is the independent data. The plot command would handle that result.

@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.