[Gretl-devel] some bugs and issues

Sven Schreiber svetosch at gmx.net
Wed Feb 1 15:28:42 EST 2012


I agree mostly with Jack. After all, hansl is also a _language_ and as
such has its syntax rules, wherever they came from.

However, Talha's GUI-argument does have some validity IMHO, given that
gretl tries to be localized (a unique and noteworthy endeavour in the
realm of statistics software as I said before). I'm feeling uneasy about
the fact that now in some places in the localized GUI you can enter
"2,5", whereas in other cases you cannot do that (as discussed in this
thread). This causes potential confusion or frustration.

So let me have another go at a suggestion for the GUI inputs (including
function calls, not just pure numbers). The proposal goes as follows:

* Starting point (sic! -- and which I said before): allowing double
meanings for commas in a single expression is out of the question IMHO.
So that means that somebody who uses commas as decimal separators *must*
use something else as function argument separator. I suggest(ed) the

* Needless to say (?), all this does not apply to hansl scripts.

* First solution: Gretl already has a preference option for choosing the
localized decimal separator. (Personally I prefer to work with the '.'
for example.) If that preference is set to localized, it seems logical
to actually _require_ the input in GUI windows in this localized form.
For example under the German (de_DE) locale: "2,5*corr(ser1;ser2)" Note
the semicolon (see above)!

* Extended solution "1b": Gretl could try to be clever and apply a
conversion according to the following algorithm, which tries to maintain
the current behavior where hansl-style input is always allowed:

- Are both a semicolon and a dot present? raise an error
- Is a semicolon present? Then treat it as localized and internally
convert the local decimal separator to dot, and semicolon to comma.
- Is a dot present (irrespective of the presence of a comma)? Then
assume hansl (C-style) rules and do not convert.
- Is only a comma present (and no dot or semicolon)? If the comma is not
inside parentheses, must be a decimal separator, treat everything as
localized. If the comma is inside parentheses, it gets more difficult
and nasty...

But again, given the existing GUI preference option for choosing the
style of the decimal separator, I think there is a strong case for
requiring this chosen style in the GUI, which resolves all ambiguities.
(At the cost of introducing a new character for function argument
separation in the GUI, which would have to be suitably documented.)


More information about the Gretl-devel mailing list