Hal wrote:
I have run up against the loss of precisionof my Intel floatingpoint
...
Could the same type of logic that detects when to switch from integer to floating point math be used to switch from using doubles to long doubles as an alternative to (or possibly in addition to) switching to arbitrary precision math?
This is not a new idea. In one very intense weekend about ten years ago I converted double to long double across the board in fractint and more or less got it to work. I shared this with the other authors and one fractal artist. The result more or less worked, but a lot (including formula type) was broken. By way of background, the old Microsoft DOS compiler v. 9 used for Fractint has an 80 bit long double. This is perfect for our purposes because this is the data type actually used in 8087 hardware, so there is essentially no speed penalty. But there were way too many complications. 1. All the zoom logic has to support long double. 2. All the assembler interfaces break. This includes formula type 3. data stored in GIFs becomes non-portable - 80 bit long double is not an IEEE standard, and not even a standard on the intel platform (try sizeof(long double) on Linux; it's not 10.) You gain three whole orders of magnitude (or so), and then you are flat out of precision all over again. So we give you a virtual image the size of the orbit of Jupiter and than you complain that you want a virtual image larger than the solar system <grin!> You can be sure that if we did this folks would pound the zoom key a few times and resume the run-out-of-precision lament. Though I admit nobody has ever complained about the 10^1600 arbitrary precision limit (about ten visible universes enfolded in each other one after the other) <even bigger grin!> So while on the one hand you are quite right, on the other virtually the entire source code has to be massaged to gain three orders of magnitude. The effort would probably be better spent extending the scope of arbitrary precision, or getting arbitrary to work with SOI which might speed up truly deep zooms. These days just a small amount of fractint maintinence goes on, and while there are sometimes significant improvements in that small amount, large rewrites are ruled out with the current team's resources.
To give you an idea of my experience in this area, I have used long integers in calculating largeprime numbers using the MS Visual C 6.0 Visual Studio compiler. My current knowledge about Fractint's code is limited to what is described in Fractsrc.doc and Fractint.docand a quick look at the formula type code in parser.c.
Ahhh - to the best of my knowledge, that compiler does not support long double. Microsoft took it out with visual C. And as I said, the Linux long double is something else.
Does this mean that Fractint already uses long doubles in its implementation of fractal type 'formula?'
Not really ... math that stays in the math coprocessor is calculated at 80 bits. But all the in-memory variables are only 64 bits. So your data's life at 80 bits is brutish and short.
It looks like someone tried to make use of long doubles (but I don't know for what) but had to back off (I think I remember seeing somewhere that it was due to some compiler's libraries not correctly implementing some operationsusing long doubles):
BIGPORT.H ----------------- /* long double isn't supported */ /* impliment LDBL as double */ typedef double LDBL;
You were misled. Wes Loewer uses long double only to support exponent handling in his arbitrary precision library. The infuriating thing is that the Linux long double does not allocate more space for the exponent, but only the mantissa, so under Linux the arbitrary precision library doesn't work as well. The old, now dead except for us fractint guys Microsoft 80 bit long double, divides the 16 extra bits between the mantissa and exponent, so not only is the precision higher, but the dynamic range is higher too. I am very wise and know a whole lot (a humongous amount!) from working on fractint this all these years. I also know how to set the timing and adjust the points of a car, develop film (color or black and white), and build electronic gadgets out of parts like transistors and tubes <grin!>. All just about as useful as Microsoft 80 bit long double in MSC 9 using the medium memory model! <sigh!> Not to worry, other than writing these occasional notes on the fractint list I spend little time fussing about the past! Gotta get back to supporting my wife's dual-cpu Dell laptop's connectivity to my wireless network ... Tim