## 28065 Reputation

17 years, 241 days

## 3D implicit plot with scaled axes...

Maple

Someone asked on math.stackexchange.com about plotting x*y*z=1 and, while it's easy enough to handle it with implicitplot3d it raised the question of how to get nice constained axes in the case that the x- or y-range is much less than the z-range.

Here's what WolframAlpha gives. (Mathematica handles it straight an an plot of the explict z=1/(x*y), which is interesting although I'm more interested here in axes scaling than in discontinuous 3D plots)

Here is the result of a call to implicitplot3d with default scaling=unconstrained. The axes appear like in a cube, each of equal "length". Here is the same plot, with scaling=constrained. This is not pretty, because the x- and y-range are much smalled than the z-range. How can we control the axes scaling? Resizing the inlined plot window with the mouse just affects the window. The plot itself remains  rendered in a cube. Using right-click menus to rescale just makes all axes grow or shrink together.

One unattractive approach it to force a small z-view on a plot of a much larger z-range, for a piecewise or procedure that is undefined outisde a specific range.

```plots:-implicitplot3d(proc(x,y,z)
if abs(z)>200 then undefined;
else x*y*z-1; end if;
end proc,
-1..1, -1..1, -200..200, view=[-1..1,-1..1,-400..400],
style=surfacecontour, grid=[30,30,30]);
``` Another approach is to scale the x and y variables, scale their ranges, and then force scaled tickmark values. Here is a rough procedure to automate such a thing. The basic idea is for it to accept the same kinds of arguments are implicitplot3d does, with two extra options for scaling the axis x-relative-to-z, and axis y-relative-to-z.

```implplot3d:=proc( expr,
rng1::name=range(numeric),
rng2::name=range(numeric),
rng3::name=range(numeric),
{scalex::numeric:=1, scaley::numeric:=1} )
local d1, d2, dz, n1, n2, r1, r2, rngs, scx, scy;
uses plotfn=plots:-implicitplot3d;
(n1,n2) := lhs(rng1), lhs(rng2);
dz := rhs(rhs(rng3))-lhs(rhs(rng3));
(scx,scy) := scalex*dz/(rhs(rhs(rng1))-lhs(rhs(rng1))),
scaley*dz/(rhs(rhs(rng2))-lhs(rhs(rng2)));
(r1,r2) := map(`*`,rhs(rng1),scx), map(`*`,rhs(rng2),scy);
(d1,d2) := rhs(r1)-lhs(r1), rhs(r1)-lhs(r1);
plotfn( subs([n1=n1/scx, n2=n2/scy], expr),
n1=r1, n2=r2, rng3, _rest[],
':-axis'=[':-tickmarks'=[seq(i=evalf(i/scx),i=r1,d1/4)]],
':-axis'=[':-tickmarks'=[seq(i=evalf(i/scy),i=r2,d2/4)]],
':-scaling'=':-constrained');
end proc:
```

The above could be better. It could also detect user-supplied custom x- or y-tickmarks and then scale those instead of forming new ones.

Here is an example of using it,

```implplot3d( x*y*z=1, x=-1..1, y=-1..1, z=-200..200, grid=[30,30,30],
scalex=1.618, scaley=1.618 );
``` Here is another example

```implplot3d( x*y*z=1, x=-5..13, y=-11..5, z=-200..200, grid=[30,30,30],
style=surfacecontour, orientation=[-50,55,0],
scaley=0.5 );
``` Ideally I would like to see the GUI handle all this, with say (two or three) additional (scalar) axis scaling properties in a PLOT3D structure. Barring that, one might ask whether a post-processing routine could use plots:-transform (or friend) and also force the tickmarks. For that I believe that picking off the effective x-, y-, and z-ranges is needed. That's not too hard for the result of a single call to the plot3d command. Where it could get difficult is in handling the result of plots:-display when fed a mix of several spacecurves, 3D implicit plots, and surfaces.

Have I overlooked something much easier?

acer

## rosettacode.org...

Maple

I see two recent items on the web about Mathematica and the rosettacode.org site. One was a Wolfram Inc. corporate blog post, and the other a post on Wolfram's relatively new community site.

There are many items on the page of tasks still without a submitted Maple implementation. It would be nice to see interesting implementations of some remaining tasks, as contributions from the Maple user base. The tasks remaining are of very mixed difficulty levels.

To date there are only 132 entries on the page for Maple implementations of that site's programming tasks. (Of these about 40 were submitted by one member while about 80 were submitted by another member.)

acer

## faster numeric Bessel functions...

Maple 18

Some years ago member William Fish started a long discussion in part about a numeric integral involving high parameter (high oscillation) Bessel J0. That numeric integration task appeared in a Bitwise Magazine article.

At that time even obtaining numeric results involved extra effort such as handling real and imaginary components of the integrand separately, and requesting particular methods (sometimes hacked, to bump up the subinterval limit, for very high parameter values).

That led to a post where I showed that the result could be obtained quickly by using a fast compiled BesselJ (J0) from an external library along with a modified low-level call to a particular evalf/Int solver.

And sometime after that a numeric result for the real & imaginary split integrand became much more readily (if not quickly) available by using a new `maxintervals` option of evalf/Int to specify the maximal number of subintervals for the particular solver.

Maple 18 has its own compiled implementations of the Bessel functions for "hardware" (double) precision arguments. So now the numeric evaluations of the integrand are computed much faster.

Using Maple 18.00 on 64bit Windows 7 the same numeric results obtain in under a second, in a simple, single call to evalf,Int.

```restart:

CodeTools:-Usage(
evalf(Int(BesselJ(0, 50001*x)*x*exp(I*(355*x^2*1/2)), x = .35 .. 1))
);
memory used=9.28MiB, alloc change=32.00MiB, cpu time=437.00ms, real time=441.00ms, gc time=0ns

-8                 -8
3.181753502 10   - 7.798301124 10   I

restart:

CodeTools:-Usage(
evalf(Int(BesselJ(0, 10000*x)*x*exp(I*(355*x^2*1/2)), x = .35 .. 1))
);
memory used=6.83MiB, alloc change=32.00MiB, cpu time=218.00ms, real time=211.00ms, gc time=15.60ms

-7                 -7
-2.007752340 10   + 4.275388462 10   I
```

Of course the ramifications of fast, compiled Bessel functions at double precision extend much farther than just this one example. But I like seeing the speed improvement in terms of a concrete example.

acer

## gridlines and inlined worksheets...

Maple , MapleNet , MaplePrimes

For some time I have been running into the problem where uploaded worksheets that are inlined into a Mapleprimes post get gridlines shown, even when they are not specified or shown in the original worksheet. This is a problem because quite often the gridlines make an inlined plot unattractive.

I believe that Mapleprimes uses some version of MapleNet as a mechanism for inlining uploaded worksheets.

It seems that the Standard GUI and/or MapleNet have special handling for gridlines in the sense that they actually distinguish between PLOT structures generated without the `gridlines` option versus those created with `gridlines=false`.  I believe that this has something to do with the persistence of various plot qualities in an output region which (perhaps for historical reasons?)  allow re-execution of a plot input command to produce a plot output rendering that remembers whether gridlines are visible.

If the second plot below does indeed get rendered here in Primes without gridlines visible then one workaround is evident: adding `gridlines=false` instead of omitting the option.

 > plot(sin(x),x=-Pi..Pi); > plot(sin(x),x=-Pi..Pi,gridlines=false); >