using @acer 's tremendous code,

this is Euclid's Orchard, with zooming-in ability.

http://mathworld.wolfram.com/EuclidsOrchard.html

https://en.wikipedia.org/wiki/Euclid%27s_orchard

Euclid's Orchard is a fractal. I would rate it as the most "elementary" fractal.

It is basically just a listing of the Farey sequence of (all irreducible) fractions for the unit interval, with height equal to 1/denom(F[k]), of level N, so it is related to Dirichlet's funtion.

https://en.wikipedia.org/wiki/Farey_sequence

http://mathworld.wolfram.com/DirichletFunction.html

The graphic displays a subset of all Detekind cuts of the unit interval. For example, (eventually) white points on the x-axis are the irrational limits of some appropriate convergent sequence of Farey fractions.

If you set for example,

Ox:=evalf(sqrt(2)-1);Oy=0;

then the zoom function will converge to the irrational 0.414213562, and the central point will indeed be blank on the x-axis.

Because one can only list all Farey fractions of a finite order (N), all blank spaces are basically (a finite number of) open covers of irrationals.

Thank you to all who read and contributed.

--

Yiannis

@acer yes, many thanks. That's it!

--

Yiannis

@Markiyan Hirnyk thanks. The size of the final animation seems to indeed present a problem.

--

Yiannis

@acer  thanks for replying. Yes, the alternate interpretation is what I am thinking of. Full first frame and then restricted (but full size) frames on the rest.

If that doesn't work, I will try saving each individual frame as a .bmp and the use bmp2avi to stitch all of them together, using either exportplot or write.

--

Yiannis 

@Carl Love the animation code is EulerAnimation.mw.

Key feature of the animation: variable "delta". To animate through a cut in the Shell-Thron region, vary d1 and d2 and N=steps. This works only for each point on the boundary except e^{1/e}. To get an animation cut there (like the period 1) you need to vary the base c directly, say from 1.2 to 1.5 or something such.

Needless to say these wouldn't be possible in realistic times, absent your patch for evalhf.

Also, to make color look compatible with Maple 13's colors, don;t forget "lightmodel=none" in plot3d, otherwise Maple 18 harasses the plot.

I will make a post a little later, when I get some time :-)

Cheers and thanks everyone.

--

Yiannis

@J F Ogilvie Herein I am providing a bit of context for the produced plots.

Newbies often get fascinated with the power tower: x^x^x^...

The generalized power tower z^z^z^... is a special case of the Euler sequence:

z_{n+1}=c^z_n, for c\in C.

Like the Mandelbrot set: z_{n+1}=z^2-c, the power tower, henceforth called infinite exponential, also has a general periodic map. It is included below and is taken from Daniel Geisler's site:
www.tetration.org

Shel and Thron proved that the infinite exponential conveges whenever c belongs to the red region, called today Shell-Thron region.

Also like the Mandelbrot set, the infinite exponential admits Juila Sets. The colored map then is a general map of how the corresponding Julia set behaves, with c taken from the map.

We can then introduce small cuts which go from the interior of the Shell-Thron region to the exterior, crossing at various angles.

This tells us how the infinite exponential evolves in general.

When the parameter c exits the Shell-Thron region at angles Pi and 2*Pi from the real axis (right and left), the infinite exponential either transitions from converging to a single feature to exploding into multiple indecomposable contiua (p=1), or it breaks into a period 2 bifurcation (p=2).

When it exits at angles 2*Pi/p, where p>2, then the infinite exponential evolves from converging to a single feature, to exploding into  p major regions, called Fatou regions, each one having its own attractor, displaying a p-furcation.

The Julia Sets of the infinite exponential are defined to be  the closure of the periodic repellers of the Euler sequence and are shown visually as the corresponding Cantor Bouquets in each case.

In all cases, indecomposable continua may be present, as some Fatou regions end up covering entire parts of the complex plane after each transition.

Included are 6 transitions, for p\in {1,2,3,4,5} and one which exits at the angle of 2 radians.

-----------------------------------------------------------
Setup:
Maple 13 on a duo core 64-bit Turbo AMD E2-1800 APU@1.7 GHz.
Resolution: 400x400 (Julia Sets)
iterations: 200
bailout: 1e30
color:ln(iterations)

@acer, @Carl Love, @Preben Alsholm:

Many thanks to all. I understand the limitation Carl talks about, so this part of the exploration seems to allow for greater flexibility. acer's no axes works wonderfully on the saved .gif.

If all else fails, I guess I can also produce first all the frames, saving as .bmp, and then shove them into bmp2avi or something similar and produce the final animation as a movie.

My apologies for not being able to vote up anything on this thread, as I don't have a rep yet, so system fires bells when I try.

Thanks,

--

Yiannis

@Preben Alsholm wrote:

@Yiannis Galidakis What do you want to happen here?

plot3d(x^2+y^2,x=-1..1,y=-1..1); p1:=%:
plot3d(x^2+y^2,x=-2..2,y=-2..2); p2:=%:
plots:-display(p1,p2,insequence);

########

Something like this?

f:=(x,y)->x^2+y^2;
plot3d(f,-1..1,-1..1); p1:=%:
plot3d((x,y)->f(x*2,y*2),-1..1,-1..1); p2:=%:
plots:-display(p1,p2,insequence);

