 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] unforgettable com> 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
|_|_) | Sysadmin WSR | eingeführt und die Menschen befreit?
| | | hjp### [at] wsracat | Von was genau, ausser von ihren Köpfen?
__/ | http://www.hjp.at/ | -- Sepp Neuper in drsm ü. d. Franz. Rev.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Does this mean I won't be able to do a scene that starts on earth, flies up
into space and look at earth again with the sun included?
Nekar
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek <tek### [at] evilsuperbraincom> wrote:
: you can do 2 billion in integers). What it also means is that nothing is
: ever precise
I wouldn't say "ever". For example 1.0 + 1.0 is exactly 2.0, no more, no
less. (Well, at least if IEEE floating point numbers are used.)
Of course something like 1.1 + 1.1 may not be exactly 2.2... (mainly
because the value 1.1 can't be represented accurately in the IEEE format.)
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nekar Xenos <vir### [at] iconcoza> wrote:
: Does this mean I won't be able to do a scene that starts on earth, flies up
: into space and look at earth again with the sun included?
Everything has its price.
If you wanted variable precision floating point numbers, then povray would
be about 100 times slower than it's now. And we don't want that, do we?
So we have to use the system's own floating point numbers. They are usually
64 bit long, and you can easily see that with that amount of bits there's a
rather small set of numbers that can be represented ("small" if we are
talking about scale differences comparable to the stars and to individual
atoms). The advantage of using those is the incredible speed boost (which
is natural since the numbers are crunched in hardware).
And to answer your question: Yes, you can make a scene where you can
fly from the earth to the stars, but you can't have both things at the
same time. You have to first model the earth with big accuracy and the
stars with low accuracy, and as you fly away from one and towards the other
you have to lower the accuracy of the first and increase the accuracy of
the second.
This only means that you can't have a scene of the surface of the earth
and an extremely powerful telescope looking at the surface of another
planet (not without using tricks, that is).
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3ac8608f@news.povray.org...
> Nekar Xenos <vir### [at] iconcoza> wrote:
> : Does this mean I won't be able to do a scene that starts on earth, flies
up
> : into space and look at earth again with the sun included?
>
> Everything has its price.
> If you wanted variable precision floating point numbers, then povray
would
> be about 100 times slower than it's now. And we don't want that, do we?
> So we have to use the system's own floating point numbers. They are
usually
> 64 bit long...
>
A systems floating point numbers may well be 64-bit, but POVs aren't -
not under Windows, anyhow - take a look at the source - it uses nothing but
32-bit floats, which according to the MSDN, gives 6-7 sig. digits and a
range of 1.17549351E-38 to 3.402823466E+38. Upping all the floats to 64-bit
doubles would give a much more respectable 16-16 sig. digits and a range of
2.2250738585072014E-308 to 1.7976931348623158E+308.
--
Scott Hill
Software Engineer.
NC Graphics (Cambridge) Ltd.
Web : http://www.ncgraphics.co.uk
E-mail : sco### [at] ncgraphicsnet
ICQ : 110661991
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 10 Apr 2001 15:57:09 +0100, Scott Hill wrote:
> A systems floating point numbers may well be 64-bit, but POVs aren't -
>not under Windows, anyhow - take a look at the source - it uses nothing but
>32-bit floats, which according to the MSDN, gives 6-7 sig. digits and a
I suspect you need to look at the source again. Most important stuff is
declared as DBL, which is a typedef for double. On x86en, that's 64 bits.
The only things I can think of that are floats are color components, which
don't need 64 bits of resolution anyway.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: The only things I can think of that are floats are color components, which
: don't need 64 bits of resolution anyway.
If I read the source code correctly, there's another thing which is stored
with 32-bit floats (using the SNGL data type): Triangle mesh vertices and
normals.
I really don't like this (since meshes are usually HUGE with lots of
tiny details), but I suppose it's done so for memory saving reasons.
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Tue, 10 Apr 2001 15:57:09 +0100, Scott Hill wrote:
> > A systems floating point numbers may well be 64-bit, but POVs
aren't -
> >not under Windows, anyhow - take a look at the source - it uses nothing
but
> >32-bit floats, which according to the MSDN, gives 6-7 sig. digits and a
>
> I suspect you need to look at the source again. Most important stuff is
> declared as DBL, which is a typedef for double. On x86en, that's 64 bits.
> The only things I can think of that are floats are color components, which
> don't need 64 bits of resolution anyway.
>
Well, as I don't have a copy of the source handy I'll have to take your
word for it. However, I'm sure when I looked at the source (to self : or was
it the MegaPOV source ?) everything used SNGL - I remember because I started
going through changing everything to DBL. My memory could be in error, but
if it is, I've got no idea what is I could be miss-remembering.
Odd.
--
Scott Hill
Software Engineer.
NC Graphics (Cambridge) Ltd.
Web : http://www.ncgraphics.co.uk
E-mail : sco### [at] ncgraphicsnet
ICQ : 110661991
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Scott Hill <sco### [at] ncgraphicsnet> wrote:
: However, I'm sure when I looked at the source (to self : or was
: it the MegaPOV source ?) everything used SNGL - I remember because I started
: going through changing everything to DBL. My memory could be in error, but
: if it is, I've got no idea what is I could be miss-remembering.
In the povray 3.1 source directory:
% cat *.c *.h | grep -c "DBL"
1645
% cat *.c *.h | grep -c "SNGL"
72
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
: % cat *.c *.h | grep -c "DBL"
: 1645
: % cat *.c *.h | grep -c "SNGL"
: 72
And by the way, that's only the number of _lines_ where those words
appear, not the total count of appearances.
A more sophisticated command (read: kludge) can count the total number
of appearances:
% cat *.c *.h | grep "DBL" | perl -pe 's/DBL/\nDBL\n/g' | grep -c "DBL"
2054
% cat *.c *.h | grep "SNGL" | perl -pe 's/SNGL/\nSNGL\n/g' | grep -c "SNGL"
78
--
char*i="b[7FK@`3NB6>B:b3O6>:B:b3O6><`3:;8:6f733:>::b?7B>:>^B>C73;S1";
main(_,c,m){for(m=32;c=*i++-49;c&m?puts(""):m)for(_=(
c/4)&7;putchar(m),_--?m:(_=(1<<(c&3))-1,(m^=3)&3););} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12 Apr 2001 11:22:19 -0400, Warp wrote:
>% cat *.c *.h | grep "DBL" | perl -pe 's/DBL/\nDBL\n/g' | grep -c "DBL"
Or the much shorter
$ cat *.h *.c | perl -0 -ne "print scalar s/DBL//g"
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
