[ODE] Length calculation
Jon Watte (ODE)
hplus-ode at mindcontrol.org
Sat Oct 13 16:16:30 MST 2007
I am saying that the change you propose is not any more precise, for
exactly the reasons you suggest -- but the additional work for the CPU
is measurable. Thus, leave dLength3() the way it is. And if there is a
precision difference, then there's one more operation in the chain in
the proposed change case, which thus will be slightly less precise.
Oleh Derevenko wrote:
> Hi Jon
> ----- Original Message -----
> From: "Jon Watte (ODE)"
> To: "Oleh Derevenko"
> Sent: 12 жовтня 2007 р. 05:30
> Subject: Re: [ODE] Length calculation
>> Oleh Derevenko wrote:
>>> Why? Multiplications and divisions do not introduce substantial error. At
>>> the same time, length calculation, as seen from dNormalize3, is much more
>>> precise after you divide by largest vector component.
>> Do the analysis: it doesn't help. It may hurt. With the normal
>> formulation, you do math on the basic quantities. With the "normalized"
>> components, multiplied by the largest value, for very long vectors, you're
>> getting small-by-large multiplication (not any more precise), and for very
>> short vectors you're getting division-by-small-value (not any more
> Could you explain why is small-by-large multiplication not precise? In FPU
> numbers are stored in exponential form. The mantissa is always in range
> [1.0b...10.0b). So, you always multiply mantissas from range [1..2) and do
> the addition for integer exponents. Why is it less precise to multiply small
> by large rather than two numbers of same order? There is only loss of
> precision if one or both numbers are denormalized. But I don't think we
> should consider operating denormalized numbers to be a common practice. It's
> a FPU exception condition, after all, and denormalized numbers are supported
> just to save at least something from failed computation.
> Oleh Derevenko
> -- ICQ: 36361783
> ODE mailing list
> ODE at ode.org
More information about the ODE