[Bug?] Arbitrary precision not working in Coloring Algorithm

I recently picked UF.5 up again to do some math experiments. I wrote a coloring algorithm, but calculations became very slow at a zoom depth of 1e24. I read UF.6 was a lot faster and maybe perturbation could also help (as I'm using Mandelbrot).

Opening the fractal in UF.6, the coloring algorithm doesn't seem to work anymore. I tried loading a non-perturbation version of Mandel, but it still doesn't work. The symptoms I'm seeing are equal to those when using Extended precision, i.e. large quantization of input values
e.g.

Entering:
0.444444444444861296182757053786418265553146200444003440041363028157654069228480050281532280718162049115995
gives the same result as:
0.4444444444448613
0.44444444444486131
0.44444444444486132 and
0.44444444444486133
and the next number giving a different result is:
0.44444444444486134

This is tell-tale of limited precision calculations.

Furthermore, increasing the precision from 70 to 100 or to 1000 doesn't change the result, or the calculation time.

Parameter:

Copy7OfExt3rnalRays-anim {
::BFWD1gn2tTVTPSNOQ07j08fwKcZ5w0TZH/5gs0ItMcYl4CzVkQmEnu9OJxROuZme/1vlT6G6
  dBkQASch+QU7ylr3zue1rL5ayu+bu8CCJHy9eb1fGnOQ+D1zJxOi/pcda01TSuDzX5GDDVkH
  Dt5dWuGI78ht7yWGHI9uD+0slVqTXyN4x/LkkupZrEKBbS+2Qe2W9Pxhre/LkXT5XzAG/Fv2
  leg8X+UEL++5z24/lY1lXsAyCVbcT5Qc0Wd3TZ/JCWRiTumQ+glCAZwn26HiteLiMuKvL2aH
  23nDTu55l7byNOP5S+xs9gfmMl8Nh5SZVIlHcTThxtrwhp4T2qrobUSTtmRNahwo0g4aYDAc
  Wt0Q5UtCUatRf7zg7vvksiJxslctS+2ShoUMw6ZkMJ1IFamwwYKuRxv9ZMgDQVJxB3W82xoS
  MP1G+SBNbApBRqumLY1cOjLNGhgpN1CFjqYKqBUCkaatnyudBx1aeXFxNut0dvCJJeJ40jc8
  jr+E2z5kP3szWtmzp9waM/g/RbFsEG+0R6iJ8h1dzKxfKUerwWAQm8pmd+mHsxuOSXo3PiKD
  b19Z3YrL1uZfHqnw320Bb1rcz5Xjx99LkY6dzZXKbhrxy8u37C9x9ZL1TxWTYcO06v5j9wOE
  vx4o/yLwc+8t6DjeXik8TeXGT8MmM83tYbP8BX2vZfzKyH5zJl1bcHeVApV6ItWfHhN8z+pl
  UmRS1MlQBialGfRx2uQIqpcJDFIc8lqu8hTrX6LyagppClUwLdVmGHoAxSsacFooaKeSuhSF
  YXeFbUs+A9XI2s/L2CJvI+oGGgfFUQKpKDvmiLLAjrROYq5Y1M81JApWrMSmgyYCgjEQBgWw
  p8aFjJxhLDHwJJgZAuSh4ua3g4i8Yby1Gw+zS/deIGxdKTupY2t4HQJlW1TWg0E7joKUqwZQ
  q4Y4aj54GoK6oZx51C1GnO/JrEmQ8FNeeZYO/1Mc6L2i+xvFTnf7z8T1nJF3vd3Xzp5sh7zM
  b+J4006x0QVA/H1zpIqcjN+7mzhBXOmKsbK+IWQ2G47S/TL9W4HU//vAbb1P8D==
}

mjd_private.ucl:ExternalRayFinder(OUTSIDE) {
::XdgTbgn29J5SzNNMQc87dm+dYJ5SSGMoVvFDlpcAOzNOr2YnqBXZPOq86TPrtcidIpxHk1+6
  v+trUIGSf42bAoquxngU5+0nj7qLh7g799b6jFiJ4l42yumfW2RRYTF4HTmcV300OIVoae2j
  pf8EeqM5pC8Jfkva5fXDvHWxhNwy2w6bvJn6BVzJXMh1phz/LguG68WNYtOnBhQO4HvDKu/X
  htpnyBgTakCM7tMuNU9fV+JaC8qFeedzncT73A8rF+A6H9Mg/oqVhoveYgeofxC/D7z95G76
  zG1v54oe2tyMIX+YTdTP9d7eIrybh5/IF3WW5fpO/iIFSDis4L/OV2RsAd+/AfN0feL6To13
  5fG8T3LP6bThm4J1MEeRO+o69g9O5sPrG5ONa5GlhpEGrWSGalSJQpmzYUOMmofRiCtgxtoy
  oVSm2x5WplxUD+EkFzgWkKS6QU5cqxRwAsTUTr/APj6vReDxdw+2mEgXnalWytOB64MaVhMt
  GNOpAJzekJbienQSw4kat1acauC5cFTSobYMrSiShhz1anwJZoEZcHTaMvO08rDN/CQzusaz
  ecPTtv379SduK775Q8Si+PwRETy0
}

mjd_private.ucl:DistanceEstimator(OUTSIDE) {
;
; Distance-estimator coloring algorithm for Mandelbrot and
; other z^n fractal types (Phoenix, Julia). This coloring
; algorithm estimates the distance to the boundary of the
; fractal (for example the Mandelbrot set) and colors points
; accordingly.
;
; Written by Damien M. Jones
;
::DfjUign29AVsONMMQ09Il/hTJLplSClRkQiBKiF2gNUlcjvUbJHfGbHRb/65sdLWewv79u39
  Ort64T1VAMSzODeCkXgnhutbgHWVXZIylZzVfxR/ieYN0eZfXBc/2VMmZvD2WXNptCTWfr2K
  ZzYnK6WbojdjiDhu2LrStc7NMUeK5y772OUknUE+xH7anFHtcQk4kYxUSaUHNIbdzr6QUYHR
  YXIqnFRy3k4VoxNpLS+aad/oa+/6RypHTEvHnNDjkh8a7xhkPShXOIvaJezxeFLM3uT4FzQO
  eJI/jJcRNZTut7kjsoN2UYumWm5x+HKlUabC38pSHggiWMS4ACBMCRC4RNqgoCB8qTANlxfX
  a/2Zi8zLGBcmWAhHhlAH/e4NyDfwrAaO4p4GuTeK8dJsIMmzcMyJDty8WUX9Hc8yY6I=
}

Incorrect UF.6 result:

Correct UF.5 result:

[edit] Placed parameter in code block

Hello,

try turning off perturbation, I assume that is what is causing the problem because whichever coloring algo you are using is relying on intermediate results that are not available when using perturbation. Some CAs require the entire orbit to be explicitly calculated. I hope this helps.

If you read my first post, I've already tried without perturbation.

I detected something strange by testing. arbitrary seams to have problems with big numbers, there where the red color is, the numbers get too big and the numbers NaN. not in extended, but in double and arbitrary. Don't know if this is related, or i made something wrong. I only changed the number in "Additional Precision".

double

extended

arbitrary

Sorry, I missed that. What happens if you manually increase precision?

//edit: I just tried your parameters and the formula does not have perturbation settings. Also, if I swap from Mandelbrot (built-in) to just Mandelbrot, the result changes completely:

Set bailout value to 1e10 and it changes back to how it's supposed to look

Ah, will try this later. But to be honest, your correct result looks like it's bugged and vice versa. Did you accidentally swap the images in your opening post?

In UF6, coloring algorithms always use double or extended precision, never arbitrary, as a general optimization. If your coloring algorithm requires arbitrary precision internally, it will give different results in UF6, so I think that explains it.

Wait, did they use arbitrary in UF5?

Ah so it IS a bug, just not the one we expected. The input fields allow for an arbitrary amount of decimals, giving the impression that the numbers are actually used as such. That's the bug. (And maybe also a documentation issue, as I read through the changelog and manual and didn't find anything about this)

