On 22/05/2011 2:13 AM, clipka wrote:
> Am 21.05.2011 23:14, schrieb Stephen:

>>
>> How does Fractint's deep zooming work, then?
>
> There's a clue is in the program's name:

Never ;-)

> It computes FRACTals using the
> computer's INTeger instructions - rather than floating point -
> implementing numeric formats with much higher precision than natively
> supported by the computer's architecture.
>

That was the question I meant to ask, how? But never mind if I'm really 
interested I suppose I can look it up.

> BTW, when Fractint first entered the scene, hardware floating point
> support was still a luxury on PCs, requiring a dedicated co-processor;
> so on most systems, those custom integer number formats didn't just
> offer higher precision, but were also at least as fast as IEEE double
> precision.

I remember trying to justify to my boss why I needed a co-processor then 
later why I needed a sound card. They did not come as standard in the 
early days.

-- 
Regards
     Stephen

Post a reply to this message

On 05/22/2011 12:14 AM, Stephen wrote:
> How does Fractint's deep zooming work, then?

   When hardware registers don't have enough precision of the required 
zoom level, it switches to calculating the values via software with much 
larger accuracies. (Obviously this is significantly slower.)

Post a reply to this message

Am 22.05.2011 09:37, schrieb Stephen:

>> It computes FRACTals using the
>> computer's INTeger instructions - rather than floating point -
>> implementing numeric formats with much higher precision than natively
>> supported by the computer's architecture.
>>
>
> That was the question I meant to ask, how? But never mind if I'm really
> interested I suppose I can look it up.

Essentially they use the same methods you'd use when doing computations 
with pen & paper, except they use 16- or 32-bit (or nowadays possibly 
64-bit) integers as "digits", i.e. base-65536 or base-42949667296 maths 
instead of base-10.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> On 05/19/2011 03:49 PM, gregjohn wrote:
> > In other words, we now have an artistic way to compare floating point error
> > between different machines.
>
>    The IEEE double-precision floating point format has 52 mantissa bits,
> and what you are seeing is hitting that limit. In other words, zooming
> any further would require more mantissa precision than that, and what
> you are seeing are the rounding errors caused by the mantissa not having
> enough bits.
>
>    The IEEE double-precision format is pretty common in most computer
> architectures, so they will all hit the limit at the same zooming level.
>
>    If the mandelbrot set were calculated using extended precision
> floating point numbers, which in the x87 have 64 mantissa bits, you
> could zoom a bit more (but not a lot) before hitting the artifacts.


Cool, thanks for the educ!   This one goes over a range (hi mag / lo mag) of
3.3E15.   How high can FractInt go??

You all may save me the embarrassment of asking someone with a more powerful
computer to run the code to compare. (Um, asking a second person).  While I do
work in computer hardware, it's on the purely physical side (processing
defects), not the system architecture side. But would every computer give the
same image for the floating point errors? Any coolness / art/ science in
comparing those?

Post a reply to this message

Am 22.05.2011 14:05, schrieb gregjohn:

> You all may save me the embarrassment of asking someone with a more powerful
> computer to run the code to compare. (Um, asking a second person).  While I do
> work in computer hardware, it's on the purely physical side (processing
> defects), not the system architecture side. But would every computer give the
> same image for the floating point errors? Any coolness / art/ science in
> comparing those?

The images are unlikely to differ much: The noise will appear at the 
same level of depth regardless of system architecture. After all, on 
virtually all systems interim results will be stored in IEEE 
double-precision floats, no more and no less.

However, depending on some compiler settings and/or system architecture 
details, the actual noise pattern may differ due to different default 
float rounding mode, differences in the precision for computations (e.g. 
extended double precision on "classic" x86 systems using the x87 
instructions, vs. standard double precision on systems supporting SSE2), 
and maybe other such details.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 22.05.2011 14:05, schrieb gregjohn:
>
> > You all may save me the embarrassment of asking someone with a more powerful
> > computer to run the code to compare. (Um, asking a second person).  While I do
> > work in computer hardware, it's on the purely physical side (processing
> > defects), not the system architecture side. But would every computer give the
> > same image for the floating point errors? Any coolness / art/ science in
> > comparing those?
>
> The images are unlikely to differ much: The noise will appear at the
> same level of depth regardless of system architecture. After all, on
> virtually all systems interim results will be stored in IEEE
> double-precision floats, no more and no less.
>
> However, depending on some compiler settings and/or system architecture
> details, the actual noise pattern may differ due to different default
> float rounding mode, differences in the precision for computations (e.g.
> extended double precision on "classic" x86 systems using the x87
> instructions, vs. standard double precision on systems supporting SSE2),
> and maybe other such details.


Interesting. I remember something years ago about how you could do some sort of
repeated calculation with a calculator and get to its floating point error
regime, and supposedly every calculator were different #declare urban_myth=off.
Exploring this concept for fun in povray.

Post a reply to this message

On 22/05/2011 10:27 AM, clipka wrote:
> Am 22.05.2011 09:37, schrieb Stephen:
>
>>> It computes FRACTals using the
>>> computer's INTeger instructions - rather than floating point -
>>> implementing numeric formats with much higher precision than natively
>>> supported by the computer's architecture.
>>>
>>
>> That was the question I meant to ask, how? But never mind if I'm really
>> interested I suppose I can look it up.
>
> Essentially they use the same methods you'd use when doing computations
> with pen & paper, except they use 16- or 32-bit (or nowadays possibly
> 64-bit) integers as "digits", i.e. base-65536 or base-42949667296 maths
> instead of base-10.

Thanks, that's just about the level I wanted.

-- 
Regards
     Stephen

Post a reply to this message

On 22/05/2011 9:32 AM, Warp wrote:
> On 05/22/2011 12:14 AM, Stephen wrote:
>> How does Fractint's deep zooming work, then?
>
> When hardware registers don't have enough precision of the required zoom
> level, it switches to calculating the values via software with much
> larger accuracies. (Obviously this is significantly slower.)

Again, Thanks

-- 
Regards
     Stephen

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:
> Povray is a million times better!
>
> The two images below show the beneft of the improvement to the mandel pattern
> pigment which is possible because of the increased limit to ITERATIONS.  Both
> images are the same essentially the same code, except for the ITERATIONS value
> in the mandel pattern.  The one with black squares at the end represents a
> povray 3.6 render, using its limit of 32000.  The other one is a frame from an
> animation where I start at 32000 and increase, using 3.7RC3, and I've probably
> increased by a factor of around 500 by this frame.
>
> As one can see, the 3.6 code looses out on what turns out to be three orders of
> magnitude in the magnification!  On an area basis, this becomes six orders!
>
> A sincere thank-you to the POV-Team for responsiveness in making improvements.

Something that's been knocking around my head for several years, now:  Has
anyone thought of implementing/using an extreme-precision number system as an
addition to the backend?

Something like the Gnu BigNum Library: http://gmplib.org/

Feel free to enlighten my ignorance.

A.D.B.

Post a reply to this message

On 05/24/2011 10:23 AM, Anthony D. Baye wrote:
> Something that's been knocking around my head for several years, now:  Has
> anyone thought of implementing/using an extreme-precision number system as an
> addition to the backend?

   Do you want the rendering to be at least a thousand times slower? 
(And that's *not* an exaggeration.)

Post a reply to this message