lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modify coord-rotate to get exact values for (sin PI) etc (issue 2695


From: Benkő Pál
Subject: Re: modify coord-rotate to get exact values for (sin PI) etc (issue 269530043 by address@hidden)
Date: Fri, 30 Oct 2015 16:07:41 +0100

2015-10-30 14:46 GMT+01:00  <address@hidden>:
> On 2015/10/30 13:20:35, benko.pal wrote:
>>
>> sorry to chime in that late, but:
>> am I right that the problem is that we get the rotation matrix
>> cos a   -sin a
>> sin a    cos a
>> inexact?  and if so, how the inexactness is present?  one of the
>
> diagonals is
>>
>> exactly +/-1 while the other is not exactly 0?
>> in that case I'd suggest (would have suggested) to perform a paranoid
>> normalization of the (cos a, sin a) vector, which e.g. normalizes
>> (1, 1e-9) into (1, 0).
>
>
> cos x = 1 - x^2/2 + ...
>
> So basically this "paranoid normalization" would suppress all low values
> for approximately |x| < sqrt (2 ulp) where "ulp" is the relative
> precision of our floats.
> So that looks like quite a noticeable cutoff relying on numerics.

I'm not sure I get that.  is this the description of the old problem
from a new viewpoint or an argument that if cos x equals 1 with
machine precision, we may still want a non-zero sin x?

> The
> advantage would be that the code is simpler, but once the code gets out
> of the clamped-down region, the precision would not be better.

sqrt (2 ulp) is quite a wide region; I'd think getting out of it means
we are in the wild anyway.  or that we are switching between single
and double (quadruple...) precision -- that must surely be avoided.

> I really think we should move everything to degrees except for the final
> calculations.

I'm not against that, but don't really know what are the final
calculations.  compute each (co)sine by checking first whether the
argument is an integer multiple of 90°?  or to review all our
calculations and reformulate so that each has at most one sin/cos/atan
computation?  does the problem come from functions in a "too" modular
hierarchy calling each other, converting between angles and sines back
and forth?  or would simply clamping all (co)sines with absolute value
below sqrt (2 ulp) to zero solve the practical problems at hand?

p



reply via email to

[Prev in Thread] Current Thread [Next in Thread]