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

[thomasmorley65]

On 2015/10/21 09:32:07, dak wrote:

https://codereview.appspot.com/269530043/diff/40001/scm/lily-library.scm
> File scm/lily-library.scm (right):


https://codereview.appspot.com/269530043/diff/40001/scm/lily-library.scm#newcode721
> scm/lily-library.scm:721: (moved-angle (- angle (/ (* quadrant PI)
2)))
> Ok, let's just tackle this as a theoretical exercise since I remain
unconvinced
> that we are doing ourselves much of a favor straying from degrees
except at the
> final step.  Then angle-0-2pi is basically an independent source of
numerical
> ambiguity we want to avoid.  So I'd probably do it as follows:

> (let* ((quadrant
>         (inexact->exact (round (/ angle PI/2))))
>         (moved-angle (- angle (* quadrant PI/2)))
>         (s (sin moved-angle))
>         (c (cos moved-angle))
>         (x (coord-x coordinate))
>         (y (coord-y coordinate)))
>    (case (modulo quadrant 4)
>      ((0) % -45 .. 45
>       (cons ...))
>      ((1) % 45 .. 135
>       (cons ...))
>      ((2) % 135 .. 225
>       (cons ...))
>      ((3) % 225 .. 315
>       (cons ...))))

> Note that this retains the problem that (* quadrant PI/2) might just
> not be properly representable which can make the whole exercise end up
> still not delivering perfect values for 3*PI/2 or 5*PI/2 or similar,
> depending on just how those values were arrived at.  However,

> (* exact-integer PI/2) likely has about the best chance to match
> values that the user arrived with using similar expressions of his
> own.  I'd also don't make two separate case statements for cos and sin
> since that's likely a construct that is a bit expensive.

Changed it following your proposal.
Up to now I found no drawback.


https://codereview.appspot.com/269530043/diff/40001/scm/lily-library.scm#newcode751
> scm/lily-library.scm:751: (cyclic-base-value (+ value cycle) cycle))
> On 2015/10/20 23:06:58, thomasmorley651 wrote:
> > what are those red dots??
> > Never seen them before.

> Spaces before tabs would be my guess.  Or just generally a spacing
change.
> either of the two.

Must be spacing change then



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