lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Solution to 7 over sqr(71) time against integer polyrhythms


From: David Kastrup
Subject: Re: Solution to 7 over sqr(71) time against integer polyrhythms
Date: Fri, 18 Nov 2016 10:46:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 11/17/16 7:21 PM, "mclaren" <address@hidden> wrote:
>>
>>The deceptive Lilypond code shown above that prints those fake tuplets is
>>truly contemptible because it doesn't address the real issue.  The real
>>issue is that Lilypond doesn't allow nested tuplets beyond very small
>>values
>>of tuplets (like 4:3, 7:5, etc.) for reasons having to do with internal
>>integer limits on calculations in Lilypond.  Now, that truly is
>>ridiculous.
>>We're dealing with modern computers with 4 or 8 or 16 gigs of RAM or more,
>>multi-core CPUs with full floating point units in hardware, and hard
>>drives
>>with terabytes of storage. And you're telling me all this computing power
>>is
>>incapable of calculating an approximation to .99^10 or .99^20 or .99^50?
>>You're telling me that that approximation of .99^50 can't be turned into
>>an
>>integer with some negligible error in the approximation? Please.
>
> There is a GNU library for arbitrary precision rationals.  It may be
> possible to replace the LilyPond Rational type with an arbitrary
> precision rational type.

Guile already has "arbitrary" (until your word count overflows)
precision integers and rationals.  I have already sketched the work that
would be necessary to get those in.

Using arbitrary size integers (rather than rationals) everywhere would
actually be more problematic since a whole lot of code does native
integer arithmetic for getting stuff done and used native integer types.
In contrast to that, most rational arithmetic runs through the
"Rational" type.  The "only" main problem is getting garbage collection
everywhere where a rational is being used on the heap: other than that,
one can put a wrapper around the Rational type reverting to Guile's
rationals.

> Then the ability to go to big nested tuplets would be limited by the
> amount memory (perhaps the amount on the heap or the stack).

Well, one would have to take a look at the actual tuplet handling code
as well as not all of its arithmetic will be in terms of the Rational
type.  But its error behavior should at least be, well, less erratic
until one gets all calculations in terms of just numerator and/or
denominator fixed.

> You can find more information about GMP here:  https://gmplib.org/

GMP is already linked into Guile exactly for that purpose.  It would not
really make a lot of sense to use it independently.

-- 
David Kastrup



reply via email to

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