Re: [Gretl-users] decimal separator bug

On Wed, 19 Sep 2007, Sven Schreiber wrote: I'll just to clarify the current situation, and our options. The main intent of the "use locale decimal separator" option is that people in locales using the decimal comma should be able to see gretl _output_ displayed that way, which seems like a legitimate desire. Things are much trickier on the input side. We debated this a while back, and reached the conclusion that we should always insist on the decimal point in gretl scripts, otherwise they would simply not be portable. There's a relevant difference here between a gretl script and, say, a spreadsheet file. A spreadsheet (Gnumeric, Excel, ODF) is a structured file written by a program, so it can handle variant decimal characters: all that's needed is that the file include a record of the decimal separator used (plus some mechanism for handling other uses of a comma). A gretl script, on the other hand, is a "free form" file typically written by the user, and not necessarily written using gretl's built-in editor. So there's no automatic way of ensuring consistency and portability, short of insisting that only '.' is acceptable as decimal character. So far: if we support printing output using ',', but insist on '.' on the input side, we already have an inconsistency of sorts -- though I'm not sure it's very damaging. A second element of inconsistency is that when the "locale decimal separator" option is turned on, we currently accept (in fact, insist on) use of the locale separator in dialog boxes that call for simple numeric input (as opposed to the "define a new variable" dialog). I agree this is potentially confusing. Here are three options: 1) Totally scrap the locale separator: all input and output uses the decimal point, with no option. [With the exception of reading and writing delimited text data files.] 2) Keep the locale separator as an option for output display, but always use the decimal point on input. (Change the dialogs that currently accept ','.) 3) Try for consistent acceptance of ',' in input dialogs. We _could_ (though I'm not recommending this) modify the "define a new variable" dialog to interpret ',' as decimal and ';' as argument separator. We'd then do a simple character substitution on the input string to turn it into canonical form. If we were to go for option 2, we could modify the relevant dialog strings and the manual to clarify the fact that decimal comma is purely a display option. One more comment: I think the most serious issue with the decimal separator is the one raised by Sven at the start of this thread, namely that gretl could silently produce incorrect output. However, this issue is fixed. So I'm not sure it's right to say the current setup is "error prone". I don't deny, though, that it's confusing! Allin.