## 18951 Reputation

14 years, 276 days

## 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);
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.

## example...

There are a great many ways to do this.

One simple way is to use a list of the expressions (y(x) instantiated at the R values). The list can be constructed using the seq command. The list gets passed to a single call to the plot command.

That will color each curve differently, using the default color palette. But you could also specify the colors.        ## Explore...

You didn't state that it had to have maximal area, so I interpret your question to mean that you want a parametrized solution.

Here is one way to do that, using Explore,

```Explore(plots:-display(
plots:-implicitplot(x^2/a^2+y^2/b^2-2*m*x*y/a/b+m^2=1,
x=-a..a,y=-b..b,gridrefine=3,rational),
plottools:-polygon([[-a,-b],[-a,b],[a,b],[a,-b]],color=white),
scaling=constrained, size=[500,500]),
parameters=[[m=-0.99999..0.99999, placement=bottom],
[ a=1.0..5.0, placement=right, orientation=vertical],
[ b=1.0..5.0, placement=right, orientation=vertical] ],
initialvalues=[m=0.0, a=2.0, b=1.0]);
```

You could also do some algebra and utilize plottools:-ellipse.

ellipse_rectangle.mw

Or, using plots:-animate ,

```F := proc(m,a,b)
plots:-display(
plots:-implicitplot(x^2/a^2+y^2/b^2-2*m*x*y/a/b+m^2=1,
x=-a..a,y=-b..b,gridrefine=3,rational),
plottools:-polygon([[-a,-b],[-a,b],[a,b],[a,-b]],color=white),
scaling=constrained);
end proc:

plots:-animate(F, [m,2.0,1.0], m=-0.99999..0.99999,
frames=50, paraminfo=false);``` You might also want to plot the tangent points (using +/- m*a and m*b).

Of course there are other ways to obtain a similar effect (using an angle as parameter, etc).  And in Explore you might use only one of the rectangle sides' lengths as a parameter, or neither.

## range...

They are in fact present in your plot, but they are too thin and short to be distinguished, or too dark and close to the x-axis.

You can shorten the x-range (which reduces the overall y-range and thus makes the 0 and 2*x^2 distinguishable from each other). And you can add thickness to make the 0 plot distinguishable from the x-axis. For example,

```plot({0, 2*x^2, 2*x^2 - 2*x^3 + 8/3*x^4 - 4*x^5},
x = -1 .. 1, thickness=4,
color = ["LightGreen", "CornflowerBlue", "Burgundy"]);``` You could also change use the view option to force the visible y-range. For example, using a slightly wider x-range and a forced view,

```plot({0, 2*x^2, 2*x^2 - 2*x^3 + 8/3*x^4 - 4*x^5},
x = -2 .. 2, thickness=4, view=-10..10,
color = ["LightGreen", "CornflowerBlue", "Burgundy"]);``` And here that is with the original x-range and another choice of y-range,

```plot({0, 2*x^2, 2*x^2 - 2*x^3 + 8/3*x^4 - 4*x^5},
x = -10 .. 10, thickness=3, view=-1e3..1e3,
color = ["LightGreen", "CornflowerBlue", "Burgundy"]);``` You can even specify the thicknesses to be different for each curve. For example,

```plot([0, 2*x^2, 2*x^2 - 2*x^3 + 8/3*x^4 - 4*x^5], x = -2 .. 2,
thickness=[4,1,1],
color = ["LightGreen", "CornflowerBlue", "Burgundy"]);``` And you can mix some of those effects.

But it is not reasonable to expect all three of those to stand out visually on a range of x=-10..10, with a full y-range on a non-logarithmic y-axis, and the colors almost as dark as the x-axis. Something could be conceded.

## u1hat, u2hat...

You didn't tell us the original form of u1hat, so I've guessed.

But the key thing, I expect, is that you needed to figure out how to utilize the dsolve result while plotting the expression u1hat that contained calls like A__2(t) or B__2(t).

 > restart;
 > deqs := {-2/9*diff(B__2(t),t,t)-2/90*diff(B__2(t),t)          -10.15209016*B__2(t)+2.124529588*A__2(t),          -2/9*diff(A__2(t),t,t)-2/90*diff(A__2(t),t)          -0.4863996160*B__2(t)-2.918397696*A__2(t)          -sin(1/10*t),          A__2(0)=0, B__2(0)=0, D(A__2)(0)=0, D(B__2)(0)=0}:
 > sols := dsolve(deqs, numeric, range=0..50, output=listprocedure):
 > AA__2 := eval(A__2(t),sols): BB__2 := eval(B__2(t),sols):
 > # # You didn't show us what this was, originally. # u1hat := (x^2-x)*A__2(t); > U1H := unapply(subs(A__2=AA__2, u1hat),[x,t]); > xmax := 5:
 > plot3d(U1H, 0..xmax, 0..50); > ## These behave the same. #plots:-odeplot(sols,[t,A__2(t)]); #plot(AA__2, 0..50);
 >

