## 19447 Reputation

14 years, 312 days

## something...

I do not know whether the expression V below is right, because I do not know whether this substitution for 0.6 in your M is right, or even whether M is right. (It may not agree with what Reuben has mentioned.)

I replaced 0.6 (which presumably stands in for a/L) with the parameter name p.

But this may still show you some numeric rootfinding and related plotting methods.

 > restart;
 > M := Matrix(8, [[0, 1, 0, 1, 0, 0, 0, 0], [1, 0, 1, 0, 0, 0, 0, 0], [0, 0, 0, 0, -sin(x), -cos(x), sinh(x), cosh(x)], [0, 0, 0, 0, -cos(x), sin(x), cosh(x), sinh(x)], [sin(p*x), cos(p*x), sinh(p*x), cosh(p*x), 0, 0, 0, 0], [0, 0, 0, 0, sin(p*x), cos(p*x), sinh(p*x), cosh(p*x)], [cos(p*x), -sin(p*x), cosh(p*x), sinh(p*x), -cos(p*x), sin(p*x), -cosh(p*x), -sinh(p*x)], [-sin(p*x), -cos(p*x), sinh(p*x), cosh(p*x), sin(p*x), cos(p*x), -sinh(p*x), -cosh(p*x)]]):
 > V:=simplify(combine(simplify(LinearAlgebra:-Determinant(M))));

 > plot(eval(V,p=0.6),x=0..6*Pi,size=[500,250],view=-1..1,xtickmarks=decimalticks);

 > fsolve(eval(V,p=0.6),x=0..6*Pi,maxsols=20);

 > U:=proc(ee) option remember; local x;   if not ee::numeric then return 'procname'(args); end if;   [fsolve(eval(V,[:-p=ee,:-x=x]),x=0..6*Pi,maxsols=6)]; end proc:

 >

## numpoints, grid...

In my Maple 2015 it appears as if the numpoints option of SurfaceOfRevolution is only controlling the values used for the (blue) function curve, whose appearance you have suppressed by passing the showfunction=false option.

And since that detail also appears to be controlled (overridden) by the functionoptions choice, then I don't really see much merit in how it uses the numpoints option.

I do see an effect from the following, however, by temporarily adjusting the "default" for the grid option.

(I suspect that you may find that the grid values get used for the number of points used for the independent parameters in cylindrical coordinates. Hence they may serve the natural purposes.)

Again, this is in Maple 2015.

 > restart;
 > with(Student:-Calculus1):
 > f := 3+surd(abs(sin(x)), 5)*signum(sin(x)):
 > orig:=plots:-setoptions3d(grid): # [49,49] plots:-setoptions3d(grid=[490,49]); SurfaceOfRevolution(f, x=0..10*Pi, output=plot, caption="", showfunction=false); plots:-setoptions3d(grid=orig);

 > op([1, 1], %);

 >

## via piecewise (parametric solve)...

Member vv's nice method of substitution of the floor call by a name might be modifed, so that isolve finds integer solutions for the dummy name rather than having to pepper the new formula with values from an ad hoc range.

It handles at least these two examples, with only one substitution equation. I'm sure that it could benefit from robustification.

