![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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'
![fracpos04kvd36.png](/povray.binaries.images/attachment/%3Cweb.4dd3ae99b89b3ad534d207310%40news.povray.org%3E/fracpos04kvd36.png?ttop=443866&toff=2000&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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'
![fracpos04kvd179.png](/povray.binaries.images/attachment/%3Cweb.4dd3af4732f6f13a34d207310%40news.povray.org%3E/fracpos04kvd179.png?ttop=443866&toff=2000&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In other words, we now have an artistic way to compare floating point error
between different machines.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Warp
Subject: Re: Finally reaching the floating point error regime: an homage to POV-Team
Date: 21 May 2011 17:09:15
Message: <4dd829fb@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Stephen
Subject: Re: Finally reaching the floating point error regime: an homage toPOV-Team
Date: 21 May 2011 17:14:21
Message: <4dd82b2d@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: Finally reaching the floating point error regime: an homage toPOV-Team
Date: 21 May 2011 21:13:48
Message: <4dd8634c$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Stephen
Subject: Re: Finally reaching the floating point error regime: an homage toPOV-Team
Date: 22 May 2011 03:37:24
Message: <4dd8bd34@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Warp
Subject: Re: Finally reaching the floating point error regime: an homage toPOV-Team
Date: 22 May 2011 04:32:20
Message: <4dd8ca14@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: Finally reaching the floating point error regime: an homage toPOV-Team
Date: 22 May 2011 05:27:40
Message: <4dd8d70c$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |