Rotation in formula

The rotation parameter is write protected.
Somebody know a elegant way to do rotation in the formula?
Usable in deep zoom.

This might be linked to #rotation being a predefined symbol. What exactly is the problem you are having? It would help to see the code. But my guess is that if you rename whatever is called "rotation" to something like "rot", your formula should work.

Sorry, I try to keep text short, but this was too short...

I search a way to zoom in to a fractal, without to use the options like #rotation etc. To move the location is easy, but i am not sure what's the right way to calculate the rotation precisely. If sin cos is OK, or if I get precision problems by deep zooming.

Imagin you cut a small rectangle out, around the cardeoid of Mandelbrot, tangential to it. Based on a int sequence.

(I wrote a code to generate fractint parameters for this, long time ago. I would like to see if I can move this code to uf.)

(And by the way, if somebody know a way to calculate the size of the bulbs this would help too.)

This is a very very old fractint parameter, but you should be able to calculate it.

Each image would be selectable by a int parameter. and the formula should to the rest.
The parameters for center and rotation will stay always on 0.

M-Kardeo-001 {

  reset             
  savename=m-ka-001

  type=Mandel
  corners=-2.25/-.75/.666666666666/-1.333333333333/-.75/-1.333333333333
  params=0/0
  ;colors=@m-ka-001.map

  float=y           
  passes=1          
  video=SF5
  maxiter=256     
  bailout=65536     
  outside=iter      
  inside=0              
}

M-Kardeo-002 {

  reset             
  savename=m-ka-002

  type=Mandel
  corners=-.63820023928/.1316001196398/.649519052838/1.226869322027/-.6382002392796/.6495190528383
  params=0/0
  ;colors=@m-ka-002.map

  float=y           
  passes=1          
  video=SF5
  maxiter=256     
  bailout=65536     
  outside=iter      
  inside=0              
}

M-Kardeo-003 {

  reset             
  savename=m-ka-003

  type=Mandel
  corners=.2708333333333/.3333333333333/.4166666666666/.8541666666666/.08333333333333/.6666666666666
  params=0/0
  ;colors=@m-ka-003.map

  float=y           
  passes=1          
  video=SF5
  maxiter=256     
  bailout=65536     
  outside=iter      
  inside=0             
}

Cos and sin in formulas will use arbitrary precision just like everything else. For rotation, you multiply the initial grid with a complex number that has your angle as argument and an abs of 1, after that you add the center of your location.

Though I am not sure what the purpose of not using #rotation is. Why not just use that?

Tanks for the tip.

If you check the parameter I post, you get the idea. Each frame would be calculated in the formula, not defined in a parameter file. Selectable by a int.
The frame location size and rotation is done by algorithm, not manually.
So you could animate this variable, and calculate all frames one time. You could animate this sequence up to 100 and more images around the cardeoid.

If there would be a write access to #center #rotation and #magn in the global: section, it would be easier to realize this.

If you check the parameter I post, you get the idea. Each frame would be calculated in the formula, not defined in a parameter file. Selectable by a int.

I do not understand... an animation is contained in a single parameter file, you don't need one file per frame, unless you have an edition that does not support animations.

First, the rotation in formula work now, sin cos works precise enough. Tanks.

Second, I don't know how to describe it else. Location and rotation around the cardeoid are done by calculation in the formula, not in a parameter file.
Just check the parameter file and understand, the formula go step be step to each bulb and cut out a frame there.

This maybe illustrates it. All frame cuts are done without changing the read only parameters.

OK, this makes a lot more sense now That is a really cool idea!

I found interesting that nobody found a formula to calculate the bulb sizes perfectly, after so many years mathematicians study the Mandelbrot set. I bitten my teeth out on this too.
My original code is now 30 years old... and still no one found a solution, as much I know.

That is super interesting!

here is a paper about it.
The_size_of_Mandelbrot_bulbs.pdf
https://www.sciencedirect.com/science/article/pii/S259005441930017X

and in the public rbs.ufm you find mapping formulas.

the idea is to use the maping and rotation/stretch-out algo to calc the bulb size.
I am not a mathematician, I only teach some to my self.
I try to extract out of the exp() rotation the y part. but even with the help of wolfram, I not got it done.
I think the rmexpinmp-o is the most promising to optimize the formula described in the paper. optically the bulbs lock even more same sized.

I used for my anim long time ago the original Mandelbrot. But you can find a easy way to animate the bulbs with the formulas in rbs.ufm

in case somebody find a solution for a better bulb size algo, pleas let me know.
tanks!

...more

if you put this in wolfram
https://www.wolframalpha.com/input?i=exp%28I+pi+2+p%29

exp(i pi 2 p)
you get this out
cos(2 π p) + i sin(2 π p)

the imaginary y part sin(2 π b) can be used for the bulb size.
and leads to
sin(π p / q) 1/q^2
To calc even other bulbs then 1/q. My animation uses 1/q.
The location of bulbs on the cardeoid is p/q.

I think rmexpinmp-o could maybe optimize the size calculations.

init:
  z = (0,0)           ; Start 0, always, Mandelbrot set.
  i2pi = (0.0,6.2831853071795865)     ; i2Pi 
    ;                           ; Continued fraction. 
  q = 1 - exp(-i2pi/(@N+1.0/(@M+#pixel)))   
    ;     ; Integers N, M specified for S:/N/M sprout. 
  qq = q*q 
;
loop:                     ; RBS-Preferred quadratic in z, 
  z = 0.5*(z*z + 1 - qq)   ; parameter q.

...more

You maybe recognised this

https://en.m.wikipedia.org/wiki/Euler's_identity

So yes, it is interesting...

Couldn't you write this as a transformation? That's the way in UF to change the coordinates programmatically.

Not really for this situation, because i can not transport values/parameters form ufm to ucl or uxf.
I do a remapping in cfm to cut out frames according to a counter.
(The ufm are combinatoric monsters with many options. And if i have time, i will try if i can do the remapping even for different p, z^p+c. The options should only to be changed in one place.)

The rotation works fine with exp or cos/sin.
For now i have not detect precision errors for small values, only for big (1000^1000), and this not mater in this situation.