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:
666ca2fd06204.png

Correct UF.5 result:
666ca2fd060d0.png

[edit] Placed parameter in code block

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: ![666ca2fd06204.png](serve/attachment&path=666ca2fd06204.png) Correct UF.5 result: ![666ca2fd060d0.png](serve/attachment&path=666ca2fd060d0.png) [edit] Placed parameter in code block
edited Jun 15 at 11:25 pm
 
0
reply

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.

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.
 
0
reply

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

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

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
66736a8ea8156.jpg

extended
66736a91340ab.jpg

arbitrary
66736a8fd2e10.jpg

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 ![66736a8ea8156.jpg](serve/attachment&path=66736a8ea8156.jpg) extended ![66736a91340ab.jpg](serve/attachment&path=66736a91340ab.jpg) arbitrary ![66736a8fd2e10.jpg](serve/attachment&path=66736a8fd2e10.jpg)
edited Jun 20 at 12:36 am
 
0
reply

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:
6674303b2e391.png

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: ![6674303b2e391.png](serve/attachment&path=6674303b2e391.png)
edited Jun 20 at 2:35 pm
 
0
reply

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

Set bailout value to 1e10 and it changes back to how it's supposed to look
edited Jun 20 at 10:33 pm
 
0
reply

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?

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?
 
0
reply

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.

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.

Ultra Fractal author

 
0
reply

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?

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?
edited Jun 21 at 1:49 pm
 
0
reply

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.)

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.)
 
0
reply

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==
}

6681342197a42.png

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== } ```` ![6681342197a42.png](serve/attachment&path=6681342197a42.png)
edited Jun 30 at 11:33 am
 
0
reply

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.

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.

Ultra Fractal author

 
0
reply

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...)

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...)
 
0
reply

(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.)

(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.)
 
0
reply

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

Exactly, it would be good to have the option to force it anyway and just decide to wait it out.
 
0
reply
216
views
15
replies
4
followers
live preview
Enter at least 10 characters.
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft