@Carl Love by all means, please elaborate. How do you choose what to evaluate in subcalls? That'd be quite interesting, as it would offer a clear hint on the magnitude difference between H(m,x,y) and H(n,x,y), inspected just visually. i don't mind having long towers as long as the lower parts are the same, so they can be ignored in the comparisons. That was actually my original intent for asking this question.

Yiannis

@Carl Love yes, this looks much better and it works on 13. For hy(5, 2, 4) I am getting:

That's as close to what I was asking as possible. Many thanks.

PS: Re: Maple 13. I will be stuck at home for some time, as all school relays for grad students are now made via the net, to avoid contacts because of the Covid-19 thingy. I expect to be back and have access to Maple 18 sometime back in January.

@Carl Love hi. Thanks for taking the time to look at this. Unfortunately, I am constrained at home and I only have access to Maple 13 here, and your inert code operators don't seem to work with that version. The parser chokes at the % sign. I manipulated your code a bit by removing the "thisproc" statement - which 13 also doesn't recognize and the best I could come u with that explicitly lists the arguments is simply using "print" statements, which outputs closely what your code intends to:

hy := proc (n, x, y) if n = 0 then print(y, "+", 1) elif n = 1 then print(x, "+", y) else if y = 1 then print(x) else if n = 2 then print(x, "*", y) elif n = 3 then print(x, "^", y) elif n = 4 then print(x, "^", ('hy')(4, x, y-1)) else ('hy')(n-1, x, ('hy')(n, x, y-1)) end if end if end if end proc

I am pretty ok with the above, as it lists the arguments explicitly, so please don't spend any more time on this. For what's worth, I was trying to get a visual of the final structure to help in comparing hyperops of different order: H(m,x,y)<=> H(n,x,y). But on second thought it's pretty obvious that if n>m, then H(n,x,y)> H(m,x,y), with or without numerical inspection (maybe except for some small values of m and n).

Thanks again,

Yiannis

@Carl Love hi, sorry I didn't give examples. I just want a symbolic form of the output, without evaluation. hy(3, 2, 3) evaluates to 8. I'd rather want 2^3 as output. Or hy(2, 3, 3) evaluates to 9. I'd want 3*3. Or, hy(4, 2, 3) evaluates to 16, but I'd want 2^(2^2), etc. In other words, an unevaluated symbolic expression in terms of the symbols for the actual numerical arguments.

That's for the hy proc, but this is just an extended version of H, which I think agrees with H for same n. Maybe it isn't doable with H, because it doesn't branch down for lower n.

@acer thanks, I already have the evalhf version of that. It's been posted as Tetrational code viewer 1.0.1 on my profile page, since 2015.

As for the splitting into real & imaginary parts, I remember it was Robert Israel who first suggested it, back on sci.math, sometime in 1998 or thereabouts. It did work wonders with my Maple V and 9 versions back in 2000-2002 with this tetration fractal (the one we are talking about in this question), but I didn't check it on newer versions like 13 or 18. But, like you do, I like simplicity, too. The code for complexes is much more elegant than the split code for re and im. It's only useful for those readers who have older versions of Maple. If you care to show us that it does make a difference, I'd gladly revise my worksheet posted as tetrational code viewer 1.0.1 to reflect these changes.

Cheerio,

Yiannis

@acer sorry, I did remember this post after you suggested evalhf, but without reading it I recalled the first person who suggested it (Carl), - who also went into the credits for the related Julia fractal generator. I never implemented a compiler version of it, so I left that issue at that.

The expMap4 example needs evalhf. I don't see it anywhere.

The period calculation is a big issue altogether and I can't see how it can be patched into any newer versions - such as the iterative/escape versions. I just cooked up a quick and dirty solution - just checking backwards differences starting from orb[N] for similarity, but this is a very loose idea and is not guaranteed to work if eps is small and you only have a small part of the orbit (i.e. if N and eps are small). (The problem is much deeper than what it looks. I tried to see if anybody had any faster ideas for checking the period of iterated maps and I got banged with two downvotes in math.stackExchange because by question wasn't "clear". What I was looking for was addressed in the answer given, but that's a lot of research into iterated systems dynamics and after going through most of the references, I didn't find anything faster than what I have, hence the small orb loop. Wiki has some ideas about it - in the answer refs, but I coudln't see how to adapt them for exponential dynamics. And the dynamics of exp are different from the dynamics of the Mandelbrot map. The latter finds actually the PRE-period of orbits of the bulbs in the M Set - which come from convergent points, the former needs to find periods from points which converge to p separate limits OUTSIDE the region of convergence. So the implementation is bound to be different. In any case, I don't know what should be done for period checking in the iterative versions, other than through this orb[N] vector, etc)

