One little addendum to an earlier message. It may actually be false that Fractint uses IEEE math. In some modes, fractint uses 80 bit "IEEE-like" numbers. I'm not an IEEE math expert, but I'm not entirely sure that 80 bit numbers as used in an Intel Floating Point Unit are legal "IEEE" (though they are very "IEEE-like"). Fractal types in fractint that are implemented 100% in assembler use pure 80 bit floating point math. In other modes implemented primarily in C, Fractint does an odd mixture - the 64 bit double precision numbers used to implement double types are IEEE, but these are converted to 80 bits briefly when passed to the math coprocessor. In my workplace (NASA) this mixed precision behavior on the Intel platform has caused some problems we don't get on machines that use pure IEEE 64 bit doubles consistently. None of this affects my negative critique of the statement that minbrots are an artifact of IEEE math. That claim is pure unadulterated hogwash. Tim
Tim Wegner:
One little addendum to an earlier message. It may actually be false that Fractint uses IEEE math. In some modes, fractint uses 80 bit "IEEE-like" numbers. I'm not an IEEE math expert, but I'm not entirely sure that 80 bit numbers as used in an Intel Floating Point Unit are legal "IEEE" (though they are very "IEEE-like"). Fractal types in fractint that are implemented 100% in assembler use pure 80 you probably meant "64 bit" ??? """""""
bit floating point math.
In other modes implemented primarily in C, Fractint does an odd mixture - the 64 bit double precision numbers used to implement double types are IEEE, but these are converted to 80 bits briefly when passed to the math coprocessor.
converted by the FPU internally? Intel(-type) Processors IIRC use 80 bit FP numbers for internal calculations and do a conversion back to 64 bit when saving the results to registers.
In my workplace (NASA) this mixed precision behavior on the Intel platform has caused some problems we don't get on machines that use pure IEEE 64 bit doubles consistently.
None of this affects my negative critique of the statement that minbrots are an artifact of IEEE math. That claim is pure unadulterated hogwash.
i agree. Too little precision results in a rectangular or quadrilateral tiling of the image. Little errors that get amplified during iterations (a special feature of fractals) *might* mess up the results (you and others probably knew). a nice example: if one implements the Gauss algorithm for solving linear equations straight out of the book without any clever pivoting strategy the result will be unusable (...my own painful experience...). But even the most sophisticated solver can fail: 64919121 * x1 - 159018721 * x2 = 1 41869520.5 * x1 - 102558961 * x2 = 0 try to reproduce the *exact* results x1=205117922, x2=83739041 with a computer using floating-point math. For example "Waterloo Maple 8" sais x1=100, x2=40.82482904. If "41869520.5" is replaced by "41869520+1/2" Maple uses its arbitrary precision rational numbers and the correct results appear. -- Michael Weitzel ... all work and no play makes Jack a dull boy ...
Michael wrote (quoting me):
One little addendum to an earlier message. It may actually be false that Fractint uses IEEE math. In some modes, fractint uses 80 bit "IEEE-like" numbers. I'm not an IEEE math expert, but I'm not entirely sure that 80 bit numbers as used in an Intel Floating Point Unit are legal "IEEE" (though they are very "IEEE-like"). Fractal types in fractint that are implemented 100% in assembler use pure 80
you probably meant "64 bit" ??? """""""
Nope, I meant 80 bits. For some fractint fractal types the math is coded in FPU assembler, and really is 80 bits.
In other modes implemented primarily in C, Fractint does an odd mixture - the 64 bit double precision numbers used to implement double types are IEEE, but these are converted to 80 bits briefly when passed to the math coprocessor.
converted by the FPU internally?
Yes.
Intel(-type) Processors IIRC use 80 bit FP numbers for internal calculations and do a conversion back to 64 bit when saving the results to registers.
If by registers, you mean the regular (non-FPU registers) this is correct. However the FPU register stack maintains values in 80 bit form exclusively, and these values CAN be copied to memory intact as 80 bit values. The old Microsoft C compiler we use for Fractint (the last one that supported the medium memory model) has an 80 bit "long double" type. (Support for this disappeared in later compilers). Once I did a huge hack of fractint for Lee Skinner in which I changed nearly all "double" types to "long double" so Lee could squeeze out another couple of orders of magnitude of precision for a very deep zoom (but not quite arbitrary precision) image he was working on. This never became part of the mainstream Fractint because there were a number of broken features, though the functionality Lee needed worked fine. (rest of Michael's interesting note is snipped) Tim
participants (2)
-
Michael Weitzel -
Tim Wegner