 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
just wondering, since the Amd64 CPUs (or general 64 bit ones) are getting
more popular, wouldnt it be a good idea to use 32.32 fixed floats?
All basic math on them can be done as on 64 bit integers AFAIR, and they
offer size of about -2,000,000,000 .. +2,000,000,000 with precision of
.0000000004 with seems realy enought for PovRay needs (anyway using in scene
values below 0.0001 and in some conditions even below 0.001 leed to some
distortions).
And such match should be very fast I quess...?
--
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Raf256 <u97### [at] raf256 com> Friday 01 of July 2005 18:23
> offer size of about -2,000,000,000 .. +2,000,000,000 with precision of
As theJackal just pointed me (at irc) operations like mul or pow are
strongly limited, but even raising size to power 3 (in example in
lightsource fading code etc) limits the maximum scene size... but then
again changing math to 48.16 format allows max scene size of 100,000 (all
above that is "infinity") while leaving precision of minimum size/detail at
abot .00003
It might need some strange code (like skysphere made of sphere of radius
1,000,000) to be adjusted, but I think it might be really wort the effort.
B w, perhaps it would be not bad idea to move someday PovRay to C++ code? As
in - leave it as it is (do NOT rewrite it as object-oriented program) but
use of some benefits, like overloading of operators - this would make
changing the base math types very easy (just one #ifdef
typdef float tPovGeometry or like typedef tMath48_16 tPovGeometry)
while resulting code (using nowday compilers) should be the same in speed
(only a little longer compilation time)...?
--
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Raf256 <spa### [at] raf256cominvalid> wrote:
> All basic math on them can be done as on 64 bit integers AFAIR, and they
> offer size of about -2,000,000,000 .. +2,000,000,000 with precision of
> .0000000004 with seems realy enought for PovRay needs (anyway using in scene
> values below 0.0001 and in some conditions even below 0.001 leed to some
> distortions).
Take into account that calculations may temporarily get values which
are much higher (or smaller) than the dimensions of the scene.
One simple example: Calculating the distance between two points is
done with sqrt(x*x+y*y+z*z) where <x,y,z> is the vector between the
two points. You can easily see from that formula that it temporarly
gets values very much larger than x, y or z alone.
Floating point math is quite ideal for this because it works just
perfectly for these kinds of calculations.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Besides, why would you want to? In modern processors floating point
math is about as fast as integer math. In fact, in some processors
floating point math is actually faster.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Raf256 <spa### [at] raf256cominvalid> wrote:
> It might need some strange code (like skysphere made of sphere of radius
> 1,000,000) to be adjusted, but I think it might be really wort the effort.
Why? Are you expecting some speedup? I believe you would get a
disappointment.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
