Well... there is no reason to avoid division by zero, and even less
reasons to return a null vector instead of (1,0,0) or something like
this.
If a division by zero makes the program crash, so should do the
normalization of a null vector. But this is still not the problem here
: vectors are not null at all, they are just "something small" with
respect to what the developper of wm3 considered "small", arbitrarily.
In my understanding of number representations (someone will correct me
perhaps), there is no less precision when computing the norm of
(2e-20, 1e-20, 0) compared to the norm of (2e+20, 1e+20, 0). That is
why this tolerance makes no sense.
Think to it as a matter of units, like in previous Janek mail. If one
wants to define the simulation with lengths in gigakilometers, and get
coordinates in the range 10e-30 - 10e-32, no "tolerance" should
prevent it.
That is true. On the other hand, you want to balance the inherent
numerical imprecision from limited number of binary positions for the
number representation. The proper way is to define a "characteristic
length" for your simulation, by which you always scale some _relative_
tolerance. (Obviously adds some multiplications, but not much.)
Wm3 was conceived for graphics and games, therefore it can rightfully
suppose that 1e-8 (or 1e-20, which is value I changed it to about half
year ago) is probably close enough to zero.
If we just remove any tolerance checks, we would get a few infinities,
but that shouldn't hurt. In some cases, however, this is not desirable,
like computing Quaternion from (0,0,1) to (0,0,-1), IIRC.
Vaclav
