Re: [Audacity-quality] Floating point input from slider widget
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Markus M. <me...@me...> - 2010-08-27 22:18:50
|
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. 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. Markus |