Anyway, I am not going to bother with implementing a compiled version as of now, as I don't have the time to check it further for compatibility (I am busy resurrecting my webpage from the archive after it crashed in 2011 - and that's a lot of work). I may come back to it later, and address a revision if the need arises.

Sorry about forgetting to include you in the credits (I usually credit the first one who comes with a solution and in that case it was Carl). For this post, I link directly to it, so there's no question who's solved it. Again, my apologies, for the omission.

Cheers

Yiannis

@acer yes, this one works. The res2 call takes around 2.3 minutes on my machine. The final img command takes around 10 secs to display. You are hereby awarded the Holy Maple Guru award B^{)>. One would tend to think that you are working for MapleSoft....

Anyway, does this error mean that the compiler doesn't work correctly in my version of Maple?

Yes, please attach the iterative maps escape code as well in a subsequent post, if it's not that much of a trouble. You never know what readers may be looking for in my webpage, so it's a good idea to have all the resources in one place.

@acer Many thanks. That's some pretty nifty code. But it crashes my 18.00. The command group of statements starting with  NN:=400; N:=20; eps:=1e-2;... etc., annoys Maple which says that the connection with the Maple kernel has been lost. Restart your Maple, etc. I checked my firewall to see if Maple 18 is excluded, but it wasn't, so I added it again, and still crashes at that statement with the same error.

Anyway, i am pretty satisfied with the optimization done with evalhf, so please don't spend too much time on this. I will link to this post from my webpage to offer it as an alternative for viewers who want to see code for more accurate depictions of the graph than what I have in my page, anyway. So the entire discussion will be seen and the user will be able to download all the worksheets.

@acer your worksheet doesn't seem to run on my machine.

What's source for Tetration module? It links to something but's not visible in your previous post. Here's the output I get:

Download parTet.mw

@acer That's terrific. I suppose the call that makes the difference is evalhf. The whole thing took ~25 secs with your code, for 200 iterations at each point. I had the same problem with other tetration fractals and it was suggested that I use evalhf, after which performance was tremendously improved. I can now see how I can tweek p so I can get a wider palette. I also used a larger eps=0.1, so the period checker is more easily satisfied. The white pixels do nor disappear altogether, but are constrained a lot.

thanks again,

Yiannis

@acer writes:

>It would also be straightforward to adjust the intensity component of the "HSV" Color call, say by the taking complex modulus of the value via the abs command.

Wouldn't that be equivalent to plotting via 'complexplot3d(f,-1-I..1+I);' and looking at the graph from above (except that the grid lines wouldn't match)?

@acer Thanks. As I suspected Bau appears to be using the inverse transformation for a given f, hence my confusion. Your shading scheme is also much more interesting than my plain gray plots. I am linking to this page as a reference.

PS: btw, Your HSV coloring scheme doesn't work with version 18. I get only two colors, like this: 

(If you can find a way to make it work with 18, I will delete this  comment)

Ah, excellent!

Robert is the answer to the question "what would Gauss be able to do if he had Maple, today".

Btw, can I add this as an application file like Robert's or are such examples added automatically?

Many thanks,

Yiannis

@acer I am only trying to export the given orientation as an. eps picture for use with LaTeX, but as indicated, the export to .eps menu creates a blank graph with only the axes, opening with GSView 5.0.

When the image is not passed through the transform 1/z, it works, but sometimes it also doesn't work. Maybe it has to do with memory?

thanks,

--

Yiannis

@acer I think a small additional adjustment needs to be made, to allow you to zoom-in at different numbers.

You have:

    PPtab[k] := display(transf(plot(select(proc (u) options operator, arrow;

    Ox-w <= u[1][1] and u[1][1] <= Ox+w end proc, F),

    Ox-w .. Ox+w, Oy .. Oy+2*w, color = black, axes = none)),

    textplot([0, -0.5e-1, evalf[3](Ox-w)]), #

    textplot([.5, -0.5e-1, evalf[3](Ox)]), ##

   textplot([1, -0.5e-1, evalf[3](Ox+w)]), ###

   view = [0 .. 1, -.1 .. 1], ####

   gridlines = false)

For zooming at a different point than (1/2,0), the following works a little better:

(For example, try Ox:=evalf(Pi-3);Oy=0;)

    PPtab[k] := display(transf(plot(select(proc (u) options operator, arrow;

    Ox-w <= u[1][1] and u[1][1] <= Ox+w end proc, F),

    Ox-w .. Ox+w, Oy .. Oy+2*w, color = black, axes = none)),

    textplot([Ox-1/2, -0.5e-1, evalf[3](Ox-w)]), #

    textplot([Ox, -0.5e-1, evalf[3](Ox)]), ##

    textplot([Ox+1/2, -0.5e-1, evalf[3](Ox+w)]), ###

    view = [Ox-w .. Ox+w, -.1 .. Oy+2*w], ####

    gridlines = false)

Thanks again,

--

Yiannis