[ODE] Length calculation

[Oleh Derevenko]

Sorry, Jon. I can see we are talking different languages. Each time you say
something different and your arguments change each time too. To be more
exact, you do not give any arguments or proofs at all - just the common
words. And that does not make any honour for you.
Now, after thinking about this formula some more time, I have realized that
I do not understand why does normalization give result much close to 1 after
division by largest vector component at all. I can invent some assumptions
like no error in one of components which becomes 1 after division or smaller
error of square root after decreasing overall magnitude of sum but I do not
see any sense in spending time to verify all that. So, if you are sure that
for length calculation the change will not give any improvement I don't
care.

Oleh Derevenko
-- ICQ: 36361783

----- Original Message ----- 
From: "Jon Watte (ODE)"
To: "Oleh Derevenko"
Cc: <ode at ode.org>
Sent: 14 жовтня 2007 р. 02:16
Subject: Re: [ODE] Length calculation


>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.
>
> Cheers,
>
>          / h+
>
>
> 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 precise).
>>>
>>
>> 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