On Mon, 24 Apr 2000 19:40:49 -0500, Thorsten Froehlich wrote:
>In article <slr### [at] tealhhjpat> , 
>hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
>
>> On Sat, 22 Apr 2000 14:43:54 -0500, Thorsten Froehlich wrote:
>>>The other comparison operators do not take EPSILON into account.  So
>>>practically POV-Ray should contain a workaround for these cases as well.
>>
>> I disagree. This workaround assumes that all numbers are in a certain
>> range (about 1E-3 ... 1E6). While this may be true for most scenes it
>> certainly isn't universally true. In my scene files one pov unit is
>> always one meter, whether I am modelling the circuits of a microchip or
>> the whole solar system.
>
>Be aware that you currently cannot model a solar system in POV-Ray anyway!
>
>I think it does not make sense to have scales the way you suggest, it will
>always cause problems with floating-point precision.

Not if you know what you are doing. Of course you can't expect to have a
scene with the sun at the origin and a space ship and the camera near
pluto. But if the scene is shifted so that the camera is always near the
origin, this should work ok. Floating point arithmetic works just the
same regardless of the scale until you hit the maximum (which is about 
1e308 for IEEE doubles).

>It is also important to keep it simple for most users. Telling them
>that there are pitfalls when using floating-point math is one thing,
>forcing them to know about the exact internals behind floating-point
>math is inadequate for a user centric program like POV-Ray. In my
>opinion users should be able to use regular mathematics expressions,
>and not have to even think about precision. Your example above clearly
>shows how messy and unintuitive it would be :-)

Floating point arithmetic is somewhat messy and unintuitive, but
people have put a lot of thought into defining the rules for IEEE-754
arithmetic to make it predictable.
Adding random workarounds just makes it even more messy and unintuitive
and utterly unpredictable.

>To solve this problem it might be best to go the way a lot of programs
>go: Force maximum (and minimum) limits somewhere in the range of 10e-9
>to 10e9. Thus, if objects are placed outside this limit (the current
>one is 10e6 I think) the scene should be rejected.

Please don't do this. "Nobody needs coordinates larger than 1e9" smells
too much like "nobody needs more than 640kB RAM" or "lines longer than
1000 characters" or "text files larger than 64 kB" for me to make me
comfortable. In 15 years of working with computers I have run way too
often into stupid arbitrary limits.

	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