Re: [Audacity-nyquist] [Audacity-quality] Floating point input from slider widget

[Vaughan J. <va...@au...>]

On 8/27/2010 3:18 PM, Markus Meyer wrote:
> Am 27.08.2010 20:56, schrieb Vaughan Johnson:
>> They don't choke, it's just that a variable's type is determined at
>> runtime.
>>    
> Okay, I understand that now.
> 
> Actually, I think the history of the bug was like this:
> 
> First, all floating point numbers in the GUI had trailing ".0"s.
> Second, the Nyquist code was consolidated (probably by me) to use
> Internat::ToString(), but still worked, because of the above property of
> floating point numbers in the GUI.
> Third, Internat::ToString() (or Internat::ToDisplayString()) was changed
> because someone (probably me, too) decided that the trailing ".0" should
> be removed. Now giving numbers to Nyquist was accidentially broken.
> 
> So I'm probably the one that introduced the bug.

I'm not sure of the sequence, but the comment says it previously used %f
and was changed to Internat::ToString() so it always has '.' no matter
the locale.

Anyway, no big deal. You were fixing Nyquist's requirement of '.' at the
time.


> 
> But why would this happen? It happened, because Nyquist.cpp used
> Internat::ToString() that (accidentially) fulfilled the contract
> expected by Nyquist (that floating point numbers must have trailing
> ".0") but this contract was just a side effect and never documented.
> Actually, Nyquist.cpp should have never used Internat::ToString() if it
> depends on an undocumented property of a former implementation of
> Internat::ToString()!
> 
> Anyway, my original point was that the value given to Nyquist should not
> depend on the value shown in the GUI anyway. Even when we show "3" in
> the GUI (and I admit that it may be more consistent to show "3.0" resp.
> "3,0" instead), the value given to Nyquist should be "3.0" if the
> Nyquist plugins requests a FLONUM. This is especially important for
> editable text fields (we cannot be sure the user always enters the
> trailing ".0"). This (and the analysis above) means that I would prefer
> to have a separate function, say, "ToNyquistNumber()" that always keeps
> (or even adds, for that matter) the trailing ".0" and clearly documents
> why it's doing this. I'm saying "adds" because I'm not sure all
> implementations of C's "sprintf" on all platforms always generate the
> trailing ".0" by itself if they don't need to. Then we would have
> "ToNyquistNumber()" to convert numbers given to Nyquist and
> "Internat::ToDisplayString()" for numbers shown in the GUI. Even if
> their implementation is 100% identical it still makes sense to keep both
> functions because the representation of numbers in the GUI may change
> (e.g. depending on the locale or a user setting or the preference of a
> future developer) but the representation of numbers sent to Nyquist must
> not.
> 

All true. But I think the change to not strip all trailing zeroes and
the decimal separator is better for the GUI, and fixes this issue, too.
And it's quicker to do, so I can get on to P2's rather than spending
much more time on this. :-)

Thanks!

- Vaughan