Re: modify coord-rotate to get exact values for (sin PI) etc (issue 269530043 by address@hidden)

[dak]

I'm not really enthused about this approach even though it originates
from a proposal of mine.  It works basically by moving around
problematic angles, leading to discontinuities at multiples of PI/4
rather than just PI being imprecise.

Fundamentally, we cannot fix this properly at the Scheme layer: even in
GUILE-2.0, we get

scheme@(guile-user)> (sin (atan 0 -1))
$1 = 1.2246467991473532e-16

I think what we should be aiming for is grounding LilyPond's offering of
trigonometric operators in degrees.

This is what PostScript offers:

GS<2>address@hidden:/usr/local/tmp/lilypond/elisp$ gsnd
GPL Ghostscript 9.15 (2014-09-22)
Copyright (C) 2014 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>-1 0 atan ==
270.0
GS>0 -1 atan ==
180.0
GS>0 -1 atan sin ==
0.0
GS>quit

This is also how METAFONT rolls:
address@hidden:/usr/local/tmp/lilypond/elisp$ mf '\\relax'
This is METAFONT, Version 2.7182818 (TeX Live 2015/dev/Debian)
(preloaded base=mf)

*show angle(-1,0)

*;
> > 180
*show sin(angle(-1,0));
> > sin
! Extra tokens will be flushed.
<to be read again>
                   (
<*> show sin(
             angle(-1,0));
?

*show sin;
> > sin
*show sind(angle(-1,0));
> > 0
*

If those graphical languages that we also work with decide it to be best
to keep off radians, maybe we should take a hint from them.

Our degree engine might even end up quite similar to what we have here,
just working for multiples of 45 rather than PI/4, whether implemented
in Scheme or C.  But the major difference is that the computer is
_guaranteed_ to have an exact representation of multiples of 45.  In
contrast, we have no guarantee that 3*(PI/4) has an exact
representation: this will only be the case if the lowest two significant
bits of the representation of PI/4 are zero since 4 > 3pi/4 > 2 and 1 >
pi/4 > 0.5 and thus the mantissa of 3pi/4 takes up two more bits in the
most significant bits.

So we can't hope to keep stuff exact when juggling with multiples of
angles in radians.

So let's rather discuss which degree-based primitives we'd rather have,
implement them, and replace everything in LilyPond juggling with angles
with them and make sure that our own commands only take degrees rather
than radians.

But I fear that this radian-based approach is only half a bandaid that
will result in this problem reappearing in different forms.

https://codereview.appspot.com/269530043/