On 3 Sep 2000 12:01:19 -0400, Warp wrote:
>Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
>:>  And if integers are ever implemented in povray, there should be a very long
>:>integer type (at least 64 bits) anyways :)
>
>: In which case the space advantage of integers would vanish. 
>
>  I said "there should be *A* very long integer type".
>  I did NOT say "the integer type of povray should be very long".
>
>  The first statement doesn't imply there could not be a shorter integer
>as well.

Sorry, I misread that. But I disagree. Types of different size are fine
for low-level languages like C (<flamebait>or Java</flamebait>), but I
don't think they are very useful for Povray. 

Basically, I think using double for everything (like it is now) is the
best solution: It has a reasonable range, accuracy and speed as an FP
number. It can be used as a perfectly accurate 54-bit integer number. 
There is only one type, so the user doesn't have to think about whether
automatic type conversion will do the right thing or whether he must
insert casts. 

Integers smaller than a double have an advantage (memory- and speedwise)
mainly if there are a lot of them. Maybe adding an element type (single
(32-bit float), int_32, int_16, int_8, int_1 (aka boolean)) to arrays
would make sense. Same might be true for some builtin types (e.g.,
meshes). Are height fields stored internally as mesh of
3d-double-precision vectors or as a 2D-array of integer numbers?

But I'm not too sure of that. Does anybody here have scenes with really
large arrays, where the parsing overhead is *not* the bottleneck?

For some applications a double FP isn't precise enough. int_64 and long
double (80 bit on Intel, up to 128 bit on some other architectures) have
good HW support, but also finite precision and range. An arbitrary
precision type would be nice, but I think it would be really bad on
performance, since it would probably have to be used everywhere to avoid
nasty surprises.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message