Re: SOLVED: going backwards in time
2008/9/6 Adam James Wilson <[EMAIL PROTECTED]>: > Hi Han-Wen, > > Thanks for the reply. The example I sent was actually a quite simplified > version of what I'm attempting to do; there is a real possibility that in my > actual scores I will cause the 64-bit 'long long' numbers to overflow as > well. As you mentioned yourself before, I think the airtight solution is to > use rationals or arbitrary precision. Just to let you know, the next development release will have support for 64-bit rationals. I imagine arbitrary precision will have to wait for the next development cycle, since we're approaching the release of 2.12. Regards, Neil ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
On Fri, Sep 5, 2008 at 9:13 PM, Joe Neeman <[EMAIL PROTECTED]> wrote: > On Fri, 2008-09-05 at 20:37 -0300, Han-Wen Nienhuys wrote: >> I think the easiest approach is to simply move to 'long long' for the >> rational class. We could start using GUILE's rationals, but it will >> complicate memory management, so I think it's not worth the trouble. > > What about using libgmp? I think it's already a dependency for guile. Let's do the long long first. It's a no brainer. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
Hi Joe, Yes, it looks like GUILE has required GNU MP arbitrary precision arithmetic library since 2006: http://rpmfind.net/linux/RPM/opensuse/oss-factory/x86_64/guile-devel-1.8.5-17.x86_64.html Best regards, Adam On Fri, Sep 5, 2008 at 5:13 PM, Joe Neeman <[EMAIL PROTECTED]> wrote: > On Fri, 2008-09-05 at 20:37 -0300, Han-Wen Nienhuys wrote: > > I think the easiest approach is to simply move to 'long long' for the > > rational class. We could start using GUILE's rationals, but it will > > complicate memory management, so I think it's not worth the trouble. > > What about using libgmp? I think it's already a dependency for guile. > > > ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
Hi Han-Wen,
Thanks for the reply. The example I sent was actually a quite simplified
version of what I'm attempting to do; there is a real possibility that in my
actual scores I will cause the 64-bit 'long long' numbers to overflow as
well. As you mentioned yourself before, I think the airtight solution is to
use rationals or arbitrary precision.
How badly would such an overhaul complicate memory management? Isn't much
of this taken care of automatically in GUILE?
I'm willing to sponsor someone to put in the fix, whatever it takes to get
my music to render. I've invested a couple of years now into lily; it is
really the only game in town that comes close to allowing me to do what I
want.
Best regards,
Adam
On Fri, Sep 5, 2008 at 4:37 PM, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote:
> I think the easiest approach is to simply move to 'long long' for the
> rational class. We could start using GUILE's rationals, but it will
> complicate memory management, so I think it's not worth the trouble.
>
> Anyone for a patch?
>
> On Thu, Sep 4, 2008 at 6:01 PM, Adam James Wilson
> <[EMAIL PROTECTED]> wrote:
> > It looks like I'm going down a road of rhythmic complexity that breaks
> > Lilypond rendering in the absence of arbitrary precision arithmetic.
> > Han-Wen: would it be possible for me to sponsor a move to arbitrary
> > precision arithmetic? As you say, GUILE does support this option, and it
> > would be possible to select it with some sort of flag so that other users
> > wouldn't take the performance hit. Such a fix would be necessary for me
> to
> > use Lilypond to fully render my scores (I can render only a few pages at
> the
> > moment).
> > My scores typically require things like the example below, which breaks
> with
> > an "unterminated beam" error, and I *think* it is exceeding 32-bit
> precision
> > (I'm assuming that Lily is using lowest common multiple of denominators
> to
> > deal with resolution):
> > \version "2.11.56"
> > \layout {
> > \context { \Score
> > \override NonMusicalPaperColumn #'line-break-permission = ##f
> > \override NonMusicalPaperColumn #'page-break-permission = ##f
> > \override SpacingSpanner #'uniform-stretching = ##t
> > \override SpacingSpanner #'strict-note-spacing = ##t
> > proportionalNotationDuration = #(ly:make-moment 1 20)
> > ragged-right = ##t
> > }
> > \context { \Voice
> > \remove Forbid_line_break_engraver
> > \override Beam #'breakable = ##t
> > }
> > }
> > \new Staff {
> > <<
> > \new Voice {
> > \time 4/1
> > c'2.*2351/3696
> > \scaleDurations #'(495 . 4336) {
> > d'8*11[ \bar "|" \break d'8*100 d'8*100]
> > }
> > e'1*827949/8012928
> > \bar "|"
> > \time 3/8
> > c'4.
> > }
> >>>
> > }
> > %{
> > warning: unterminated beam d'8*11[ \bar "|" \break d'8*100 d'8*100]
> > [a=3696, b=34688 (denom. of 495/4366*211/8), c=8012928, d=8]
> > gcf(a,b,c,d) = 8
> > lcm(a,b,c,d) = 1027312242130944
> > 32-bit precision maxes out at 4.3 billion (less than the lcm above)
> > 64-bit is more like 18.4 quintillion
> > %}
>
>
>
> --
> Han-Wen Nienhuys - [EMAIL PROTECTED] -
> http://www.xs4all.nl/~hanwen
>
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
On Fri, 2008-09-05 at 20:37 -0300, Han-Wen Nienhuys wrote: > I think the easiest approach is to simply move to 'long long' for the > rational class. We could start using GUILE's rationals, but it will > complicate memory management, so I think it's not worth the trouble. What about using libgmp? I think it's already a dependency for guile. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
I think the easiest approach is to simply move to 'long long' for the
rational class. We could start using GUILE's rationals, but it will
complicate memory management, so I think it's not worth the trouble.
Anyone for a patch?
On Thu, Sep 4, 2008 at 6:01 PM, Adam James Wilson
<[EMAIL PROTECTED]> wrote:
> It looks like I'm going down a road of rhythmic complexity that breaks
> Lilypond rendering in the absence of arbitrary precision arithmetic.
> Han-Wen: would it be possible for me to sponsor a move to arbitrary
> precision arithmetic? As you say, GUILE does support this option, and it
> would be possible to select it with some sort of flag so that other users
> wouldn't take the performance hit. Such a fix would be necessary for me to
> use Lilypond to fully render my scores (I can render only a few pages at the
> moment).
> My scores typically require things like the example below, which breaks with
> an "unterminated beam" error, and I *think* it is exceeding 32-bit precision
> (I'm assuming that Lily is using lowest common multiple of denominators to
> deal with resolution):
> \version "2.11.56"
> \layout {
> \context { \Score
> \override NonMusicalPaperColumn #'line-break-permission = ##f
> \override NonMusicalPaperColumn #'page-break-permission = ##f
> \override SpacingSpanner #'uniform-stretching = ##t
> \override SpacingSpanner #'strict-note-spacing = ##t
> proportionalNotationDuration = #(ly:make-moment 1 20)
> ragged-right = ##t
> }
> \context { \Voice
> \remove Forbid_line_break_engraver
> \override Beam #'breakable = ##t
> }
> }
> \new Staff {
> <<
> \new Voice {
> \time 4/1
> c'2.*2351/3696
> \scaleDurations #'(495 . 4336) {
> d'8*11[ \bar "|" \break d'8*100 d'8*100]
> }
> e'1*827949/8012928
> \bar "|"
> \time 3/8
> c'4.
> }
>>>
> }
> %{
> warning: unterminated beam d'8*11[ \bar "|" \break d'8*100 d'8*100]
> [a=3696, b=34688 (denom. of 495/4366*211/8), c=8012928, d=8]
> gcf(a,b,c,d) = 8
> lcm(a,b,c,d) = 1027312242130944
> 32-bit precision maxes out at 4.3 billion (less than the lcm above)
> 64-bit is more like 18.4 quintillion
> %}
--
Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
It looks like I'm going down a road of rhythmic complexity that breaks
Lilypond rendering in the absence of arbitrary precision arithmetic.
Han-Wen: would it be possible for me to sponsor a move to arbitrary
precision arithmetic? As you say, GUILE does support this option, and it
would be possible to select it with some sort of flag so that other users
wouldn't take the performance hit. Such a fix would be necessary for me to
use Lilypond to fully render my scores (I can render only a few pages at the
moment).
My scores typically require things like the example below, which breaks with
an "unterminated beam" error, and I *think* it is exceeding 32-bit precision
(I'm assuming that Lily is using lowest common multiple of denominators to
deal with resolution):
\version "2.11.56"
\layout {
\context { \Score
\override NonMusicalPaperColumn #'line-break-permission = ##f
\override NonMusicalPaperColumn #'page-break-permission = ##f
\override SpacingSpanner #'uniform-stretching = ##t
\override SpacingSpanner #'strict-note-spacing = ##t
proportionalNotationDuration = #(ly:make-moment 1 20)
ragged-right = ##t
}
\context { \Voice
\remove Forbid_line_break_engraver
\override Beam #'breakable = ##t
}
}
\new Staff {
<<
\new Voice {
\time 4/1
c'2.*2351/3696
\scaleDurations #'(495 . 4336) {
d'8*11[ \bar "|" \break d'8*100 d'8*100]
}
e'1*827949/8012928
\bar "|"
\time 3/8
c'4.
}
>>
}
%{
warning: unterminated beam d'8*11[ \bar "|" \break d'8*100 d'8*100]
[a=3696, b=34688 (denom. of 495/4366*211/8), c=8012928, d=8]
gcf(a,b,c,d) = 8
lcm(a,b,c,d) = 1027312242130944
32-bit precision maxes out at 4.3 billion (less than the lcm above)
64-bit is more like 18.4 quintillion
%}
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
I'm all for the use of arbitrary precision arithmetic -- the slowdown in processing would not bother me at all. Trevor's idea of a compile-time choice -- defaulting to 32-bit internals -- would make everyone else happy. BTW, should one of us file a bug on this? Best, Adam On 11/29/07, Trevor Bača <[EMAIL PROTECTED]> wrote: > On Nov 29, 2007 6:28 PM, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > > > 2007/11/29, Adam James Wilson <[EMAIL PROTECTED]>: > > > > > I see -- so even with my arithmetic error (which started as a tiny > > > offset of 9/6319), we should expect Lily to render the score. > > > > > > I can see that if fractional relations get complex enough to require > > > more precision than 32-bit values, there could be a problem. > > > > > > Is a possible solution to use 64-bit representation internally? > > > > It's an option, but it's a stopgap measure. The real solution is to > > have a arbitrary precision arithmetic. GUILE already provides that, > > but it would have a slight but noticeable performance impact. > > Maybe a compile-time option to chose between the two? > > > > -- > > Trevor Bača > [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
On Nov 29, 2007 6:28 PM, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > 2007/11/29, Adam James Wilson <[EMAIL PROTECTED]>: > > I see -- so even with my arithmetic error (which started as a tiny > > offset of 9/6319), we should expect Lily to render the score. > > > > I can see that if fractional relations get complex enough to require > > more precision than 32-bit values, there could be a problem. > > > > Is a possible solution to use 64-bit representation internally? > > It's an option, but it's a stopgap measure. The real solution is to > have a arbitrary precision arithmetic. GUILE already provides that, > but it would have a slight but noticeable performance impact. Maybe a compile-time option to chose between the two? -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
2007/11/29, Adam James Wilson <[EMAIL PROTECTED]>: > I see -- so even with my arithmetic error (which started as a tiny > offset of 9/6319), we should expect Lily to render the score. > > I can see that if fractional relations get complex enough to require > more precision than 32-bit values, there could be a problem. > > Is a possible solution to use 64-bit representation internally? It's an option, but it's a stopgap measure. The real solution is to have a arbitrary precision arithmetic. GUILE already provides that, but it would have a slight but noticeable performance impact. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
Hi Han-Wen, I see -- so even with my arithmetic error (which started as a tiny offset of 9/6319), we should expect Lily to render the score. I can see that if fractional relations get complex enough to require more precision than 32-bit values, there could be a problem. Is a possible solution to use 64-bit representation internally? Best regards, Adam On 11/29/07, Han-Wen Nienhuys <[EMAIL PROTECTED]> wrote: > 2007/11/29, Trevor Bača <[EMAIL PROTECTED]>: > > > Excellent. I think what clued me in was the error message about going > > *backwards* in time ... > > > > And, yes: I think Han-Wen and the gurus really *really* got it right on the > > time-keeping: AFAICS, it's all rationals all the time and so completely > > exact. > > Actually, lily should never go backwards in time, not even if you have > really wonky time sigs and tuplets, so this is definitively a bug. > One possibility is that you have an overflow error: the rationals use > 32 bit integers, so they easily overflow if you do strange things. > > -- > Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen > ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
2007/11/29, Trevor Bača <[EMAIL PROTECTED]>: > Excellent. I think what clued me in was the error message about going > *backwards* in time ... > > And, yes: I think Han-Wen and the gurus really *really* got it right on the > time-keeping: AFAICS, it's all rationals all the time and so completely > exact. Actually, lily should never go backwards in time, not even if you have really wonky time sigs and tuplets, so this is definitively a bug. One possibility is that you have an overflow error: the rationals use 32 bit integers, so they easily overflow if you do strange things. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
On Nov 28, 2007 4:46 PM, Adam James Wilson <[EMAIL PROTECTED]> wrote: > Hi Trevor, > > As you suspected, there WAS indeed a math error -- I checked things > over yet again and found I'd entered a time signature as 4356/6319 > instead of 4365/6319. (I'm doing some things algorithmically and some > intuitively, hence the entering of some data by hand). > > I feel considerably relieved that it was my error and not Lily's! I > feel pretty confident now that I can inflict my sickest notation and > not have to worry about Lily breaking. > > Now the only thing going backwards in time (at least it feels this > way) is my compositional process! Hi Adam, Excellent. I think what clued me in was the error message about going *backwards* in time ... And, yes: I think Han-Wen and the gurus really *really* got it right on the time-keeping: AFAICS, it's all rationals all the time and so completely exact. The formal + intuitive way of working is definitely a great way to go. Maybe a quick script in python just to check things like well-formedness of time signatures and stuff could be a nice addition to your arsenal in future? Good luck with the piece! Looks amazing from the small bits I've seen ... :-) -- Trevor Bača [EMAIL PROTECTED] ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: SOLVED: going backwards in time
Hi Adam, I'd entered a time signature as 4356/6319 [...] I feel pretty confident now that I can inflict my sickest notation and not have to worry about Lily breaking. Oh, come on... 4356/6319 is your sickest notation? Wussy. ;-) Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
SOLVED: going backwards in time
Hi Trevor, As you suspected, there WAS indeed a math error -- I checked things over yet again and found I'd entered a time signature as 4356/6319 instead of 4365/6319. (I'm doing some things algorithmically and some intuitively, hence the entering of some data by hand). I feel considerably relieved that it was my error and not Lily's! I feel pretty confident now that I can inflict my sickest notation and not have to worry about Lily breaking. Now the only thing going backwards in time (at least it feels this way) is my compositional process! Best, Adam ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
