Re: [Fractint] BUG - (all MandelbrotMix images are reflections!)
At 08:27 PM 5/26/03 +0100, Jim White wrote: <snipped>
....all images using MandelbrotMix4 are accidental reflections!....
I have long realized that all is not mathematically correct with the way the MandelbrotMix4 (and MandelbrotMix2) formulas are handled by the Fractint program. This is quite obvious when the order of the parameters is reversed and (a*z1)+(b*z2) does not equal (b*z2)+(a*z1). But what can be done about it now? If the bug were corrected, many of the older parameter files would not work. Jim M.
Mandelbrotmix4 pars computed in UltraFractal look the same as those computed in Fractint. It would be strange if both programs have the same identical bug.
Hi Lee,
Mandelbrotmix4 pars computed in UltraFractal look the same as those computed in Fractint. It would be strange if both programs have the same identical bug.
The Mandelbrotmix4 pars I rendered in UltraFractal look the same, because I used a modified formula. I added a parameter @p4 that I set to a non-zero value if needed and the init section has: if (@p4 != 0) z = conj((-a*b*g*h)^j) else z = (-a*b*g*h)^j endif Cheers, - Sylvie _________ ________ _______ ______ _____ ____ ___ __ _ E-mail address: sylvie.gallet1@libertysurf.fr Web site: in English : http://www.fractalus.com/sylvie/homepage.htm in French : http://www.fractalus.com/sylvie/homepagf.htm _________ ________ _______ ______ _____ ____ ___ __ _
To all Question:When is a bug not a bug: Answer: When it is a feature. Example: Fractints integer artifacts. I had a computer with one of the defective Pentiums and in years of calculating I never saw any problem due to it. I ran into something when I wrote my first Mandelbrot formula. I ended up with a central high count feature that looked like a three blade airplane propeller. The formula is in the Orgform collection under the name Prop, along with several variants. I always blamed it on a defect in the double precision ROM routines in the TRS80. The actual problem was that the imaginary component got it's sign reversed at every iteration. I really can't say whether the real problem was me, the ROM, or the documentation I had. Since then I have seen the same figure in two other Fractint formulas. I have lost one of them but the other, a totally different formula, produces precisely the same result. This looks strange to me. My conclusion? When you are dealing with endless repetitions on infinitesimal quantities anything can and does happen. Who can say what is right and what is wrong? Charles
Charles wrote:
My conclusion? When you are dealing with endless repetitions on infinitesimal quantities anything can and does happen. Who can say what is right and what is wrong?
The developer who is deciding what considerations deserve backward- compatibility protection with a new release is making a statement about what is "right" and what is "wrong". Integer artifacts can be very beautiful. I have even featured them in my books. But these artifacts run afoul of portability considerations, and won't be supported in future frac tint versions, which will at some point soon stop supporting integer math. Therefore, I am making a judgement that "integer artifacts are bad" :-) Just keep your old versions of fractint around! Tim
But what can be done about it now? If the bug were corrected, many of the older parameter files would not work. <<
Incredible timing - just as Jim's CD is about to be published! Many of us have hundreds of Mandelbrotmix4 images that we may want to zoom into someday. If this particular bug were fixed, the formula would have to be rewritten such that the images would be generated exactly the same. Then the parameter files would work. But how many formulas other than Mandelbrotmix4 would have to be rewritten? In this case, fixing it would probably create more problems than it solves! I'd just let it become a documented idiosyncrasy of Fractint (you won't find COSXX in trig books! or Tim'sError).
participants (5)
-
Charles F Crocker -
Jim Muth -
Lee H. Skinner -
Sylvie Gallet -
Tim Wegner