Is there any workaround for this?

OK this explains my bug i found. in this case it would be good if UF not uses double but extended as a fallback in case arbitrary is requested. And a option to use arbitrary also in coloring algorithms could be useful, maybe as a switch in "default:" section. it maybe solves Mark Jeronimus bug too?

(i tried to use a tool in a coloring algorithm to find Misiurewicz points in high precision, and this not worked because of the same reason.)

I just found another reason why removing arbitrary precision from coloring was a bad idea.

The plain old Distance Estimator breaks down at magnifications above 1e76 on standard Mandelbrot.

My Better Distance Estimator (which adjusts the Color Density automatically with #magn) still breaks down at magnifications above 1e140 and high bailout values. Lowering the bailout makes it work for up to 1e149 (bailout 4) but obviously Distance Estimator will show artifacts at this bailout, and it's literally the end of zooming.

The next parameter is with the default Distance Estimator and a Color Density of 3e38. Try increasing it to 4e38 and it turns completely black.

Copy10 {
::Stz93gn2tJVPvtNMQ0dD4/DEaqdI287PiBnazSR7UXLQAtElFbkIFIpRs7v+eS2pJDVaQk39
  u39Odv+srt6Gfc7GEqGqjebzXSzXRfig/MK1j8Xqsc0NiyurlHcxwUD61QXdwK5Y0gPcaoaZ
  Y8S9jur+cxSQ9Z3kvYpC5tjWFH1PXsyVYtZfXoWsN/wlfB9NfOBseucQunh3TxU+h/kme44B
  ze9yVWz2NrMvqxW3cNki2mvvECRaQpZXboe1SwY0kvOk6sTnHrhZXpsdzkbeOEPdrWfs6zW8
  OOnpISlWwoUuSz0YJb9Llw1aiQoFYJ2QJEmgyNcO1IIYiEy8rFi4GpgoJGMXykaKla4UukCR
  pCx+Hw7YKKmDsToamRZAWhXqQJ0KORbgOZWJSzFYBWZkcDhZ0UBEgQxGjUSB9BkYMAVCQZMD
  Gr0alUsU4k7U0y2pxGimpeSp2upPlh5294t0XCLjqSghH0sP3O4bfxmTnPNgcd/+cpav6Lo+
  woPusha+Z1F7c5udn7naW4A+Zlvuskid+xj5UtBN/cp6yVLePw5zzpXhWQXPf0FGTnrWinA7
  4QsE6838UZXs0D4ipof7GAz/S15BYwij5Z63xNGieXGl9zeXFq6/Kx2xPKxvGAZFb9PVqhJX
  NlbeXd7A5cK76CA21uWmSJw9uM8wM5WNTEUAGyLWMqNNmyWwboUUi4eYmxcPBQ2d72H5CE5b
  1/mZE8Bb38XAhVB/IC==
}

Interesting. This change seemed like a good idea to me while implementing perturbation calculations, because if you still need to do a bunch of arbitrary precision math during each iteration (for the loop section of a coloring algorithm), there is hardly any speedup at all. From my testing, it didn't seem to make a difference but I can see why distance estimation would break down.

I'll investigate and see if a different approach is needed. Of course it would be possible to go back to UF5 behavior and do all coloring algorithm calculations with arbitrary precision, but that would really slow down a fractal that uses perturbation calculations in combination with e.g. an orbit trap coloring.

Another possibility would be to only use double/extended if perturbation is used and allow to turn off perturbation in the Formula tab.

I think the most people witch investigate time to create there own formulas, know at least do a degree what they do. And so it would make sense if they have the chance to make there decisions and have all tools for it. And in case is a simple info in the Help text useful for example that arbitrary precision can cause much slower calculations. And if the forum is floated whit always the same questions, the software could give a hint for optimization if the calculations are very slow.

(I usually spent way much more time for solutions and workarounds, if there is something missing, an way less if i just have all tools to make better decisions. I for example spend much time to search the error in my code, when actually the software made something unlogical and unexpected.)
(i have not checked jet if only the coloring algo not uses arbitrary precision, or the codes in libraries too, even when used in formulas...)

(Something about the perturbation, it should be a visible option. Because it uses a shortcut for the calculations, i would expect that some of my coloring algos would not work anymore. For example, some add up all results in every calculation step.)

Exactly, it would be good to have the option to force it anyway and just decide to wait it out.