What's the largest number POV-Ray can correctly handle (for instance,
when specifying translation values or the size of an object)? I always
thought the ceiling was in the billions somewhere, but I'm getting
unexpected results around ten million or so.. frustrating, to say the least.

-Xplo

Post a reply to this message

As I understand it POV does everything in floating point, which means the
largest number is ridiculously big (I expect way more than billions, 'cause
you can do 2 billion in integers). What it also means is that nothing is
ever precise, floating points suffer from a variable accuracy. so the bigger
the number the bigger the errors.

Dunno if that's of much help :(

--
Tek
http://www.evilsuperbrain.com

Xplo Eristotle <inq### [at] unforgettablecom> wrote in message
news:3AC4B481.CBB3238C@unforgettable.com...
> What's the largest number POV-Ray can correctly handle (for instance,
> when specifying translation values or the size of an object)? I always
> thought the ceiling was in the billions somewhere, but I'm getting
> unexpected results around ten million or so.. frustrating, to say the
least.
>
> -Xplo

Post a reply to this message

On 2001-03-30 22:15, Tek <tek### [at] evilsuperbraincom> wrote:
> Xplo Eristotle <inq### [at] unforgettablecom> wrote in message
> news:3AC4B481.CBB3238C@unforgettable.com...
>> What's the largest number POV-Ray can correctly handle (for instance,
>> when specifying translation values or the size of an object)? I
>> always thought the ceiling was in the billions somewhere, but I'm
>> getting unexpected results around ten million or so.. frustrating, to
>> say the least.
>
> As I understand it POV does everything in floating point, which
> means the largest number is ridiculously big (I expect way more than
> billions, 'cause you can do 2 billion in integers).

I think there is no fixed upper (and lower) limit on the numbers you can
use in povray. It depends a lot on what you are doing.

For example, let's say you have 1 point at <1E10, 0, 0> and one at
<1E10, 1, 0>. Both positions can be represented exactly with double
precision floating point numbers, so that's not a problem. Now, let's
assume that Povray needs for some reason to compare their distances
to the origin. 1E20 can be represented exactly in a double, but 1E20+1
cannot and will be rounded to 1E20, so to povray both points will seem
to have exactly the same distance from the origin.

In addition to the inaccuracies inherent in fp computation, povray
sometimes compares against arbitrarily chosen "magic numbers". If your
numbers are much larger or much smaller than the authors of povray
thought anyone would ever need, those comparisons don't yield the
expected results. For example, I once tried to model the solar system
with a pov-unit of 1 km. The sun wasn't visible from the earth.
When I changed the pov-unit to 1 Mm, it magically appeared.

> What it also means is that nothing is ever precise,

This is not true. There are a lot of numbers (approximately 2^64) which
can be represented precicely in a double. Of course, compared to the
infinity of real numbers, that's not much, but it is a lot more than can
can be represented precicely in an integer.

> floating points suffer from a variable accuracy. so the bigger the
> number the bigger the errors.

The conclusion is true, but I'd say this is because the accuracy is
constant, not variable (i.e., it is always about 16 decimal places,
whether you use small or large numbers).

	hp


-- 
   _  | Peter J. Holzer    | Und *da* wurde also die Demokratie

Post a reply to this message

> There are a lot of numbers (approximately 2^64) which
> can be represented precicely in a double. Of course, compared to the
> infinity of real numbers, that's not much, but it is a lot more than can
> can be represented precicely in an integer.

I hate to point out the obvious, but a double float can only exactly
represent the same number of values as a double integer (they're both
64-bit) :) Though your other points were very informative, thanks.

> > floating points suffer from a variable accuracy. so the bigger the
> > number the bigger the errors.
>
> The conclusion is true, but I'd say this is because the accuracy is
> constant, not variable (i.e., it is always about 16 decimal places,
> whether you use small or large numbers).

I must confess I've never really got the hang of raising numbers to an
exponent, despite having a maths degree ;)

--
Tek
http://www.evilsuperbrain.com

Post a reply to this message

