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.

Allin Cottrell schrieb: Since it's user-configurable, I agree this is not a real issue. The "insist on" part is problematic. IMHO gretl must always accept decimal periods ('.') everywhere irrespective of other settings, simply because it's already mandatory in scripts (for good reasons). Otherwise it's confusing, and such behavior might even deter people (students, for example) from writing scripts, which would be a pity. I don't care much whether or not it's also possible to use some other separator (if the locale option is activated), provided it doesn't require a syntax change for other things. So I'm more or less indifferent between 1) and 2). What I meant was that trying to accommodate different locales made this particular bug possible, and possibly would make similar bugs more likely in the future. Thanks for the "open ears", sven

On Thu, 20 Sep 2007, Hélio Guilherme wrote: "list separator": is that what you expect to use for function arguments? For example, let a function expect two floating-point arguments. In the "C" locale one might write x = f(3.21,4.56) When the decimal comma is used, would x = f(3,21;4,56) be the standard form? I'll think about your other suggestions along this line. Hmm, I think that's debatable. I believe the standard form is X ~ N(\mu, \sigma^2). However, for the purpose of data-entry, I think it's more intuitive to put the standard deviation in the second slot (as at present). Other thoughts? True. That's largely because I don't know how to write, e.g. X ~ N(1.5, 25) in a comma-using locale. As in my question above, is it X ~ N(1,5; 25) or what? Is there a definite standard? Allin.

On Wednesday 19 September 2007 15:26:36 Allin Cottrell wrote: I also vote for option 2). The user may always activate option 1) unselecting the "use locale settings for decimal point" option in the preferences. (I should warn that in my PC, that uses Kubuntu Linux with UTF-8 encoding, and gretl in Spanish, the "use locale settings ..." does not work. In collaboration with Allin I tryied several changes in my gretl configuration but we could not resolve the problem. So I have this option disabled in my gretl preferences) -- Ignacio Diaz-Emparanza DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA) UPV/EHU Avda. Lehendakari Aguirre, 83 | 48015 BILBAO T.: +34 946013732 | F.: +34 946013754 www.et.bs.ehu.es

Allin Cottrell schrieb: Ok thanks, a quick test works ok for me. For locale-using users, I would suggest to make the error message of the define-new-variable dialog more informative: For example: "The symbol ',' is invalid in this context; if you used it as a decimal separator, you must use '.' for this dialog (sorry for the inconvenience)". An unrelated minor issue: Isn't it strange that to create a new variable (by manually entering values, not via formula) one has to 1) select an (arbitrary) existing variable, 2) click edit values 3) choose add new variable in the dialog window? I.e., why isn't (3) possible from the main menus? Or am I missing something? thanks, sven

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.

On Thu, 20 Sep 2007, Sven Schreiber wrote: Ah, how about this? At present the text in the new variable dialog says "Enter formula for new variable". It could say "Enter formula for new variable (or just a name if you want to enter the values manually)". Then if we find just a name in that dialog, we pop open the data editor. Allin.

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.