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