From: noring@netcom.com (Jon Noring)
Newsgroups: alt.fractals
Subject: Re: Fractint & 64-bit math
Date: 27 Aug 92 18:23:55 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

In article bert.tyler@satalink.com (Bert Tyler) writes:

>CP>One point I have never quite understood.  Why does fractint _ever_ use
>CP>floating point for mandlebrots?  Surely as the rang of numbers is allways
>CP>somehwere around .1 to 16 in magnitude, all that frigging around with
>CP>exponent is just a complete waste of time.  Going to 64bit fixed point
>CP>would be much more usefull.

In article bert.tyler@satalink.com (Bert Tyler) replies:

>The problem with using scaled 32-bit integer math is that you've only got
>32 bits available with which to represent the number.  There's only
>somewhere between nine and ten decimal digits of accuracy to play
>with.  The floating-point values 1.23456789012 and 1.23456789013 end
>up being scaled to the same long integer, which tends to wreak havoc
>when those two numbers represent the X-coordinate at the left and
>right edges of the screen <grin>.  Hence our switch to floating-point
>math when we hit the precision loss.
>
>We could certainly switch to 64-bit integer math at that point. The
>problem with that approach (aside from the fact that we'd have to
>rip Fractint apart to implement it) is that 64-bit integer math is
>slower than floating-point math (if you have an FPU) across the entire
>Intel CPU line.
>
>Simulating a 64-bit integer multiply with 32-bit integer math involves
>four multiplies.  On a 386 with an FPU, using floating-point math instead
>would be slightly faster - and on a 486, floating-point math would be
>significantly faster.  On a 286-and-below, a 64-bit integer multiply
>involves using 16-bit integer math and 16 multiplies - and 286-and-below
>CPUs perform their integer multiplies relatively slowly.  There's
>really no gain on *any* system unless you don't have an FPU, and IMHO
>it's just not worth the agony to go through all the effort required to
>add a feature that only assists deeply-zoomed images and then only if
>you don't have an FPU.  That's just my opinion, though, and I invite
>anyone with an alternate opinion to go ahead an implement 64-bit
>integer math in Fractint - we're always looking for new authors.


I'm a little slow when it comes to these things, but how much more can one
zoom with 64-bit integer math compared to the current floating point math
implementation on Fractint 17?  My experiments with extreme zooms on the
Mandelbrot indicate that a zoom of about 10^12 is about the limit for
floating point.  However, I've seen some interesting images from higher zooms
of the Mandelbrot set (10^26 to 10^40), and I'd like to be able to generate
them using Fractint, but I can't at the present.

If 64-bit integer math can allow a zoom to 10^25 or greater, then I would
certainly like to see it implemented in Fractint.  My lack of programming
skills precludes me from taking on such an implementation, though.  Any
takers out there?  :^)

Jon Noring

-- 
=============================================================================
| Jon Noring          | noring@netcom.netcom.com | "The dogs bark, but the  |
| JKN International   | IP    : 192.100.81.100   |  caravan moves on."      |
| 1312 Carlton Place  | Phone : (510) 294-8153   | "Pack your lunch, sit in |
| Livermore, CA 94550 | V-Mail: (510) 862-1101   |  the bushes, and watch." |
=============================================================================
"If your annual income today is $50,000, you have the same buying power as
the average coal miner did in 1949, adjusted for taxes and inflation," John
Sestina, nationally recognized Certified Financial Planner;  quoted in 1987.
Xref: sparky alt.fractals:1384 comp.compression:3142