"Peter J. Holzer" wrote:
> 
> In addition to the inaccuracies inherent in fp computation, povray
> sometimes compares against arbitrarily chosen "magic numbers". If your
> numbers are much larger or much smaller than the authors of povray
> thought anyone would ever need, those comparisons don't yield the
> expected results. For example, I once tried to model the solar system
> with a pov-unit of 1 km. The sun wasn't visible from the earth.
> When I changed the pov-unit to 1 Mm, it magically appeared.

That sounds almost exactly like my problem. So this is, in fact, a
long-standing bug in POV-Ray?

-Xplo

Post a reply to this message

On Sat, 31 Mar 2001 23:03:49 +0200, Peter J. Holzer wrote:
[lots of reasons why precision can be nonintuitive in POV]

There's another reason you might have missed: the actual number that
POV uses to determine whether and where an intersection took place might
be much larger or smaller than the dimensions of the object.  Some 
surprisingly common objects might use the square of a dimension, which
has of course roughly double the exponent and can be a lot larger or
a lot smaller than the primary dimension of the object.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Sat, 31 Mar 2001 11:19:04 -0700, Xplo Eristotle wrote:
>That sounds almost exactly like my problem. So this is, in fact, a
>long-standing bug in POV-Ray?

Not a bug.  A design flaw, perhaps, but not a bug.  POV-Ray is not 
designed to do full-scale simulations of microscopic or astronomical
distances, and especially not of both in the same scene.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:
> 
> There's another reason you might have missed: the actual number that
> POV uses to determine whether and where an intersection took place might
> be much larger or smaller than the dimensions of the object.  Some
> surprisingly common objects might use the square of a dimension, which
> has of course roughly double the exponent and can be a lot larger or
> a lot smaller than the primary dimension of the object.

Well, I can take a scene that works as expected and scale it up
proportionally a bit at a time until it suddenly starts going weird (I
have in fact tested this, to make sure the problem is with POV-Ray and
not my math).

As far as the design flaw goes.. well, I'm primarily modelling
geological distances, not astronomical ones. One would think/hope that
POV-Ray would be flexible enough to do so in feet, especially since it
can theoretically handle numbers much larger than the ones I'm actually
using anyway. I have to say, I'm a bit disappointed (although I'm aware
that some other software has much stricter arbitrary limits).

-Xplo

Post a reply to this message

> I hate to point out the obvious, but a double float can only exactly
> represent the same number of values as a double integer (they're
both
> 64-bit) :) Though your other points were very informative, thanks.

the number of valid FPs is less than 2^64 ...
There are some combinations that are not allowed...
consider 0E1 and 0E10 and 0E100 ...
they are the same number, numerically.
to make them compareable in memory, they'll get normalized...
mostly they'll be saved as 0E0 (that is not 0^0 but 0*(10^0)) and the
other combinations are used to represent some special states of the
FP-Unit for example "NaN"

So we can conclude: 64Int can represent more numbers than 64Float

.... just my peanuts ...

--
background{rgb 1}camera{location<1,5,-2>look_at 0}#macro
m(a,b,i)#local d=(b-a)
/8;#local
e=vcross(d,y);#if(i)m(a-e,a+e+2*d,i-1)m(a+e,a+2*d-e,i-1)m(a+3*d-e,a+e
+3*d,i-1)m(a+3*d-e,a+5*d-e,i-1)m(a+6*d-e,a+e+6*d,i-1)m(a+8*d-e,a+e+8*d
,i-1)#else
cylinder{a,b,vlength(d)/3 pigment{rgb 0}}#end#end m(-4*x,2*x,4) // Jan
Walzer

Post a reply to this message

Xplo Eristotle wrote in message <3AC4B481.CBB3238C@unforgettable.com>...
> What's the largest number POV-Ray can correctly handle (for instance,
> when specifying translation values or the size of an object)? I always
> thought the ceiling was in the billions somewhere, but I'm getting
> unexpected results around ten million or so.. frustrating, to say the least.


I think there is no easy answer or even no answer

at first : accuracy could depends of platform - bits per float value, algorithm
for simple math functions in coproc

second : there are some constant limits different for some parts of source code

third : accuracy depends of important positions in number - ie. 123456700000
could be handle as well as 0.00000001234567
becouse it is handle as 1234567*10^N - but 123456700000.00000001234567 produces
aproximation in handling

fourth : there is agregation of error in nearly every operation providing to
point on image

ABX

Post a reply to this message