I displayed the intermediate piecewise result, since it helps illustrate how some progress was made (you could also evalf that piecewise, to see it even more clearly).

 > restart;
 > P := proc(A,B) local S;      if A={} then NULL;      else S:=isolve(A[]);           if S=NULL then NULL;           else eval(B,S[]);           end if;      end if; end proc:
 > Q := proc(k) local i,j,kk;   kk := PiecewiseTools:-ToList(k):   seq(`if`(kk[i][2]=[],NULL,            P({solve({seq(not(kk[j][1]),j=1..i-1),kk[i][1]})},            kk[i][2])),i=1..nops(kk)); end proc:

 > f := x^2+floor(x)-10;

 > K := solve({eval(f,[floor(x)=n]),             n<=x, x

 > Q(K);

 > g := x^2+2*x+floor(x^2+x)-25;

 > K := solve({eval(g,[floor(x^2+x)=n]),             n<=x^2+x, x^2+x

 > Q(K);

 >

## viewpoint...

Another choice -- if you want to rotate each figure separately -- is to use the viewpoint option.

And, once again, a crude way to slow down the animation (including its gif export) is to repeat frames.

You might want to consider a single color (with glossiness and lighting) instead of shading=zhue, if you plan on exporting to .gif format.

 >
 >
 >
 >
 >
 >
 >
 >
 >
 >
 >

 >

## polygons...

The extrusion is done using POLYGONS substructures (rather than GRID or MESH, say), so I don't think that you would be able to get a surface with wireframe grid directly.

You can use overrideoption to get various other styles that are relevant for POLYGONS, though. This affects the CURVES as well as the POLYGONS.

You could use subsindets if you wanted to target just the POLYGONS and leave the CURVES alone (if your choice would be valid for them and otherwise alter them).

 > with(plottools):
 > p := plot(x^2,x=-5..5, thickness=3, adaptive=false, numpoints=13):
 > extrude(p, 1..2); indets(%,specfunc(STYLE));

 > plots:-display(extrude(p, 1..2), overrideoption, style=polygonoutline); indets(%,specfunc(STYLE));

 > plots:-display(extrude(p, 1..2), overrideoption, style=line); indets(%,specfunc(STYLE));

 > plots:-display(extrude(p, 1..2), overrideoption, style=pointline, symbolsize=25); indets(%,specfunc(STYLE));

 > plots:-display(extrude(p, 1..2), overrideoption, style=patchcontour); indets(%,specfunc(STYLE));

 >

## using the MathApp's code...

Here I've re-used the code from the MathApp itself so as to retain the aspect ratios and relative placement per frame (and a scaling procedure PP to unify the frame view).

One of the few changes I made was to allow the randomize seed to be passed to the Reset procedure, which affects the shuffling randomization of the colors.

 > restart;

Source for FibonacciNum module is based closely on that of the MathApp,
and is in the worksheet's Startup Code.

 > PP := proc(P)   local data,xmin,xmax,ymin,ymax;   data := indets(P,specfunc(anything,VIEW))[1];   (xmin,xmax):=[lhs,rhs](op(1,data))[];   (ymin,ymax):=[lhs,rhs](op(2,data))[];   plottools:-transform((x,y)->[(x-xmin)/(xmax-xmin),                                (y-ymin)/(ymax-ymin)])(P); end proc:
 >
 > plots:-display(PP(FibonacciNum:-Reset(1234))\$5,                seq(PP(FibonacciNum:-NextStep())\$5,i=1..23),insequence=true);

I used repeated frames to slow it down. If you have a animated .gif player which allows you to adjust the speed then there's no need to use repeated frames.

## transformation...

Another possibility for your Maple 13 is to transform a result from odeplot using your known procedure FAK.

You could do that in one line (or in two steps, if you want to save the intermediate plot).

In older versions such as yours the odeplot curve renders thinly in places, which you may be able to make up for using the refine=1 option (which Preben also utilized).

(Although, for your given FAK, Preben's solution to utilize piecewise seems much more sensible.)

 >
 >
 >

 >

 >

 >
 >

You can find older Posts and Questions on this topic.

For example,

## various...

Here are various versions, with the rest in black (rather than just default blue for output), or background effects as in the original question, etc.

Mix and match as wanted.

note: In the actual Maple GUI the 2nd and 3rd versions below render properly with the 5's having white foreground as well as the red background. Mapleprimes' backend doesn't render them properly.

 > a:=[1,3,4,5,3,4,9,4,5,3,9,2,3,4,2,5,21,32,22,12,15,3,2,5,4]:

 > map(x->Typesetting:-mn(sprintf("%a",x),mathcolor=`if`(x=5,"red",black)),a);

 > map(x->Typesetting:-mn(sprintf("%a", x),                        `if`(x = 5,[mathbackground="red",mathcolor="white"][],                             NULL)), a);

 > map(x->Typesetting:-mn(sprintf("%a", x),                        `if`(x = 5,[mathbackground="red",mathcolor="white"][],                             mathcolor="black")), a);

 >

## scaled...

You can scale the frames to a common x-y range, so that the conventional  animation (from plots:-animate, or collection displayed with the insequence option) renders them more like the Explore frames.

FractalesAnim_ac.mw

For example, using procedure PP to scale all the frames to [0..1]x[0..1],

```PP := proc(P)
local data,xmin,xmax,ymin,ymax;
data := indets(P, Array)[1];
xmin,xmax := [min,max](data[..,1])[];
ymin,ymax := [min,max](data[..,2])[];
plottools:-transform((x,y)->[(x-xmin)/(xmax-xmin),
(y-ymin)/(ymax-ymin)])(P);
end proc:

plots:-display(
seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
Fractals:-LSystem:-LSystemExamples:-KochCurve,a))\$5,
a=1..5),insequence);```

```plots:-display(
seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
Fractals:-LSystem:-LSystemExamples:-Carpet,a))\$5,
a=1..4),insequence);```

```plots:-display(
seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
Fractals:-LSystem:-LSystemExamples:-Rings,a))\$5,
a=1..4),insequence);```

```plots:-display(
seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
Fractals:-LSystem:-LSystemExamples:-Seaweed,a))\$5,
a=1..4),insequence);```

```plots:-display(
seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
Fractals:-LSystem:-LSystemExamples:-GosperCurve,a))\$4,
a=1..5),insequence);```

## possible reason...

The most likely scenario is that procedure X called searchtext with invalid arguments by mistake -- in other words, a buggy situation overlooked by whoever wrote procedure X.

There are some other variations on the theme (eg. rethrowing errors of a similar sort, but made at a deeper level).

But it's difficult to say for sure, because you have, unhelpfully, omitted the example in which this arose.

## something like this...

It is not clear from you description what you are trying to do. Is it something like either of these?

 >
 >
 > The Vectors X and Y are the same. so plotting Y against X produces a straight line.

 > Each Vector could be plotted as a separate curve. I use a different style for each, since they overlap (because the points are the same).

 >

## lack of simplification...

The problem is a lack of simplification, such that a verification fails.

As one of some preliminary steps, the free Vector v2 in cartesian coordinates is used to generate a new rooted Vector, and then a coordinate transformation is done. Unfortunately the coordinates of the ensuing extracted root-point of that new rooted Vector is not in simplified form. A later call to verify produces a spurious false result when comparing against the root-point of the rooted Vector v1, and a somewhat unhelpful error message is emitted.

The following commands are some of these internal steps, done under VectorCalculus:-DotProduct for the example at hand. The following rooted Vector vv2 is generated by MapToBasis, executed under PrepareBinaryVectorOp. The verify call is done under ValidateVectorSpaces.

 > restart;
 > with(VectorCalculus):
 > v1:=RootedVector(root=[1,Pi/6,0],[0,0,1],spherical[r,theta,phi]);

 > GetSpace(v1):-GetRootPoint();

 > v2:=Vector(3, [0,2,1], attributes = [coordinates = cartesian[x,y,z]]);

 > c1:=spherical[r,theta,phi];

 > inorigin:=Vector(3, [1,1/6*Pi,0], attributes = [coordinates = spherical[r,theta,phi]]);

 > vv2 := VectorCalculus:-MapToBasis(v2,c1,inorigin);

 > # # Hmm. This will cause the problem. # GetSpace(vv2):-GetRootPoint();

 > # # This will do better. # simplify(GetSpace(vv2):-GetRootPoint());

 > # # Oops. # verify(GetSpace(vv2):-GetRootPoint(),        GetSpace(v1):-GetRootPoint(),        ':-Vector');

 > # # OK # verify(simplify(GetSpace(vv2):-GetRootPoint()),        GetSpace(v1):-GetRootPoint(),        ':-Vector');

 >

I could probably construct a hot-fix patch. I'm trying to figure out whether it would be best to strengthen the call to verify, or simplify the stored root-point when constructed by MapToBasis.

In the other example, the simplified coordinates happen to be produced directly, and the straight verification succeeds.

 > restart;
 > with(VectorCalculus):
 > v1:=RootedVector(root=[1,Pi/4,0],[0,0,1],spherical[r,theta,phi]):
 > GetSpace(v1):-GetRootPoint();

 > v2:=Vector(3, [0,2,1], attributes = [coordinates = cartesian[x,y,z]]):
 > c1:=spherical[r,theta,phi]:
 > inorigin:=Vector(3, [1,1/4*Pi,0], attributes = [coordinates = spherical[r,theta,phi]]):
 > vv2 := VectorCalculus:-MapToBasis(v2,c1,inorigin):
 > GetSpace(vv2):-GetRootPoint();

 > verify(GetSpace(vv2):-GetRootPoint(),        GetSpace(v1):-GetRootPoint(),        ':-Vector');

 >

## T undefined...

It should be clear to you from the error message that the problem is that T is not assigned and doesn't provide a numeric value. It looks like you inadvertantly omitted it.

There are other efficiency problems, but you need to fix the T issue first. You should know the formula to do one iteration by Newton's method. See below.

I am leaving most of the rest as it was, and not addressing the inefficiency of augmenting a set with each new plot, or cleaning up the role of A, and so on.

I also made a change to allow the initial point to be passed (xinit).

 > restart;
 > NewtonM:= proc(f, a, b, xinit, N, e)                local n, tps, x0, E, A, x1, ps, x, j,  pf, pic, T;                uses plots:      n:=0: tps:={}:    T := unapply(x-'f'(x)/D(f)(x),x);    x0:=xinit: E:=evalf(abs(f(x0))):    while ( E>e and n
 > NewtonM(x->x^2-2,1,40,38.0,10,1e-9);

 > evalf(2^(1/2));

 >

## context-panel...

If you are using 2D Input mode then the open context-panel (right panel) may be trying to call ifactor on your 123!+1 (after evaluating it). There is a timeout of a few seconds, but for some inputs it might still seem sluggish.

Try closing (collapsing) the right-panel, using the double chevron that looks like << at the right side of the menubar.

note. I will submit a bug report -- at the very least there ought to be a more sensible check on whether to try ifactor, or a way to disable it while keeping the context-panel open.

 The following command will disable the subexpression menu parts that appear at the top of the context-panel, but it will allow the lower context-menu portion to work as usual.