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.

Post a reply to this message

Attachments:
Download 'fracpos04kvd36.png' (412 KB)

Preview of image 'fracpos04kvd36.png'

And here is the 3.7RC3 one.  As you can see, we finally hit a regime where it
gets fuzzy.  And I'm assuming that this is where we've finally hit floating
point error of the machine.

Post a reply to this message

Attachments:
Download 'fracpos04kvd179.png' (392 KB)

Preview of image 'fracpos04kvd179.png'

In other words, we now have an artistic way to compare floating point error
between different machines.

Post a reply to this message

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.

Post a reply to this message

On 21/05/2011 10:09 PM, Warp 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.

How does Fractint's deep zooming work, then?

-- 
Regards
     Stephen

Post a reply to this message

Am 21.05.2011 23:14, schrieb Stephen:
> On 21/05/2011 10:09 PM, Warp 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.
>
> How does Fractint's deep zooming work, then?

There's a clue is in the program's name: 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.

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.

Post a reply to this message

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