No. Your example keeps the axes aligned, so the next frame is reduced in size. I would expect that my animation sequence of plots were displayed as if each frame had the same picture size as the first one, which happens if I do k separate displays, like:

display(P[1]);

display(P[2]);

...

Instead, the final display command on my doc, aligns the axes of ALL included plots and as a result the size of individual plots diminishes and then blows up again upon animating. Is that clear?

On each frame then, the axes should adjust to the size of each frame, which doesn't happen.

Thanks,

--

Yiannis

Ok, with Carl's answer the problem of speed has been fixed and so now animation is possible.

Consider now the doc: EulerAnimation2.mw

By varying the magnification factor, we can do simple zooms, so I added two small k loops which produce an ascending and a descending sequence of frames.

What's the problem now? It animates on display as if each frame is less in size than the previous one. It's sort of understandable in the sense that when Maple displays two plots it aligns their coordinate systems, but why here?

Note that if you call display(P[3]); or display(P[k]) for any specific k, the display assumes the right dimensions. But all of them together are a sequence of squished squares.

I used a list, because it seems to be the faster option.

Any ideas how to fix this behavior?

Thanks,

--

Yiannis

@Axel Vogt , the HW are just multivalued inverses of more specific exponential equations. While Lambert's W is the inverse to z*exp(z), the HW allow a little more flexibility. Think in terms of inverses of z*exp(f(z)), where f(z) are arbitrary functions, possibly themselves exponentials.

They basically can solve anything. Any equation, transcendental, mixed exponential, trigonometric, etc, provided the equation is not implicit. This means, as long as all the x's are on one side and the y on the other, they can solve it.

They are part of my Ph.D. thesis, and I am not done yet with that. The code for them in the Maple 13 doc I gave is basically it. I'd rather not bother the mathematicians here (or elsewhere), until I finish my doctorate. Then, they may gradually come around.

Otherwise, they are on my papers in my scholar pages, which you can visit at:

https://scholar.google.com/citations?user=BmHlhq0AAAAJ&hl=el

--

Yiannis

FYI these techniques can be used for your problem, if you are interested in high quality 2D images produced quickly. I couldn't quite tell from your original post whether you actually wanted the depth of a 3D plot or whether you used plot3d just because it hammers the Standard GUI less hard than does the corresponding densityplot. I included in my attachments the call to do it in 2D with plots:-densityplot, by the way.

@acer Thanks. I will take a look at them, I used the plot3d plotting command basically as an older suggestion of Robert Israel, who very long time ago gave me some pointers on the tetration fractal, but turns out that the z coord is useful as a determinant of speed of convergence.

If you rotate the 3d plot, you can "play billiards" with the surface, as Fatou regions are indeed basins and repellers and the Cantor bouquets are highlands. So you can conceivably play billiards with the 3D plot, by mapping the z coord to the gravitational force on an inclined surface.

--

Yiannis

@acer

Thanks for the additional code. I downloaded your examples and will study the code carefully.

At present though it doesn't look like the evalhf 13 version benefits a lot from splitting into re and im, but I will look at it further.

What I meant about the global usage of lim and lambda, certainly doesn't exclude your and other people's note: namely, stuffing them through a parameter list.

What I meant by "global" here, was just "having them ready" inside the proc  one way or another, so your note stands.

Cheers,

--

Yiannis

Hi Axel, Carl and all others,

This has been an interesting experiment. I was trying to produce these Julia fractals, since 8-10 years ago, when I was still on usenetand was using Maple V rel 4, but it was a pita.

Now at school, they wanted to see them as part of my PhD thesis, so I started switching between versions.

With V they did complete on small grids (100x100) in about 10-20 minutes, so V was essentially useless. I had to have several samples and took too long to generate animations.

My school then updated to Maple 9 and there the results were similar on smallish grids, just a tad faster, in the order of 5-8 minutes.

Now the school also wanted me to evaluate between versions, so by pure accident I tried it on 13 and it worked, so I was able for the first time to see what these Julias look like, even under animation.

They also had 18, so I tried them there and hence the discrepancy.

Looks like Carl found the culprit? That is amazing! I thought that maybe 18 did not take advantage of java property or something to that extent. Oh well.

Please feel free to experiment with the code. I know of no other program which can produce these with additional attractors included, except Xaos, but neither it nor other programs which accept custom functions have a way to calculate the limits (either the main feature, or the secondary attractors outside the Shell-Thron region), so the Fatou basins are always black.

For best results, choose c values close to the Shell-Thron boundary, shown on the upper part of the code.

Many thanks to all who looked at this. Can't wait to try Carl's solution!

PS: the code is aptly optimized through the years. Even the use of globals is the best solution in this case. I experimented with using only locals, takes too long on Maple 13. For example, lim and lambda need to be global so they can be ready for each iteration. If I changed to a local calculation, it still drags, even on 13.

PS2: My old web page was scrapped by the Brain virus. I lost everything, but parts of it were saved at the www.archive.org. If anyone wants to take a look, send me an email and I will reply on how to access it.

Thanks again everyone!

Thanks to both. I wasn't aware that 13 introduced new features for fractals.

--

Yiannis

@Kitonum many thanks. It's a glitch I always stuble upon.