################################################## Hal wrote:
Does anyone know if arbitrary precision math works with formula type fractals in Fractint?
Jonathan wrote: The arbitrary precision math has been implemented for only four fractal types. mandel, julia, manzpower, and julzpower.
=========================================== I have run up against the loss of precision of my Intel floating point processor on zooms in Fractint in several different images in the last week or two. Jim Muth has also mentioned reaching the limits of precision as well. This running up against the precision limitation of the current Intel floating point hardware seems to be happening more often -- most likely because the increased speed of computers allows users to more quickly zoom to the depths that get in trouble with precision limitations. In an effort to ease this problem somewhat I have the following proposal: 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? <---<< In particular, I'm guessing that using long doubles would involve doing at least the following: - duplicating existing floating point code (implemented with doubles) and - replacing all the double variables and arrays with long doubles and - adding the logic to switch between the routines using the two data types. - adding reading and writing a 3rd parameter for MATHTOLERANCE similar to the existing ones supporting MATHTOLERANCE in parameter files and .gif 1989a images. - code to support the new data type throughout Fractint. Am I correct here? <---<< I would be willing to participate in the effort involved to implement something like this (assuming it is practical) -- for the fractal type formula (even as involved as I suspect it may be), since many of Fractint's built-in fractals can be implemented as formulas. To give you an idea of my experience in this area, I have used long integers in calculating large prime 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.doc and a quick look at the formula type code in parser.c. Note that implementing long doubles for the fractal type 'formula' could remove some of the need to implement long doubles for each of the separate fractal types in Fractint since many of Fractint's built-in types can be calculated as formula files. Oops! I just read this in the 20.0 fractint.doc: Fractint Version 20.0 Page 154 -------------------------------- "Big as this zoom magnification is, your PC can do better using something called arbitrary precision math. Instead of using ***64 bit double*** precision to represent numbers, your computer software allocates as much memory as needed to create a data type supporting as many decimals of precision as you want." Does this mean that Fractint already uses long doubles in its implementation of fractal type 'formula?' <---<< However, I also note that FRACTSRC.DOC has: "parser.c uses the MathTypes: D_MATH: uses ***double precision*** routines, such as dStkMul, and FPUsincos This is used if we have a FPU. M_MATH . . . L_MATH . . ." This seems to conflict with the "64 bit double precision" in FRACTINT.DOC. I'm inclined to believe FRACTSRC.DOC... 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 operations using long doubles): BIGPORT.H ----------------- /* long double isn't supported */ /* impliment LDBL as double */ typedef double LDBL; - Hal Lane ######################### # hallane@earthlink.net # ######################### ################################################## -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.408 / Virus Database: 268.13.4/476 - Release Date: 10/14/06