30214 Reputation

18 years, 241 days

scaling is not part of a plot structure...

Yes, there is a way to decompose and reparse the output of InlinePlot, to get back to a plot structure.

But that mentioned zoom/scale is not part of a plot structure. It's only part of the XML markup of the actual worksheet. So reparsing from an InlinePlot's XML return back to an actual plot structure would not retain an such scaling/zoom level information.

If that scale/zoom (like with right-click manipulator) were a programmatic part of a plot structure itself then I'd have shown that way in your previous Question.

However, another possibility for getting a "zoomed" effect might be to use the viewpoint option with just a single frame.

allsolutions...

For fun, here is the first example, but using the allsolutions option to get a result in terms of conditional relations.

(Sorry, this site doesn't render it so nicely.)

 > restart;
 > r := a + (b - a)*z/h:
 > x1 := sqrt(r^2 - y^2):

The so-called "collapsed" syntax for multiple integrals
allows easy use of the allsolutions option.

There are various piecewise instances in the following result,
involving various relations between a,b, & h.

 > simplify( int(1, [x=-x1..x1,y=-r..r,z=0..h], allsolutions) )    assuming real;

followup example...

 > restart;
 > r := a + (b - a)*z/h:
 > x1 := sqrt(r^2 - y^2):

Note that I use a different syntax for the multiple integral,
in which the command int is called just once. A "collapsed" syntax.

That allows knowledge to be transferred from the outer integeration
to the inner integration. E.g. relations between the inner level's integrand's
variables and and the outer levels' ranges.

 > simplify( int(x^2+y^2, [x=-x1..x1,y=-r..r,z=0..h]) )     assuming h>0, a>0, b>0;

In contrast to the above, the form with three nested int calls
takes longer. (In general this nested form can even fail while
the collapsed form succeeds. Here, we are lucky.)

In this case the inner integral (w.r.t. x) gets computed without knowledge
that y is between -r and r, or that z is less than h.

 > simplify( int(int(int(x^2+y^2, x = -x1 .. x1), y = -r .. r), z = 0 .. h) )     assuming h>0, a>0, b>0;

Warning, unable to determine if (a*h-a*z+b*z)/h is between -a-(b-a)*z/h and a+(b-a)*z/h; try to use assumptions or use the AllSolutions option

Warning, unable to determine if -(a*h-a*z+b*z)/h is between -a-(b-a)*z/h and a+(b-a)*z/h; try to use assumptions or use the AllSolutions option

maybe...

You cannot link just the character length or length of the 1D code representation of a general expression with the width the takes to pretty-print it as 2D Output. It generally needs a bit more finesse, according to type of expression.

However, I've seen at least one quite decent attempt at estimating 2D rendering width for algebraic expressions. I'd have to go hunting to find it.

But the elision fade-out was done using Typesetting constructs, in the instance I'm recollecting. I'm not 100% sure that the further/repeat 2D type-setting by Tabulate would work ok. If not then the DocumentTools:-Layout constructors might be used to get the same kind of Table result.

Alas it is the end of the day for me.

example...

@nmacsai These two ways of injecting the COLBAR substructure into the cylinder's PLOT3D structure end up with the same result.

 > restart;
 > interface(version);

 > Psin := plots:-contourplot(sin(x*y),x=-Pi..Pi,y=-Pi..Pi,colorbar):
 > # the colorbar will have height 200 pixels CB := subsindets(indets(Psin,specfunc(COLBAR))[1],specfunc(PLOT),                  u->plots:-display(u,size=[200,200])):
 > op(0,CB);

 > c1 := plots:-display(plottools:-cylinder([1, 1, 1], 1, 3),                      scaling = constrained, color = red, size=[400,400]):
 > # first way subsop(-1=[op(-1,c1),CB][],c1);

 > # second way PLOT3D(op(c1),CB);

I used contourplot to get its accompanying color-bar. You could alternatively use densityplot and then pass that your choice of colorscheme option. Eg,

colbar_M2023_3.mw

 The constructed color-bar is itself just a 2D densityplot with aligned values shown. There are doubtless more efficient ways to construct it, and I just chose one that was reasonably straightforward. The trick is to wrap it in a COLBAR call, and then make it the new last operand of the PLOT3D structure. You could likely use other kinds of 2D plots. The GUI recognize the COLBAR within the PLOT3D and renders it (only) on the right side.

method...

@Dkunb evalf(Int(...)) uses option remember,system so doing duplicates in rapid succession will utilize "remembered" results.

So your idea to do the numeric integration once (each, followed by substitution) is a well-meaning idea but not beneficial if all's done properly.

What can make a big effect here is using method=_d01akc (periodic), or method=_d01ajc for you evalf(Int(...)) calls. Do that after substituting numeric parameter values, otherwise an inadvertant evalf will strip off that option.

You latest code is too convoluted and perhaps not robust. The combination of Expand and then multiplication by I looks nonrobust. Best would be if you provided the slow code in full, including the float results. Otherwise fixing it up is problematic.

e^(z^2) ?...

Did you intend exp(x^2) instead of e^(z^2) ?

Parametric...

 > restart;
 > Eq := -8*(rho + 1)^4*Lambda^4 + 12*(rho + 1)^3*Gamma*(rho - 1)*Lambda^3 - 5*(rho + 1)^2*(-4/5 + Gamma^2*rho^2 + 2*(-2/5 - Gamma^2)*rho + Gamma^2)*Lambda^2 - 4*(rho + 1)*Gamma*(rho^2 - 1)*Lambda + Gamma^2*(rho + 1)*(rho - 1)^2;

 > with(RootFinding:-Parametric):
 > m := CellDecomposition([Eq=0, Lambda>0, Gamma>0], [Lambda]):
 > CellPlot(m, samplepoints, view=[0..10,-2..2], size=[400,300]);

 > NumberOfSolutions(m)[2..3];

 > SampleSolutions(m,3);

 > SampleSolutions(m,3);

not an export...

@C_R

IVPOrder is a local of the Student:-ODEs module, not an export.

A few ways get what you're after,

```restart;
kernelopts(opaquemodules=false):
stopat(Student:-ODEs:-IVPOrder1,14);

[ODEs:-IVPOrder1]

restart;
stopat(Student:-ODEs::IVPOrder1);

[ODEs:-IVPOrder1]

restart;
stopat((Student::ODEs)::IVPOrder1);

[ODEs:-IVPOrder1]```

I am surprised to see such a mistake in a Library routines. It's pretty common to do instead something like,

indets(expr, And(name,Not(constant)))

or,

indets(expr, name) minus {constants};

@MaPal93 Don't spawn more wholly sepatate new threads on this.

deduced how?...

In your second to last example you first asked, "What proportion of the population needs to be vaccinated in order to prevent an epidemic...", and then you set p=0.5 where initial condition is R(0)=p, and then ended with the statement,
"The required vaccination coverage is around 50% ."

Is that supposed to show some deduced computation? Clearly the "required vaccination coverage" was not computed there. We might accept that 50% is adequate (the R(t) plot is flat), but why wouldn't slightly less also work? The word "required" makes it seem as if no less would do.

The same thing happens in the last example. You start by setting p=0.83, and then end with the statement that 83% is required. Why is that much required? What's the computational criterion to accept that 0.83 was the smallest value that was adequate?

related?...

@dharr Is this at all related to procedure f in the 3rd attachment in this Answer? (tracking largest positive RootOf, to help with "switch" when, say, roots coincide at a point, or number of real roots changes, etc).

There I used fnormal and simplify(..,zero) and doubled-Digits to help with imaginary artefacts.

side note...

Plot problem reported, regression in Maple 2024.0,

```plot(Pi/2-arccos(h/sqrt(h^2+2)),h=0..3),

plot(arccos(1/sqrt(x))),

useassumptions...

@minhthien2016 The result is correct.

But you can get rid of the warning with,

solve(temp = Pi/3, h, useassumptions);