It could be adjusted if your u1hat expression contained calls to derivatives of A__2 or B__2. Please just ask in that case. But provide full details.

## not generally true...

Your two expressions are not equal for all complex values of the unknowns. Here is an example set of values for which they are the negation of each other.

```Is_eq := II[mu]/sqrt((omega__r^2 + omega__rK^2)*sigma^2
/(sigma^2*omega__rK^2 + omega__r^2)):

Is_eq2 := II[mu] * sqrt((1+(omega__r/(sigma * omega__rK))^2)
/(1+(omega__r/(omega__rK))^2)):

evalc(eval([Is_eq, Is_eq2],
[II[mu] = 1, omega__r = 1,
omega__rK = 1, sigma = I*sqrt(2)/2]));

[-1/2*I*2^(1/2), 1/2*I*2^(1/2)]
```

It is not generally true that sqrt(1/x) is equal to 1/sqrt(x) . It is true for all nonnegative real x, but not for all complex x

If all the unknowns within the radicals of your expressions are real then (since the arguments inside the radicals would then happen to be nonnegative) the expressions will be equivalent. That is a sufficient condition.

 I adjusted the wording of the previous two paragraphs, to more closely match the situation in the OP's expressions and to clarify.

Now, the is command is usually as strong as simplify (and friends). But very rarely it will need a little prod. This seems to be one of those cases, at least for the version Maple 2020.0 in which I executed this.

So we can do the comparison under the assumption that the unknowns are real (and we can help the is command a bit).

```simplify(Is_eq - Is_eq2) assuming real;
0

is(simplify(Is_eq = Is_eq2)) assuming real;
true

true

is(evala(Is_eq = Is_eq2)) assuming real;
true

# Is it rare that such an extra simplification
# step is required.

is(Is_eq = Is_eq2) assuming real;
FAIL

is(Is_eq - Is_eq2 = 0) assuming real;
FAIL```

Note. I changed I[m] to II[mu] since the name I is special and denotes the imaginary unit by default and you didn't declare it as local.

 I shall log a bug report on the case where the is command needed an simplification extra step. (By which I mean the extra simplification step, not the assumption.)

## literal...

A somewhat close conversion is as follows,

```r,theta := (abs,argument)(1+I):
plots:-animate(
a->plot(((r^(1/a))*~([cos,sin]))~([seq]((2*Pi*k+theta)/a,k=0..a)),
style=pointline, symbol=solidcircle, symbolsize=25,
gridlines, thickness=3, scaling=constrained, color=blue,
labels=[Re,Im], labelfont=[Helvetica,bolditalic,20]),
[a], a=1..20, frames=20, paraminfo=false);
``` But it is not exactly the same, since your Explore example runs with the default of 50 frames.

Note that integer values for the parameter get passed by plots:-animate when the number of frames matches a supplied integer range, but otherwise a float gets passed by the animate command. In contrast, Explore passes the integer values (possibly multiple times) in that case.

For your example there is an effect of passing a float instead (ie. the computed points are different that those obtained from the rounded integers. And so a closer conversion would be as follows, keeping Explore's default of 50 frames.

```r,theta := (abs,argument)(1+I):
plots:-animate(
a->plot(((r^(1/round(a)))*~([cos,sin]))~([seq]((2*Pi*k+theta)/round(a),k=0..round(a))),
style=pointline, symbol=solidcircle, symbolsize=25,
gridlines, thickness=3, scaling=constrained, color=blue,
labels=[Re,Im], labelfont=[Helvetica,bolditalic,20]),
[a], a=1..20, frames=50, paraminfo=false);
``` The same effect could be obtained more gracefully with a local variable.

```r,theta := (abs,argument)(1+I):
plots:-animate(
proc(aa) local a:=round(aa);
plot(((r^(1/a))*~([cos,sin]))~([seq]((2*Pi*k+theta)/a,k=0..a)),
style=pointline, symbol=solidcircle, symbolsize=25,
gridlines, thickness=3, scaling=constrained, color=blue,
labels=[Re,Im], labelfont=[Helvetica,bolditalic,20]);
end proc,
[a], a=1..20, frames=50, paraminfo=false);
```

Of course you are free to adjust the number of frames as you please. I just wanted to mention the difference in behavior.

Also, there's nothing inherently wrong with using non-integer values for the parameter, if you wanted to show the effect of it. There are some nice variants on your animation possible like that. But I was focused on a conversion of what your particular example did in Explore.

There is another difference that comes up for your example. The effective view of the result from plots:-animate is shared across all rendered frames. (Sometimes view is referred to as a "global" plot option.) But in Explore the example you gave shows with the non-forced view being different for each frame. You might actually prefer the common view, however, and of course that could also be forced in the Explore example by adding a view option to the call.

## piecwise log fit...

How about a piecewise logarithmic fit?

I am not bothering to make use of the fact that the data is symmetric (because I don't know whether this will be true of some larger data set you might actually have.)

 The only reason I use evalf below is to make the result look a little tidier on the page. You can remove the wrapping evalf calls, if you prefer. (Doing so might improve the fit a little, though it's likely not optimal regardless.)

 > restart;
 > X := [-0.012, -0.010, -0.004, -0.002, -0.001, -0.0001,       0.0001, 0.001, 0.002, 0.004, 0.010, 0.012]: Y := [-0.695, -0.7, -0.74, -0.825, -0.95, -1.0,       1.0, 0.95, 0.825, 0.74, 0.7, 0.695]:
 > P := plots:-pointplot(X,Y,symbol=solidcircle,symbolsize=12,color=blue):
 > Xn,Xp := selectremove(`<=`,X,0); T := table([seq(X[i]=Y[i],i=1..nops(X))]): Yp,Yn := [seq(T[x], x=Xp)], [seq(T[x], x=Xn)];  > Fp := evalf( Statistics:-Fit(a+b*ln(abs(c*x)), Xp, Yp, x) ): Fn := evalf( Statistics:-Fit(a+b*ln(abs(c*x)), Xn, Yn, x) ): F := piecewise(x<=0, Fn, Fp); > plots:-display( plot(F,x=min(X)..max(X), thickness=3, discont),                 P, view=-2..2, size=[500,350] ); >

Or you could do a rational polynomial fit. (With so few points it's unclear what is the "best" form.) I'll use the symmetry here, for fun.

```Fn := evalf( Statistics:-Fit((a+b*x+c*x^2)/(d+e*x+f*x^2),
Xn, Yn, x) );
F := piecewise(x<=0, Fn, -eval(Fn,x=-x)):

2
4655.04 x  + 0.575145 x + 0.00875488
Fn := ------------------------------------
2
-6833.43 x  - 2.22097 x - 0.00889769
``` ## HelpTools...

Read the Help pages for the commands from the HelpTools package.

That ought to provide the functionality for you Create a new database file, Store a custom Help pages to it, and so on.

There are also some Templates for Help pages.

You might also be able to do some of the management from the Tools item on the main menubar.

Sometimes in the past I have found some of this kind of documentation to be out of date, as the utilities get revised but some older instructions stick around for a while. Your mileage may vary.

## empty product and sum...

Basically, when you call select the result is the same operation or container that it is passed.

In the documentation quote you cited the key phrase is, "creates a new object of the same type". Sometimes it's tricky to document behaviour and keep clear which terms are technical and which are being used in a more general sense. Here, a strictly technical definition might well be confusing for most people.

For example, calling select on this product returns a product.

```select(type, x*sin(a)*7*cos(y)*z, specfunc({sin,cos})):
lprint(%);
sin(a)*cos(y)```

The empty product is 1. The empty sum is 0.

 This behavior in Maple is due not merely to mathematical convention. Or, rather, the convention is not merely incidental. It allows the math to work out more usefully. It allows the programming to work out much more usefully.

````*`(NULL);
1

`+`(NULL);
0
```

If you want to test whether the selected operands of the `+` or `*` expressions are NULL then you could operate on a list of those operands. For example,

```[op(3*C)];
[3, C]

select(has,[op(3*C)],x);
[]

[op(3+C)];
[3, C]

select(has,[op(3+C)],x);
[]
```
 1 2 3 4 5 6 7 Last Page 1 of 218
﻿