2015-10-30 14:46 GMT+01:00 <[email protected]>: > 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
