Re: [Gretl-devel] some bugs and issues

Folks, FWIW, here are my 2 cents worth. And note that I've never worked with the comma as decimal separator, so feel free to discount the following at the appropriate rate. As I see it, there are 2 potential issues for decimal-comma users: 1) When using the GUI, one would like to have the interface as "local" as possible. That is, allow use of the comma for input as well as output, subject to the constraints that Allin's talked about. 2) When doing scripting, writing functions, etc., we always use the American system -- commas are never allowed as a decimal seperator. I think if I were a decimal comma user, the question I'd be asking myself would be: given that goal 2 above is fixed (and I think it should be), which of the following would be more convenient? a) using familiar methods ("local" spreadsheets, data entry, etc) with the GUI, but "American" notation otherwise, or b) biting the bullet and doing things the bloody American way. I don't know if (a) is what Allin means by a "wretched British compromise", and I'm not sure which would be less annoying to me if I were in that position. But if I were, I think this is how I'd start weighing marginal costs vs marginal benefits. PS ________________________________________ From: gretl-devel-bounces(a)lists.wfu.edu [gretl-devel-bounces(a)lists.wfu.edu] on behalf of Allin Cottrell [cottrell(a)wfu.edu] Sent: Thursday, January 26, 2012 6:34 PM To: Gretl development Subject: Re: [Gretl-devel] some bugs and issues On Thu, 26 Jan 2012, Talha Yalta wrote: This is in response to Talha (above) but also Sven and Jack. First, there are two more prohibitions on comma-substitution that would have to be added: (a) never touch commas within '{' and '}', since these denote matrix-definition and in that context ',' separates columns; and (b) never touch commas within double quotes (just in case someone is defining a string via the GUI). With those prohibitions added, I'm 99.9% (+) confident that the comma substitution that Talha would like to have will not break any correct "genr"-type expressions (i.e. those using '.' as decimal character) entered via the GUI. I've grepped hundreds of highly varied scripts on my system for ',' and the above-mentioned rules would protect all legitimate uses of the comma. Sven says, "I believe it would take a long time to iron out bugs introduced by such an approach, since I'm sure there are cases where gretl would then mis-interpret the commas." I would say, it depends on what you mean by a bug. In my view one could talk of a bug only if gretl substituted '.' for comma when the comma in the original was in fact correct. As I've said above, I'm confident this will not happen under the proposed rules. If you include as bugs instances where a comma was intended by the user as decimal separator but gretl failed to substitute '.' then, for sure, that can be expected to happen, though probably not very often. It would definitely happen, for example, if a decimal comma-preferring user typed into the GUI "genr" box y = sqrt(1,5*x) since the comma would be protected by the enclosing parentheses. I'm taking that as given. This leads to two questions: For those who favor accommodation of the decimal comma on GUI input: would you regard this as acceptable -- where "this" means that use of the decimal comma would work with simple uses of "genr" but would predictably fail on complex uses, and that sort of failure would not be considered a bug? For the rest of us: are we willing to tolerate the syntactical sloppiness implied by the above -- given that it won't actually compromise our own interaction with gretl so long as we use the decimal point? I read Jack as saying "No" to the second question, and I respect that view. It's clear and consistent. But I'm not totally ruling out a wretched British compromise until I hear some more views. Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel