Re: \tempo should accept floats

[David Kastrup]

Werner LEMBERG  writes:

>> Sorry I can’t comment on techniques of implementation, but for
>> user’s sake we should allow input like
>>
>>   \tempo 2 = 86.83
>>
>> and have Lily output exactly that number, as it was input.

And what happens to

\tempo 2 = #(/ 155 2)

?  Or any tempo that is the result of calculation?  "For user's sake"
mixing up input and representation to some incoherent mess where values
aren't values any more is ultimately not even doing the elusive "user"
any favor.

> I rather sugggest an extension to have something like
>
>   \tempo  = #'( . )
>
> (or whatever syntax is appropriate) so that we have a textual
> representation of the tempo in the cdr element that gets printed.  The
> car element could then be restricted, say, to fractions.
>
> Example:
>
>   \tempo 2 = #'(8683/1000 . "86.83")

Well, there _is_ #e86.83 to save you from getting your fraction wrong by
an order of magnitude...

So we have a technically feasible proposal on the table.  But, well,
ugh?  I think we are better off with some solution with fixed formatting
(say, ~,1f for inexact numbers) and with the possibility to just use an
override for specifying the desired markup.

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[Werner LEMBERG]

> Sorry I can’t comment on techniques of implementation, but for
> user’s sake we should allow input like
>
>   \tempo 2 = 86.83
>
> and have Lily output exactly that number, as it was input.

I rather sugggest an extension to have something like

  \tempo  = #'( . )

(or whatever syntax is appropriate) so that we have a textual
representation of the tempo in the cdr element that gets printed.  The
car element could then be restricted, say, to fractions.

Example:

  \tempo 2 = #'(8683/1000 . "86.83")


 Werner
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[Simon Albrecht]

Am 28.03.2017 um 18:41 schrieb David Kastrup:

So I’d consider it
sensible to additionally allow_only_  numbers in the form \tempo 4 =
123.45…  (there should be no point in restricting the number of
‘post-point digits’) (sorry, I’m not familiar with English
mathematical terminology)

This is not how (binary) floating point works.

100.1 may well be 100.09997 or similar.  There is absolutely no
issue with letting LilyPond_accept_  non-integers.  But I don't see a
plan how it could or should then go about formatting them.


Sorry I can’t comment on techniques of implementation, but for user’s 
sake we should allow input like

\tempo 2 = 86.83
and have Lily output exactly that number, as it was input.

Adapting this to a ‘locale’ or ‘output language’ would be a different 
issue: ideally, if it is specified as german,

\tempo 4 = 92.01
would be printed with 92,01 as the number. But LilyPond doesn’t have 
such a feature anyway (cf. 
…), so that need 
not be considered right now, does it?


Best, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[Simon Albrecht]

Am 28.03.2017 um 18:41 schrieb David Kastrup:

So I’d consider it
sensible to additionally allow_only_  numbers in the form \tempo 4 =
123.45…  (there should be no point in restricting the number of
‘post-point digits’) (sorry, I’m not familiar with English
mathematical terminology)

This is not how (binary) floating point works.

100.1 may well be 100.09997 or similar.  There is absolutely no
issue with letting LilyPond_accept_  non-integers.  But I don't see a
plan how it could or should then go about formatting them.


Sorry I can’t comment on techniques of implementation, but for user’s 
sake we should allow input like

\tempo 2 = 86.83
and have Lily output exactly that number, as it was input.

Adapting this to a ‘locale’ or ‘output language’ would be a different 
issue: ideally, if it is specified as german,

\tempo 4 = 92.01
would be printed with 92,01 as the number. But LilyPond doesn’t have 
such a feature anyway (cf. 
…), so that need 
not be considered right now, does it?

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[David Kastrup]

Urs Liska  writes:

> Am 28. März 2017 18:41:55 MESZ schrieb David Kastrup :

>>This is not how (binary) floating point works.
>>
>>100.1 may well be 100.09997 or similar.  There is absolutely no
>>issue with letting LilyPond _accept_ non-integers.  But I don't see a
>>plan how it could or should then go about formatting them.
>>
>
> So does this point to accepting a stribg argument without implications
> to thr actual tempo?
> Of course this wouldn't be much morr than simplifying a markup entry.

Get the cat off the keyboard.  I don't know what form and meaning you
expect a stribg argument to take.

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[Urs Liska]

Am 28. März 2017 18:41:55 MESZ schrieb David Kastrup :
>Simon Albrecht  writes:
>
>> Am 28.03.2017 um 17:47 schrieb David Kastrup:
>>> Urs Liska  writes:
>>>
 As discussion onhttps://github.com/wbsoft/python-ly/pull/90  shows
 floating point metronome numbers are surely something LilyPond
>should
 provide.

 \tempo 4 = 60.0
 => error: syntax error, unexpected REAL
>>> So what do you expect to see here as the markup?  "♩ = 60.0" ?  And
>for
>>> \tempo 4 = #190/7
>>> what do you expect to see here?  "♩ = 12.9"? "♩ = 12.86"?  "♩ =
>190/7"?
>>>
>>> What for
>>> \tempo 4 = #(/ 190.0 7) ?
>>>
>>> I know how to format an integer.  But I have no way to guess what a
>>> composer will want to see for some rational or floating-point
>number.
>>>
>>> If LilyPond "should surely provide", the question is_what_  should
>it
>>> provide?
>>
>> I don’t think there is any reason to allow Scheme expressions or
>> usecase for doing so.
>
>Midi can represent certain fractions exactly and others not.  Using
>exact numbers will give the Midi representation the best shot at
>figuring out the timing relation to use.  So there is a case for
>fractions.
>
>> But in modern music it certainly occurs to have metronome marks with
>> one or two (maybe more) digits behind the point. So I’d consider it
>> sensible to additionally allow _only_ numbers in the form \tempo 4 =
>> 123.45…  (there should be no point in restricting the number of
>> ‘post-point digits’) (sorry, I’m not familiar with English
>> mathematical terminology)
>
>This is not how (binary) floating point works.
>
>100.1 may well be 100.09997 or similar.  There is absolutely no
>issue with letting LilyPond _accept_ non-integers.  But I don't see a
>plan how it could or should then go about formatting them.
>

So does this point to accepting a stribg argument without implications to thr 
actual tempo?
Of course this wouldn't be much morr than simplifying a markup entry.

Urs

>-- 
>David Kastrup
>
>___
>bug-lilypond mailing list
>bug-lilypond@gnu.org
>https://lists.gnu.org/mailman/listinfo/bug-lilypond

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[David Kastrup]

Simon Albrecht  writes:

> Am 28.03.2017 um 17:47 schrieb David Kastrup:
>> Urs Liska  writes:
>>
>>> As discussion onhttps://github.com/wbsoft/python-ly/pull/90  shows
>>> floating point metronome numbers are surely something LilyPond should
>>> provide.
>>>
>>> \tempo 4 = 60.0
>>> => error: syntax error, unexpected REAL
>> So what do you expect to see here as the markup?  "♩ = 60.0" ?  And for
>> \tempo 4 = #190/7
>> what do you expect to see here?  "♩ = 12.9"? "♩ = 12.86"?  "♩ = 190/7"?
>>
>> What for
>> \tempo 4 = #(/ 190.0 7) ?
>>
>> I know how to format an integer.  But I have no way to guess what a
>> composer will want to see for some rational or floating-point number.
>>
>> If LilyPond "should surely provide", the question is_what_  should it
>> provide?
>
> I don’t think there is any reason to allow Scheme expressions or
> usecase for doing so.

Midi can represent certain fractions exactly and others not.  Using
exact numbers will give the Midi representation the best shot at
figuring out the timing relation to use.  So there is a case for
fractions.

> But in modern music it certainly occurs to have metronome marks with
> one or two (maybe more) digits behind the point. So I’d consider it
> sensible to additionally allow _only_ numbers in the form \tempo 4 =
> 123.45…  (there should be no point in restricting the number of
> ‘post-point digits’) (sorry, I’m not familiar with English
> mathematical terminology)

This is not how (binary) floating point works.

100.1 may well be 100.09997 or similar.  There is absolutely no
issue with letting LilyPond _accept_ non-integers.  But I don't see a
plan how it could or should then go about formatting them.

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[Simon Albrecht]

Am 28.03.2017 um 17:47 schrieb David Kastrup:

Urs Liska  writes:


As discussion onhttps://github.com/wbsoft/python-ly/pull/90  shows
floating point metronome numbers are surely something LilyPond should
provide.

\tempo 4 = 60.0
=> error: syntax error, unexpected REAL

So what do you expect to see here as the markup?  "♩ = 60.0" ?  And for
\tempo 4 = #190/7
what do you expect to see here?  "♩ = 12.9"? "♩ = 12.86"?  "♩ = 190/7"?

What for
\tempo 4 = #(/ 190.0 7) ?

I know how to format an integer.  But I have no way to guess what a
composer will want to see for some rational or floating-point number.

If LilyPond "should surely provide", the question is_what_  should it
provide?


I don’t think there is any reason to allow Scheme expressions or usecase 
for doing so. But in modern music it certainly occurs to have metronome 
marks with one or two (maybe more) digits behind the point. So I’d 
consider it sensible to additionally allow _only_ numbers in the form

\tempo 4 = 123.45…
(there should be no point in restricting the number of ‘post-point 
digits’) (sorry, I’m not familiar with English mathematical terminology)


Best, Simon
___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[Phil Holmes]

"Urs Liska"  wrote in message 
news:cc89b397-6b28-9130-e263-8ad4a7a4e...@openlilylib.org...

As discussion on https://github.com/wbsoft/python-ly/pull/90 shows
floating point metronome numbers are surely something LilyPond should
provide.

\tempo 8 = 60.0
=> error: syntax error, unexpected REAL


I don't see how this is different from using accepted notation of \tempo 8 = 
60.  What would be the use case?


--
Phil Holmes 




___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond

Re: \tempo should accept floats

[David Kastrup]

Urs Liska  writes:

> As discussion on https://github.com/wbsoft/python-ly/pull/90 shows
> floating point metronome numbers are surely something LilyPond should
> provide.
>
> \tempo 4 = 60.0
> => error: syntax error, unexpected REAL

So what do you expect to see here as the markup?  "♩ = 60.0" ?  And for
\tempo 4 = #190/7
what do you expect to see here?  "♩ = 12.9"? "♩ = 12.86"?  "♩ = 190/7"?

What for
\tempo 4 = #(/ 190.0 7) ?

I know how to format an integer.  But I have no way to guess what a
composer will want to see for some rational or floating-point number.

If LilyPond "should surely provide", the question is _what_ should it
provide?  I don't see that there is a ready answer for that.

-- 
David Kastrup

___
bug-lilypond mailing list
bug-lilypond@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-lilypond