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

[thomasmorley65]

This oe is about radians vs degrees

On 2015/10/20 14:25:21, dak wrote:
> 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.

I can't follow all of your explanations, but it's clear what you
demonstrate.


> 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.

Well, I'd happily agree, though I've not the slightest clue how to get
(sin what-ever-degree) work.
(You know I'm a schemer. If other languages come into play, I'm at a
loss)

Please correct me, if I'm somewhere (or general) wrong:
All our trigonometric stuff (and guile itself) relies on radians, as an
example:
`sin' is a guile-procedure _expecting_ a radians.
Thus, we would need to define our own sin-ly (or however we wold call
it) and I don't even know where to start such a task.

I thought about using polar-coordinates, but at some point PI (and not a
degree) needs to be introduced, see our `polar->rectangular'

Otoh, I'd really like a degree-based approach, any hint would be
welcome.

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