[Lilypond-auto] Issue 3085 in lilypond: Replace C++ rational with Scheme implementation

[lilypond]

Status: Accepted
Owner: ----
Labels: Type-Enhancement

New issue 3085 by address@hidden: Replace C++ rational with Scheme  
implementation
http://code.google.com/p/lilypond/issues/detail?id=3085


Reported by project member address@hidden, Today (1 minute ago)

Based on these threads:
http://lists.gnu.org/archive/html/bug-lilypond/2013-01/msg00026.html
http://lists.gnu.org/archive/html/lilypond-user/2013-01/msg00053.html

On Fri, Jan 04, 2013 at 10:22:02AM -0000, Trevor Daniels wrote:

> David Kastrup wrote Friday, January 04, 2013 9:15 AM

> > "Trevor Daniels" <address@hidden> writes:
> >
> >> David Kastrup wrote Friday, January 04, 2013 8:21 AM
> >>
> >>> Oscar Dub <address@hidden> writes:
> >>>>
> >>>> From a user perspective, I thought it might be nice for the compiler
> >>>> to send out some kind of error or warning message. Currently there's
> >>>> no sign of anything wrong except the final output. Is this valid
> >>>> enough an issue to be worth a quick bug report?
> >>>
> >>> Overflow in C++ Rational arithmetic would take effort to reliably and
> >>> would complicate the code base considerably.  At some point of time,  
> the
> >>> Rational class will likely get replaced with Scheme rationals (which
> >>> have "arbitrary precision") and the problem will go away.
> >>
> >> Until then we ought to document this as a "Known issue" in NR 1.2.1
> >> under Scaling durations.
> >>
> >> Copying to Bug list so bug squad can raise a Doc issue if they agree.
> >
> > I disagree.  LilyPond uses "Rational" in a number of places, like for
> > alterations/accidentals/tunings, time management in general, and... uh.
> >
> [snip long list]
> >
> > Uh, possibly something in relation to beaming.  That would seem to be
> > about it.  But at any rate, there are oodles of places in LilyPond where
> > you can trigger silent overflow in non-Guile types.  Totally not
> > restricted to duration scales.

> True, but which of these have a simple documented user command
> like *m/n which could provoke the problem, and how many have a
> demonstrated example of a user encountering it?  Those criteria are the
> important ones, together with the knowledge that the issue is unlikely to
> be fixed, in deciding what should be documented as a Known issue.

Oscar has run into a known issue with the limited precision of
Rational in Lilypond.

Although David is correct that this issue can crop up in many places
it makes sense to follow Trevor's suggestion and warn future users who
may end up with the same issue encountered by Oscar.

Also, we need a tracker to have the C++ rational replaced with a
Scheme implementation with unlimited precision. I had a look on the
tracker:

http://code.google.com/p/lilypond/issues/list?can=2&q=rational

There does not seem to be an existing issue tracker for this.

So, I suggest a tracker for the documentation enhancement, and another
to capture the idea of replacing the existing C++ rational
implementation with an arbitrary precision implementation. That second
tracker may trigger a debate about performance but I'd prefer that
took place on the tracker rather than here on the bug list.