KF 2.10 less minor bug

[Pauldelbrot]

KF can't seem to "lock onto" the minibrot on the real axis at -1.74876509068805410962773875505207110549828030172535743839553294443795670645244652789999995 correctly. In fact, center near this mini and KF's user interface will often freeze for extended periods, failing to update its display or accept input while reference or series calculations are occurring in particular. The control-D find minibrot Newton's method function when used near here will sometimes correctly detect the minibrot's period at 840 and its location, but will misdetect the location sometimes, or even misdetect the period as 420 or 210. Even when it detects both the period and the location correctly it misdetects the size and shows a blank black screen that turns out to be a minuscule speck in the exact center of the minibrot.

Nanoscope's code to identify minibrot size when given the exact center point seems to detect this one correctly: it spits out the numbers 37.000028089048676 and 0, which are the base 10 logarithm of the size of the full Mandelbrot relative to this minibrot (so, it's a bit over 10^37 times magnified) and the orientation (same as the main set, nose-west exactly).

Since I was given to understand that both programs use the same algorithm for this computation I find it surprising that KF isn't giving correct results while Nanoscope is. The only thing unusual about this mini is that it's exactly on the axis; could there be some corner case for y = 0 being mishandled somewhere?

[claude]

As I understand it, KF uses a modified version of code that I wrote.  My code detects the period correctly as 840 when the box radius is less than 1e-24, at 1e-23 the period is mis-detected(*) as 700, and with 1e-22 as 420; so perhaps you aren't zoomed in enough when you start the process?  Using period 840 my code computes size and orientation matching your result:  9.9993532466678371e-38 0e+00

(*) the box is large enough to contain another minibrot of lower period

In short, the problem seems to be in KF's implementation, not the algorithm itself.

[Pauldelbrot]

As I understand it, KF uses a modified version of code that I wrote.  My code detects the period correctly as 840 when the box radius is less than 1e-24, at 1e-23 the period is mis-detected(*) as 700, and with 1e-22 as 420; so perhaps you aren't zoomed in enough when you start the process?  Using period 840 my code computes size and orientation matching your result:  9.9993532466678371e-38 0e+00

(*) the box is large enough to contain another minibrot of lower period

In short, the problem seems to be in KF's implementation, not the algorithm itself.

From right on top of the minibrot (1e-36) and able to see the darn thing I end up around 1e-150 but with the correct period and center coordinates, just not the correct size; it does seem to go completely off the rails from unusually close to the mini (ordinarily, if you're halfway to the mini and pick a point near the center of the formation it will find the correct mini, but it definitely won't with this one from near 1e-19). The size being miscalculated by 113 whole orders of magnitude even from right clicking *inside the mini's cardioid* is even more unusual, to the point I'd not had that happen before. The UI skipping and hiccuping when working near this location is also not something I've otherwise seen except much, much deeper (where often after series calculations are done KF will "pause" for a while, then suddenly render a lot of the fractal at a low resolution, before acting normal from there, indicating that it was calculating from as soon as the series calculations were finished but did not start updating the display for a while afterward -- this seems to require high iterations and not just high magnification, but it gets quite bad even at moderate magnifications around e500 if the iterations are in the eight figures).