11:10 a.m.
Hi everyone:
I would like to report a few problems or issues:
1)- In the "Restrict based on criterion" window, if I use comma as
the decimal sign I get a syntax error.
2)- Why is it that many of the tests are not available when WLS (and
heteroscedasticity corrected OLS) is used? I am asking this because I
can easily obtain the same results with whighting the model manually,
in which case I can also use the White test etc.(and see H0 is
rejected).
3)- When I add observations using Data>Add observations, the forecasts
window still says "There are no observations available for forecasting
out of sample...". (after Cochrane-Orcutt, HL, PW etc.)
4)- When I import a data file with labels, gretl gives the message:
"first row label "xxx", last label "zzz" label strings can't
be
consistent dates" This is not an error message right? Because it
sounds like one. I think the "label strings can't be consistent dates"
part is unnecessary and confusing. What do you think?
5)- IMO the data menu (along with the variable menu) is really too
long. How about considering the following changes to make it look less
intimidating:
a)- Removing the refresh window item. (I don't know if it is
really needed. Besides it doesn't even look like it belongs to the
data menu.)
b)- Making a default named list called "all variables" and
removing the "select all" item. Also, could you provide a means to
delete such lists.
c)- Having a single entry for compact data and expand data
Best regards
Talha
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
12:16 a.m.
On Fri, 20 Jan 2012, Talha Yalta wrote:
I would like to report a few problems or issues:
1)- In the "Restrict based on criterion" window, if I use comma as
the decimal sign I get a syntax error.
That's expected, and will not change: when you specify a criterion
for restricting the sample "based on a criterion" you're accessing
the "genr" mechanism, and that mechanism doesn't/can't support the
decimal comma, for one thing because in that context ',' is the
separator for function arguments.
2)- Why is it that many of the tests are not available when WLS (and
heteroscedasticity corrected OLS) is used? I am asking this because I
can easily obtain the same results with whighting the model manually,
in which case I can also use the White test etc.(and see H0 is
rejected).
Maybe this should be relaxed. First, however, I'd want to be clearer
in my own mind about what is the "right" thing to do in regard to
the various residual-based tests after WLS estimation.
3)- When I add observations using Data>Add observations, the
forecasts
window still says "There are no observations available for forecasting
out of sample...". (after Cochrane-Orcutt, HL, PW etc.)
If your model includes exogenous stochastic regressors, as one would
usually expect with Cochrane-Orcutt and so on, then gretl cannot
extend these automatically, and so cannot forecast out of sample
unless you manually fill in the extra values of the relevant series.
But if the models you're talking about have only simple
deterministic terms on the right-hand side then out-of-sample
forecasting should work once you've requested that observations be
added. So if that's not working, please give details.
4)- When I import a data file with labels, gretl gives the message:
"first row label "xxx", last label "zzz" label strings can't
be
consistent dates" This is not an error message right? Because it
sounds like one. I think the "label strings can't be consistent dates"
part is unnecessary and confusing. What do you think?
No, it's not an error message as such. But in current CVS and
snapshots that message should only be printed on stderr, and not
shown to the user in a dialog box. Please let us know if that's not
the case.
5)- IMO the data menu (along with the variable menu) is really too
long. How about considering the following changes to make it look less
intimidating:
a)- Removing the refresh window item. (I don't know if it is
really needed. Besides it doesn't even look like it belongs to the
data menu.)
This item _ought_ to be redundant, since the main data window is
supposed to refresh automatically. Has anyone seen a case lately
where the automatic refresh does not occur? If not, we can probably
get rid of it.
b)- Making a default named list called "all variables"
and
removing the "select all" item. Also, could you provide a means to
delete such lists.
"Select all" is a standard GUI option which admittedly may be useful
only rarely in gretl, but which -- it seems to me -- is not
equivalent to defining a list containing all variables. On your
second point, yes, I guess deleting lists via the GUI should
probably be supported.
c)- Having a single entry for compact data and expand data
That would reduce the menu slightly, but complicate considerably the
dialog box that the menu item calls up.
Allin Cottrell
8:35 p.m.
Thanks very much Professor Cottrell for your modificaitons and
explanations. Just one thing:
> 1)- In the "Restrict based on criterion" window, if I
use comma as
> the decimal sign I get a syntax error.
That's expected, and will not change: when you specify a criterion
for restricting the sample "based on a criterion" you're accessing
the "genr" mechanism, and that mechanism doesn't/can't support the
decimal comma, for one thing because in that context ',' is the
separator for function arguments.
Would it be possible that gretl (depending on the locale setting)
automatically replaces commas with dots (and say semicolons with
commas) before sending the command to genr? I insist because this is
someting that can be important in some places and/or countries.
Sincerely
Talha
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
8:50 p.m.
On 25-01-2012, at 21:35, Talha Yalta wrote:
Thanks very much Professor Cottrell for your modificaitons and
explanations. Just one thing:
>> 1)- In the "Restrict based on criterion" window, if I use comma as
>> the decimal sign I get a syntax error.
>
> That's expected, and will not change: when you specify a criterion
> for restricting the sample "based on a criterion" you're accessing
> the "genr" mechanism, and that mechanism doesn't/can't support the
> decimal comma, for one thing because in that context ',' is the
> separator for function arguments.
Would it be possible that gretl (depending on the locale setting)
automatically replaces commas with dots (and say semicolons with
commas) before sending the command to genr? I insist because this is
someting that can be important in some places and/or countries.
I don't think that such behaviour would be a good idea.
It would mean that you can write a script with comma's in numbers which would work in
your environment.
Then you send that script to me and I work in decimal dot environment.
So what am I going to do? ....
A programming or scripting language IMHO should be locale independent. So that regardless
of the locale a script or e.g. a C source file will be processed correctly and
predictably.
I have in the past (not even all that long ago) actually encountered a commercial C
compiler offered by a reputable company that insisted on interpreting a perfectly valid C
source (decimal dot) file using a Dutch locale (comma as decimal separator).
And not even giving syntax errors and producing totally ridiculous and wrong answers. The
company initially refused to acknowledge the error but had to relent. They claimed that
repairing the error was too difficult (ha ha).
Berend
9:21 p.m.
On Wed, 25 Jan 2012, Talha Yalta wrote:
Thanks very much Professor Cottrell for your modificaitons and
explanations. Just one thing:
>> 1)- In the "Restrict based on criterion" window, if I use comma as
>> the decimal sign I get a syntax error.
>
> That's expected, and will not change: when you specify a criterion
> for restricting the sample "based on a criterion" you're accessing
> the "genr" mechanism, and that mechanism doesn't/can't support the
> decimal comma, for one thing because in that context ',' is the
> separator for function arguments.
Would it be possible that gretl (depending on the locale setting)
automatically replaces commas with dots (and say semicolons with
commas) before sending the command to genr? I insist because this is
someting that can be important in some places and/or countries.
Talha, please, how many times do we have to go over this? We found what
turned out to be an acceptable compromise years ago: dot in input,
locale-dependent separator in output.
You know very well that others have been against national decimal
separators forever, and yet have stopped complaining about them in the
name of the principle that, once a compromise has been agreed on, then
that's it.
I don't mean to be confrontational here, but just to put this in context:
try to make the same request on the Stata or on the R mailing lists. I
suspect you'd be treated like an alien from outer space.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
7:20 a.m.
Thanks Brend, Jack. I understand and agree with what you are saying.
Jut to be a bit clearer, I am not talking about scripts and not
everyone is a script-writer. I was merely talking about casual command
entering using the GUI.
In the plot controls, if I add a line and enter, say, "2,5 + 2,5*x"
gretl automatically converts the commas and draws the line correctly.
Gretl also supports writing and reading different csv files as well as
different date formats. I don't think these are so bad and even excel
is known to handle such things correctly.
No need to be confrontational. We are all brainstorming on how to make
gretl better and greater. I don't have any benefit whatsoever except
being able to say to the students "OK, gretl genuinely supports
different systems and does things in a consistent manner."
At any rate, based on the above example, my initial post was a
perfectly valid bug report.
Cheers
Talha
On Wed, Jan 25, 2012 at 11:21 PM, Riccardo (Jack) Lucchetti
<r.lucchetti(a)univpm.it> wrote:
On Wed, 25 Jan 2012, Talha Yalta wrote:
> Thanks very much Professor Cottrell for your modificaitons and
> explanations. Just one thing:
>
>
>>> 1)- In the "Restrict based on criterion" window, if I use comma
as
>>> the decimal sign I get a syntax error.
>>
>>
>> That's expected, and will not change: when you specify a criterion
>> for restricting the sample "based on a criterion" you're accessing
>> the "genr" mechanism, and that mechanism doesn't/can't support
the
>> decimal comma, for one thing because in that context ',' is the
>> separator for function arguments.
>
>
> Would it be possible that gretl (depending on the locale setting)
> automatically replaces commas with dots (and say semicolons with
> commas) before sending the command to genr? I insist because this is
> someting that can be important in some places and/or countries.
Talha, please, how many times do we have to go over this? We found what
turned out to be an acceptable compromise years ago: dot in input,
locale-dependent separator in output.
You know very well that others have been against national decimal separators
forever, and yet have stopped complaining about them in the name of the
principle that, once a compromise has been agreed on, then that's it.
I don't mean to be confrontational here, but just to put this in context:
try to make the same request on the Stata or on the R mailing lists. I
suspect you'd be treated like an alien from outer space.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
4:55 p.m.
On Thu, 26 Jan 2012, Talha Yalta wrote:
In the plot controls, if I add a line and enter, say, "2,5 +
2,5*x"
gretl automatically converts the commas and draws the line correctly.
It's true that in some GUI contexts (contexts that do not have
a script counterpart) we attempt to recognize the decimal
comma on input, in locales where this applies. It's also true
that this introduces a degree of inconsistency, since, as you
say, the decimal comma is never accepted in a "genr" dialog.
The rigorous way to fix the inconsistency would be to insist
on '.' as the decimal character in _all_ input contexts.
Perhaps we should consider that option.
You suggest that gretl might automatically fix up the decimal
comma in GUI "genr" contexts (meaning that the actual string
passed to genr, and recorded in the command log, would use the
decimal point). That could be done, but only at a basic
heuristic level.
The comma is the argument separator for functions, and also
the row/column separator in matrix-range specifications. To
make sure we don't break user input that's already correct,
we'd have to do something like this:
* Never touch commas that appear between '(' and ')', or
between '[' and ']', in case we're in a function call or a
matrix range.
* Otherwise substitute '.' for ',' if the comma is followed by
a digit.
This to be confined to GUI dialog input (we'd never mess with
scripts or console input) and the case where the output
decimal separator is the comma. I'm not recommending this,
just seeing what people think.
Allin
8:54 p.m.
Am 26.01.2012 17:55, schrieb Allin Cottrell:
On Thu, 26 Jan 2012, Talha Yalta wrote:
> In the plot controls, if I add a line and enter, say, "2,5 + 2,5*x"
> gretl automatically converts the commas and draws the line correctly.
It's true that in some GUI contexts (contexts that do not have
a script counterpart) we attempt to recognize the decimal
comma on input, in locales where this applies. It's also true
that this introduces a degree of inconsistency, since, as you
say, the decimal comma is never accepted in a "genr" dialog.
The rigorous way to fix the inconsistency would be to insist
on '.' as the decimal character in _all_ input contexts.
Perhaps we should consider that option.
Yes, perhaps.
You suggest that gretl might automatically fix up the decimal
comma in GUI "genr" contexts (meaning that the actual string
passed to genr, and recorded in the command log, would use the
decimal point). That could be done, but only at a basic
heuristic level.
The comma is the argument separator for functions, and also
the row/column separator in matrix-range specifications. To
make sure we don't break user input that's already correct,
we'd have to do something like this:
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 note that spreadsheet programs that have always (?) had
locale-dependent decimal separators therefore don't use the comma as an
argument separator. Instead they seem to use the semicolon. *IF* gretl
allowed commas as decimal separators for input (and I'm not saying it
should) I would be in favor of a policy that then also requires the use
of semicolons for argument separations (etc.) so as to avoid any
ambiguities.
Clarification: This should only apply to somebody who chooses a new
tickbox option "allow comma decimal separator for GUI command input",
not for the rest of us who could merrily continue the current status
quo. But again, this is very hypothetical, I'm only stating this as a
suggested damage-prevention way of things, not as my wish.
thanks,
sven
9:05 p.m.
we'd have to do something like this:
* Never touch commas that appear between '(' and ')', or
between '[' and ']', in case we're in a function call or a
matrix range.
* Otherwise substitute '.' for ',' if the comma is followed by
a digit.
This to be confined to GUI dialog input (we'd never mess with
scripts or console input) and the case where the output
decimal separator is the comma. I'm not recommending this,
just seeing what people think.
The above sounds very nice to me. Please do remember
that many new
users prefer gretl for its GUI. Also, most of these people are
accustomed to using Excel and entering commands via GUI a-la-Excel
(and using commas in doing so depending on where they live).
Finally, I am considered geekier than most people (OK maybe not most
people in this list) but I do love GUIs.
Cheers
Talha
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
9:20 p.m.
On Thu, 26 Jan 2012, Allin Cottrell wrote:
The rigorous way to fix the inconsistency would be to insist
on '.' as the decimal character in _all_ input contexts.
Perhaps we should consider that option.
My vote goes to this one.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
11:26 p.m.
Em 26 de janeiro de 2012 Jack escreveu:
On Thu, 26 Jan 2012, Allin Cottrell wrote:
The rigorous way to fix the inconsistency would be to insist
> on '.' as the decimal character in _all_ input contexts.
> Perhaps we should consider that option.
>
My vote goes to this one.
Dear Gretl Team,
I have a suggestion that, in my humble opinion, could at least partially
help to finish this issue: What do you think about the inclusion of warning
messages in the GUI context when the user tries to use commas instead of
dots?
I really don't know if this is possible from the programming point of view,
but if this is a not so code intensive task, I think we could give it a try.
Um abraço,
Henrique Andrade
11:34 p.m.
On Thu, 26 Jan 2012, Talha Yalta wrote:
> we'd have to do something like this:
>
> * Never touch commas that appear between '(' and ')', or
> between '[' and ']', in case we're in a function call or a
> matrix range.
>
> * Otherwise substitute '.' for ',' if the comma is followed by
> a digit.
>
> This to be confined to GUI dialog input (we'd never mess with
> scripts or console input) and the case where the output
> decimal separator is the comma. I'm not recommending this,
> just seeing what people think.
The above sounds very nice to me. [...]
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
12:23 a.m.
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:
> we'd have to do something like this:
>
> * Never touch commas that appear between '(' and ')', or
> between '[' and ']', in case we're in a function call or a
> matrix range.
>
> * Otherwise substitute '.' for ',' if the comma is followed by
> a digit.
>
> This to be confined to GUI dialog input (we'd never mess with
> scripts or console input) and the case where the output
> decimal separator is the comma. I'm not recommending this,
> just seeing what people think.
The above sounds very nice to me. [...]
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
1:32 a.m.
On Fri, 27 Jan 2012, Summers, Peter wrote:
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.
Your point (hah) is well taken: anyone aspiring to be a power-user
of gretl will have to get used to the decimal point sooner or later,
the only question is exactly when.
But I'd note that the decimal point is not just an American thing:
it's used in all English-speaking countries (that I know of) plus
China, Korea, Israel, India and Pakistan, etc., etc., i.e. a good
majority of the world's population.
Allin
2:16 a.m.
Since I am one in favor of localization in the most extent possible,
here is my contribute (not the first time, we talk about this).
Leaving the GUI aside (considering that solved), I think that we could
have a directive (or environmental variable setting) that a script
author would add in the script. The omission of that setting would go
for EN (as it is now).
But to guarantee that the setting defined by the script's author is
kept in the script, the setting would be explicit. For example, jut to
see the idea:
#define decimal_dot_thousands_comma
#define decimal_comma_thousands_dot
set number_style(',' , '.')
---
I also say that this setting is independent from the position in the
script where it's invoked. This allows to use it in the command line,
meaning that all numbers processed from that point, would use the
defined form.
We can expect some performance degradation if the user decides to have
all input to be processed before being used in calculations when
having a setting other than default.
---
If a solution of this kind is implemented, I would not mind to
"translate" the example scripts. I can also make a utility program to
translate those numbers styles inside scripts.
Helio Guilherme
2:27 a.m.
Em 27 de janeiro de 2012 Hélio escreveu:
Since I am one in favor of localization in the most extent possible,
here is my contribute (not the first time, we talk about this).
I strongly agree with Hélio.
Leaving the GUI aside (considering that solved), I think that we
could
have a directive (or environmental variable setting) that a script
author would add in the script. The omission of that setting would go
for EN (as it is now).
But to guarantee that the setting defined by the script's author is
kept in the script, the setting would be explicit. For example, jut to
see the idea:
#define decimal_dot_thousands_comma
#define decimal_comma_thousands_dot
set number_style(',' , '.') (...)
Great ideia :-)
Um abraço,
Henrique Andrade*
*
2:52 a.m.
On Thu, 26 Jan 2012, Henrique Andrade wrote:
Em 26 de janeiro de 2012 Jack escreveu:
On Thu, 26 Jan 2012, Allin Cottrell wrote:
>
> The rigorous way to fix the inconsistency would be to insist
>> on '.' as the decimal character in _all_ input contexts.
>> Perhaps we should consider that option.
>
> My vote goes to this one.
I have a suggestion that, in my humble opinion, could at least partially
help to finish this issue: What do you think about the inclusion of warning
messages in the GUI context when the user tries to use commas instead of
dots?
I think that's a good idea. If we can isolate the specific error
when "genr" comes across an unexpected comma and print a suitable
informative message, instead of just "syntax error", that would help
matters.
Allin
3:16 a.m.
On Fri, 27 Jan 2012, Hélio Guilherme wrote:
Leaving the GUI aside (considering that solved), I think that we
could
have a directive (or environmental variable setting) that a script
author would add in the script. The omission of that setting would go
for EN (as it is now).
Thanks, Hélio, but here I totally agree with Jack. We can't
"balkanize" gretl scripting. The decimal character in gretl scripts
is '.', period. Don't think of this as "EN", just think of it as
what's used in serious computing.
There's nothing stopping anyone from writing a converter that takes
as input a localized script using the decimal comma (and that
therefore uses some other character such as ';' for
function-argument separation, and yet another character where gretl
syntax already specifies ';') and writes out a standard gretl
script.
Jack and I don't think that would be a good idea, and we're not
going to do it, but it's an option that's open to anyone who thinks
otherwise.
Allin
7:52 a.m.
On Thu, 26 Jan 2012, Allin Cottrell wrote:
I read Jack as saying "No" to the second question,
You're a good reader :)
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.
I'm not against it per se. After all, compromise is an art which I hold in
high esteem (being exceptionally bad at it). I'd just like to point out
that this decision would (philopsophically) mark a point when Hansl and
Gretl started diverging from one another. This may not be a bad thing in
itself, Hansl being more oriented to power users and Gretl to casual
users. The only thing, in time we may have several "favour/favor",
"centre/center" etc. situations. Are we ok with this?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
10:30 a.m.
On 27-01-2012, at 00:34, Allin Cottrell wrote:
On Thu, 26 Jan 2012, Talha Yalta wrote:
>> we'd have to do something like this:
>>
>> * Never touch commas that appear between '(' and ')', or
>> between '[' and ']', in case we're in a function call or a
>> matrix range.
>>
>> * Otherwise substitute '.' for ',' if the comma is followed by
>> a digit.
>>
>> This to be confined to GUI dialog input (we'd never mess with
>> scripts or console input) and the case where the output
>> decimal separator is the comma. I'm not recommending this,
>> just seeing what people think.
> The above sounds very nice to me. [...]
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.
Also looks like a typical "wretched" Dutch political compromise.
I agree with Jack. No syntactical sloppiness, please.
As far as I am concerned, the only place where I would be prepared to accept a locale
dependent decimal point character in GUI input is where a user can input pure numbers
only. Nowhere else.
Berend
11:33 a.m.
But I'd note that the decimal point is not just an American thing:
it's used in all English-speaking countries (that I know of) plus
China, Korea, Israel, India and Pakistan, etc., etc., i.e. a good
majority of the world's population.
Allin
Hello friends,
let me add some more information, from the point of view of a user of a
decimal-comma country.
Firstly, we have not to decide which is better if the decimal point or
the decimal comma. There is an international agency, the International
Committee for Weights and Measures, who already took a decision about
that: both are valid (http://www.bipm.org/en/CGPM/db/22/10/ ). Wikipedia
has an interesting map of the use of ech of them
(http://en.wikipedia.org/wiki/Decimal_mark ).
But I suppose that Allin's affirmation is correct, a good majority of
the world's population uses the decimal point (or at least in our field
I am sure that is correct). For the scripting language is reasonable to
restrict the use only to a unique decimal symbol, so the logic election
is the decimal point. But I am in favour of letting the people to use
the comma in the GUI, if this is not very difficult to program. When a
new user knows gretl, the first impression he has is trough the GUI, and
in these initial steps we should make things as easy as possible for him.
--
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.ea3.ehu.es
12:16 p.m.
Am 27.01.2012 11:30, schrieb Berend Hasselman:
On 27-01-2012, at 00:34, Allin Cottrell wrote:
>
> 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?
From the point of view of the pro-locale users, would such a
inconsistent gretl behavior really help them? I tend to think no,
because they would have to learn *more* (exceptions).
[Also I note, a pair of parentheses not only means a function call, but
can also simply indicate precedence; is 'genr hello=(2,5+my)*4,5'
already a complex statement? If I understand correctly, it would fail
even under the proposed rules. -- Allin: Yes, this is what I meant by 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?
Yes I could accept it, but I have my doubts that it really won't interfere.
More generally once more: Gretl (Allin) implicitly made the design
decision long ago, by choosing the comma as a different separator (for
arguments etc.). It doesn't make sense to overload the comma character's
meaning. If the comma were to be allowed as decimal mark, in principle
gretl would need a new argument separator, e.g. the semicolon.
As far as I am concerned, the only place where I would be prepared
to
accept a locale dependent decimal point character in GUI input is
where a user can input pure numbers only. Nowhere else.
Berend
In principle I can agree here, but as argued above, does this really
help the affected users? Are "pure numbers" inputs the common need of
gretl users, also given that gretl has deliberately outsourced most data
editing to specialized (text editor and spreadsheet) programs?
cheers,
sven
3:04 p.m.
On Fri, 27 Jan 2012, Berend Hasselman wrote:
I agree with Jack. No syntactical sloppiness, please.
As far as I am concerned, the only place where I would be
prepared to accept a locale dependent decimal point
character in GUI input is where a user can input pure
numbers only. Nowhere else.
I find myself in agreement with this. There are various places
in the gretl GUI where a dialog box (or similar) wants a plain
number, and for a long time we have accommodated numbers
entered using either '.' or (in the relevant locales) the
decimal comma. I don't propose to change this at present.
On the other hand, for the "genr" dialog (and the sample
restriction dialog, which invokes genr) I'm agree that we'd
not really be doing users a favor by providing a half-baked
"fix-up" mechanism for decimal commas.
What I've added in current CVS and snapshots is smarter
error-handling. So if you're using the decimal comma for
output in the gretl GUI, and you enter a "genr"-type formula
that has a syntax error in the form of a misplaced comma, you
should see not just "syntax error", but a new, specific
translatable message:
"Please note: the decimal character must be '.'\n"
"in this context"
That leaves the matter of the "plot a curve" dialog, where
we've historically been doing fix-up for the decimal comma.
There's a case for putting this in line with "genr", but I'm
not going to make a backward incompatible change right now.
Allin
3:23 p.m.
On 27-01-2012, at 16:04, Allin Cottrell wrote:
What I've added in current CVS and snapshots is smarter
error-handling. So if you're using the decimal comma for
output in the gretl GUI, and you enter a "genr"-type formula
that has a syntax error in the form of a misplaced comma, you
should see not just "syntax error", but a new, specific
translatable message:
"Please note: the decimal character must be '.'\n"
"in this context"
Excellent idea.
Berend
7:53 p.m.
I find this final solution to be rather disappointing (although it is
better than a bug). I also consider it discouraging for translators
putting considerable effort localizing gretl. But maybe that is also
unnecessary. Maybe everyone should learn English to do econometrics
:-P
I was away for the last few days and I am surprised how the discussion
evolved from Helio's excellent proposal to the final "solution". Good
thing many fine open-source projects such as LaTeX don't solve this
particular type of problem the easy way.
Regards
Talha
On Fri, Jan 27, 2012 at 5:04 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Fri, 27 Jan 2012, Berend Hasselman wrote:
> I agree with Jack. No syntactical sloppiness, please.
>
> As far as I am concerned, the only place where I would be
> prepared to accept a locale dependent decimal point
> character in GUI input is where a user can input pure
> numbers only. Nowhere else.
I find myself in agreement with this. There are various places
in the gretl GUI where a dialog box (or similar) wants a plain
number, and for a long time we have accommodated numbers
entered using either '.' or (in the relevant locales) the
decimal comma. I don't propose to change this at present.
On the other hand, for the "genr" dialog (and the sample
restriction dialog, which invokes genr) I'm agree that we'd
not really be doing users a favor by providing a half-baked
"fix-up" mechanism for decimal commas.
What I've added in current CVS and snapshots is smarter
error-handling. So if you're using the decimal comma for
output in the gretl GUI, and you enter a "genr"-type formula
that has a syntax error in the form of a misplaced comma, you
should see not just "syntax error", but a new, specific
translatable message:
"Please note: the decimal character must be '.'\n"
"in this context"
That leaves the matter of the "plot a curve" dialog, where
we've historically been doing fix-up for the decimal comma.
There's a case for putting this in line with "genr", but I'm
not going to make a backward incompatible change right now.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
10:53 p.m.
On Sun, 29 Jan 2012, Talha Yalta wrote:
I find this final solution to be rather disappointing (although it
is
better than a bug). I also consider it discouraging for translators
putting considerable effort localizing gretl. But maybe that is also
unnecessary. Maybe everyone should learn English to do econometrics
:-P
Beyond a certain point it is indeed necessary to learn English to do
econometrics, since that's the language in which the great majority
of original papers on the subject are published. But you can get a
good understanding of econometrics at the undergraduate level
without knowing English, and I think the gretl translators have done
a great job in making that easier.
Regardless of one's native language, however, one thing it's
necessary to learn, to be a competent econometrician, is
"programming" in a broad sense (including scripting, not just
low-level computer languages, which not everyone has to learn). And
in relation to programming, the newbie econometrician has to learn
that the decimal comma is simply not acceptable -- for technical
reasons, not chauvinistic ones -- even if it's the preferred form
for printed material in one's native country.
Allin
12:40 a.m.
I understand most of the discussions for using dot as the decimal
separator but I cannot understand why it is not posible to allow
people enter one-line commands at the GUI (with a simple translation
layer) without avoiding some sort of a millenium bug where all scripts
will suddenly stop working and the hell will break loose. (Maybe we
should have this discussion after 2012 passes?)
At any rate, as a small protest, I decided not to translate the string
"Please note: the decimal character must be '.'\n in this context"
Instead, maybe I can help with updating the manual :-)
Gretl proudly adheres to the Anglo-American tradition of using dots as
the decimal separator. To support this view, it first seemed like a
good idea to point out that the majority of World's population uses
dots. Quickly realizing that the Chinese can one day switch to commas,
we decided to go with the fact that programming languages such as
Fortran, C, C++ and Java... also use dots. Of course, there are two
or three billion people who know nothing about these languages but can
still use computers and somehow do arithmetics even, however, that
surely is an exception. Our firm stand on this topic should teach
those comma-huggers how to write error free scripts if they aspire to
computer literacy. Finally, we realize that today computer literacy
also requires knowing Microsoft products, so in the future we will do
our best to do things the Microsoft way as well.
The Gretl Team
(From eco////////////////////////////////
(You are either with us or against us)
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
1:35 a.m.
Hi,
We do not need to go this far on this:
Instead, maybe I can help with updating the manual :-)
Gretl proudly adheres to the Anglo-American tradition of using dots as
the decimal separator. To support this view, it first seemed like a
good idea to point out that the majority of World's population uses
dots. Quickly realizing that the Chinese can one day switch to commas,
we decided to go with the fact that programming languages such as
Fortran, C, C++ and Java... also use dots. Of course, there are two
or three billion people who know nothing about these languages but can
still use computers and somehow do arithmetics even, however, that
surely is an exception. Our firm stand on this topic should teach
those comma-huggers how to write error free scripts if they aspire to
computer literacy. Finally, we realize that today computer literacy
also requires knowing Microsoft products, so in the future we will do
our best to do things the Microsoft way as well.
The Gretl Team
(From eco////////////////////////////////
(You are either with us or against us)
This unnecessary!
Let's just accept that Allin and Jack had done a marvelous piece of
software and algorithms, and they implement the use of decimal point
in the command line and scripts. That's it!
We I have the time I will do some code to prevent user errors
(entering decimal comma numbers) at command line input (and validation
of scripts).
Let us focus on more important things.
Hélio
11:09 a.m.
On Sun, 29 Jan 2012, Talha Yalta wrote:
I find this final solution to be rather disappointing (although it
is
better than a bug). I also consider it discouraging for translators
putting considerable effort localizing gretl. But maybe that is also
unnecessary. Maybe everyone should learn English to do econometrics
:-P
Talha, I have the feeling that perhaps you're over-ideologizing this
issue. Let me explain. I may be wrong, but to my ears you sound like
someone (the little good guy) who thinks he's fighting a survival battle
against Anglo-Saxon cultural imperialism (the big bad guy).
It's not that way. There are historical reasons why English has become the
world's vehicle language, like Latin used to be in medieval Europe and
Swahili has been for several centuries in South-East Africa. You say
"Maybe everyone should learn English to do econometrics" with what sounds
to me like an obvious rhetorical intent. Well, in my view the above
assertion is (as Allin pointed out) true to a very large extent: you don't
_need_ to be a fluent English speaker to run a regression, obviously. But
on the other hand, econometrics is not basic arithmetic; it is a subject
that, as far as I know, is not taught outside of universities. If this is
the case, I would find it bizarre if someone with a university-level
education from any country in the world was unable to understand (let
alone speak) the _lingua franca_ of the 21st century. If a university
system allows their students to obtain a degree without a basic knowlegde
of THE vehicular language any cultured person expects to use with
foreigners, then something is very wrong (and this may well happen in MY
country, so I know what I'm talking about).
And finally, let me mention something else I profoundly believe in: the
formative power of being exposed to foreign languages. Having a decent
command of a language other than the one you learned as a child is very,
very, very good for your brain at a very general level. I pity those poor
English mother-tongue speakers who lack the incentive the rest of the
world has to open their minds in such a beautiful way.
Sorry for the rant :-)
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
8:28 p.m.
Hello,
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
semicolon.
* 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.)
thanks,
sven
9:33 p.m.
On Wed, 1 Feb 2012, Sven Schreiber wrote:
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.
Granted.
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
semicolon.
* 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.)
A couple of comments on this.
First, I wonder how many users want to see the decimal comma
on output, but would prefer to keep the input in a "genr" box
consistent with hansl?
Second, there's another character that would need fixing,
namely the ';' that is used for terminating a matrix row, as
in
m = {1.1, 2.2 ; 3.3, 4.4}
I suppose this would have to become something like
m = {1,1; 2,2 X 3,3; 4,4}
but what's the 'X'? I guess ':' would be an obvious choice,
but it means things already.
Allin
11:15 p.m.
On 02/01/2012 10:33 PM, Allin Cottrell wrote:
On Wed, 1 Feb 2012, Sven Schreiber wrote:
>
> 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.)
A couple of comments on this.
First, I wonder how many users want to see the decimal comma
on output, but would prefer to keep the input in a "genr" box
consistent with hansl?
can only speculate, but why should anybody really want that?
Second, there's another character that would need fixing,
namely the ';' that is used for terminating a matrix row, as
in
m = {1.1, 2.2 ; 3.3, 4.4}
Sigh -- ok, so instead of changing this it would mean to choose some
other character for function argument separation. Not much sensible
stuff is left if it should be a single ASCII char: %@_ ? Of course this
doesn't look at all readable...
-sven
1:29 a.m.
> Second, there's another character that would need fixing,
> namely the ';' that is used for terminating a matrix row, as
> in
>
> m = {1.1, 2.2 ; 3.3, 4.4}
Sigh -- ok, so instead of changing this it would mean to choose some
other character for function argument separation. Not much sensible
stuff is left if it should be a single ASCII char: %@_ ? Of course this
doesn't look at all readable...
I vote for having the standard as is now. In scripts and command line,
always use decimal dot, commas for lists, and semi-columns for ending
matrices rows (and column for whatever).
My proposal goes for an intelligent parser at input time (keyboard),
that would change to a decimal dot if typed for a first time after a
digit, and remain as a list separator if second use. No need for other
translations, I think.
(I really don't have time for making code now, but I will keep this in
my To Do list)
Hélio
6:47 a.m.
> First, I wonder how many users want to see the decimal comma
> on output, but would prefer to keep the input in a "genr" box
> consistent with hansl?
can only speculate, but why should anybody really want that?
I agree.
I would be perfectly happy with something simple such as what we have
for adding lines using GUI. The whole thing is about helping (and not
annoying) newcomers and casual users. More than 80 percent of the
econometrics students will not become econometricians (some of them
will not even become economists). Also there are applied people in the
government who need to do things a bit more complex than with Excel
but do not ever want to write scripts (all they want is to finish
things and get out at 6pm). Why should we ask these people to "bite
the bullet" especially when many other things in gretl are so newcomer
friendly?
Regards
Talha
--
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
--
4464
days inactive
4477
days old
33 comments
9 participants
participants (9)
-
Allin Cottrell -
Berend Hasselman -
Henrique Andrade -
Hélio Guilherme -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Summers, Peter -
Sven Schreiber -
Talha Yalta