On Tue, 18 Sep 2007, Sven Schreiber wrote: I take your point, but the "define a new variable" dialog is essentially just a window onto a tiny script: the parser is the same as for "genr" commands in scripts, and allowing the decimal comma here would break other valid uses of that character (e.g. as separator for function arguments). The real bug here is gretl silently truncating rather than flagging an error. But I can't replicate that. Running currrent gretl on Linux in German, if I try executing the formula you quoted, I get an error box: Das Symbol ',' ist ung\"ultig in diesem Kontext. I don't specifically recall doing anything that would have changed this behaviour since the 1.6.5 release, but I suppose I must have done -- there have been several small genr fixes. Allin.

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.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just want to say that option 2 currently in use is a good solution, and option 1 should be discarded. I am opposing discarding localized settings! As for having both output and input using locale settings my be considered as a goal in the future, and that is in my "wish list". As for the scripts with locale settings I propose using a kind of directive at the beginning of the script, so, for example: #separators=",.;" - - There is a fixed order for the separators. In the example, for Portuguese, I wrote: decimal separator, thousands separator and list separator. - - If script is generated from GUI and locale defined then the directive is written to the file. - - If the directive is absent the default is English locale. For performance sake I think that is best to parse the file and using a temporary file (possibly in RAM) with the English locale. - ---- Testing as I was writing this message, I found that in Tools/Distributions graphs the Normal label in the Gnuplot appears as N(mean, variance) when should be N(mean, standard deviation). The distributions labels are being parsed for localization, but the numbers are not (still appear with decimal point). - --- Thanks, Hélio Guilherme

Hi, Allin Cottrell schrieb: I can only speak for German habits: No, I'm afraid not. On the blackboard, some people use spacing to indicate the difference (something like N(1,5 , 25)), but of course that's no option for computers. Others have switched to decimal periods (in handwriting) for that reason even though it's not the German standard. Personally I use the semicolon as you suggest above, but my impression is that it's not too widespread. As you know, for programming one has to use decimal periods anyway for all (?) numerical languages. Apart from that, Helio's suggestions are worth considering IMO. All I want is consistency in the usage (as long as it's not too difficult and/or error-prone to implement). -sven

On Thu, 20 Sep 2007, Hélio Guilherme wrote: The problem is that the translator cannot assume that a person using gretl in his/her locale has chosen to use the locale decimal separator. But I guess we could work around that: use the "translation" if and only if the use has chosen to use the locale decimal separator?? That was my fear. I'm not sure we're better off with a (good-faith but) questionable "translation" for these strings than with the status quo. Allin.

On Wed, 19 Sep 2007, Sven Schreiber wrote: OK, I can definitely agree on that. In fact, as a first step I have tried to ensure this in current CVS and Windows snapshot. I may have missed something, but so far I've re-done * The parameter entry boxes for statistical tables, etc., and * The data-editing spreadsheet. The object is that even if you're in a decimal-comma locale and have "use locale setting for decimal point" selected, you are still able to use '.' as decimal separator in gretl numeric dialogs without error. (Besides using ',', which remains valid for the present, for purely numeric dialogs.) If anyone finds a dialog in violation of that rule, please let me know! Allin.

On Thu, 20 Sep 2007, Sven Schreiber wrote: Yes, that's a good idea. Hmm, that hadn't occurred to me. I suppose that when you choose "define a new variable" there should be an intermediate dialog: "Define using formula" versus "Enter values" (or similar). Meanwhile, there is a work-around. Use the formula, e.g., x = NA*const then right-click on x and "Edit values". Well, on second thoughts an intermediate dialog is probably not a good idea. Defining a new variable by typing values is likely to be a relatively rare choice, and an extra dialog step would just slow things down most of the time. Any clever suggestions? One possibility, if it's not too obscure: add a check-box to the define variable dialog, something like "Force the result to be a series". Then you could enter "x = NA", "x = 1" or whatever, then open the new series for editing. Allin.

Allin Cottrell schrieb: very good!

On Thu, 20 Sep 2007, Ignacio Diaz-Emparanza wrote: Yes, we never got to the bottom of that. I'll try to find out more about the issue. Allin.