[Top][All Lists]

[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: thomasmorley65
Subject: Re: modify coord-rotate to get exact values for (sin PI) etc (issue 269530043 by address@hidden)
Date: Tue, 20 Oct 2015 22:10:50 +0000

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
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
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 ==
GS>0 -1 atan ==
GS>0 -1 atan sin ==

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)

*show angle(-1,0)

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

*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

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

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

But I fear that this radian-based approach is only half a bandaid that
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

Please correct me, if I'm somewhere (or general) wrong:
All our trigonometric stuff (and guile itself) relies on radians, as an
`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

reply via email to

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