lilypond-devel
[Top][All Lists]

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

 From: dak Subject: Re: modify coord-rotate to get exact values for (sin PI) etc (issue 269530043 by address@hidden) Date: Tue, 20 Oct 2015 14:25:21 +0000

```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:

GPL Ghostscript 9.15 (2014-09-22)
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:
This is METAFONT, Version 2.7182818 (TeX Live 2015/dev/Debian)

*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

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