6:08 p.m.
Hi,
basically by coincidence and after a long hunt (let's see if it's a
another bug I was really after...) I found out:
the 'omit' command will silently ignore the cutoff significance level
option if it is provided as a bundle element, like this:
<hansl>
bundle b
b.cutoff = 0.05
ols lhs const rhs1 rhs2
omit --auto=b.cutoff
</hansl>
Instead 'omit' will use the default value of 0.10 in this case.
This is with 2015d.
thanks,
sven
6:52 p.m.
On Thu, 29 Oct 2015, Sven Schreiber wrote:
Hi,
basically by coincidence and after a long hunt (let's see if it's a another
bug I was really after...) I found out:
the 'omit' command will silently ignore the cutoff significance level option
if it is provided as a bundle element, like this:
<hansl>
bundle b
b.cutoff = 0.05
ols lhs const rhs1 rhs2
omit --auto=b.cutoff
</hansl>
Instead 'omit' will use the default value of 0.10 in this case.
This should not fail silently, agreed. Now in git it fails noisily:
? omit --auto=b.cutoff
b.cutoff: invalid option argument
When a numerical argument is required for a command option, we accept
either a straight number or the name of a scalar variable, but that's
all.
Allin
7:03 p.m.
New subject: bad bug: the same with 2015e + some more
Hi, the same behavior also with matrix bb = {1,0.05}
omit --auto=bb[2]
with scalar z = 0.05
omit --auto=z works OK
This is with 2015e
Oleh
29 жовтня 2015, 20:09:55, від "Sven Schreiber" < svetosch(a)gmx.net >:
Hi,
basically by coincidence and after a long hunt (let's see if it's a
another bug I was really after...) I found out:
the 'omit' command will silently ignore the cutoff significance level
option if it is provided as a bundle element, like this:
<hansl>
bundle b
b.cutoff = 0.05
ols lhs const rhs1 rhs2
omit --auto=b.cutoff
</hansl>
Instead 'omit' will use the default value of 0.10 in this case.
This is with 2015d.
thanks,
sven
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
1:32 a.m.
On Thu, 29 Oct 2015, Allin Cottrell wrote:
On Thu, 29 Oct 2015, Sven Schreiber wrote:
> Hi,
>
> basically by coincidence and after a long hunt (let's see if it's a another
> bug I was really after...) I found out:
>
> the 'omit' command will silently ignore the cutoff significance level
> option if it is provided as a bundle element, like this:
>
> <hansl>
> bundle b
> b.cutoff = 0.05
> ols lhs const rhs1 rhs2
> omit --auto=b.cutoff
> </hansl>
>
> Instead 'omit' will use the default value of 0.10 in this case.
This should not fail silently, agreed. Now in git it fails noisily:
? omit --auto=b.cutoff
b.cutoff: invalid option argument
Well, OK, it might as well succeed since it's not that difficult to
arrange. That's now in git.
Allin
7:48 a.m.
Am 30.10.2015 um 02:32 schrieb Allin Cottrell:
On Thu, 29 Oct 2015, Allin Cottrell wrote:
> On Thu, 29 Oct 2015, Sven Schreiber wrote:
>
>>
>> <hansl>
>> bundle b
>> b.cutoff = 0.05
>> ols lhs const rhs1 rhs2
>> omit --auto=b.cutoff
>> </hansl>
>>
>> Instead 'omit' will use the default value of 0.10 in this case.
>
> This should not fail silently, agreed. Now in git it fails noisily:
>
> ? omit --auto=b.cutoff
> b.cutoff: invalid option argument
Well, OK, it might as well succeed since it's not that difficult to
arrange. That's now in git.
Hm, I'm not sure that's the best course of action. We had the issue
before that "you pay a price for the simplicity of commands". For example,
var b.lagorder series1 series2
isn't possible, either.
IMHO either bundle elements (of the right type, of course) should be
possible everywhere, or they should be banned everywhere. Of course I'd
like the "possible everywhere" option, but I can understand that it's
difficult and error-prone. So I would rather have a clearcut rule;
explicit errors are not a problem in my view. Any partial solution isn't
helpful for really mastering hansl.
thanks,
sven
3:40 p.m.
On Fri, 30 Oct 2015, Sven Schreiber wrote:
Am 30.10.2015 um 02:32 schrieb Allin Cottrell:
> On Thu, 29 Oct 2015, Allin Cottrell wrote:
>
>> On Thu, 29 Oct 2015, Sven Schreiber wrote:
>>
>>>
>>> <hansl>
>>> bundle b
>>> b.cutoff = 0.05
>>> ols lhs const rhs1 rhs2
>>> omit --auto=b.cutoff
>>> </hansl>
>>>
>>> Instead 'omit' will use the default value of 0.10 in this case.
>>
>> This should not fail silently, agreed. Now in git it fails noisily:
>>
>> ? omit --auto=b.cutoff
>> b.cutoff: invalid option argument
>
> Well, OK, it might as well succeed since it's not that difficult to
> arrange. That's now in git.
Hm, I'm not sure that's the best course of action. We had the issue before
that "you pay a price for the simplicity of commands". For example,
var b.lagorder series1 series2
isn't possible, either.
IMHO either bundle elements (of the right type, of course) should be possible
everywhere, or they should be banned everywhere. Of course I'd like the
"possible everywhere" option, but I can understand that it's difficult and
error-prone. So I would rather have a clearcut rule; explicit errors are not
a problem in my view. Any partial solution isn't helpful for really mastering
hansl.
I take your point; maybe we should back off on this until we've
considered it more carefully. Let me comment on this a but more
generally.
In general, when a gretl command calls for a scalar argument (either
"in line" or attached to an option flag) you can give that either in
numerical form or as the name of a pre-defined scalar variable. (If
there are any remaining contexts where the latter is not accepted I
would regard that as a bug.)
However, by popular demand we have extended that a bit, so in some
contexts an expression that evaluates to a scalar is accepted, for
example in the limits of iteration, as in
loop i=1..$nobs/2
One question is how far we want to go in this direction. It turns out
that it's quite easy to make that extension for option-flag arguments
(or at least seems easy, there may be cases where this causes
problems).
As regards bundle-members, I don't think it's going to be worth
treating them as a special case: they require an evaluation process
and so might as well be passed through "genr". I mean, when we come
across a string that's neither numeric nor the name of a scalar
(things that can be checked pretty quickly) we have no idea at first
whether it represents bundle.member (or bundle["member"]), or some
other expression that evaluates to a scalar, or nonsense. But we have
a parser to handle all those cases, so I think we should either use it
or not, rather than trying special means to detect stuff inside
bundles.
Allin
10:40 a.m.
Am 30.10.2015 um 16:40 schrieb Allin Cottrell:
On Fri, 30 Oct 2015, Sven Schreiber wrote:
> Hm, I'm not sure that's the best course of action. We had
the issue
> before that "you pay a price for the simplicity of commands". For
> example,
> var b.lagorder series1 series2
> isn't possible, either.
>
> IMHO either bundle elements (of the right type, of course) should be
> possible everywhere, or they should be banned everywhere.
I take your point; maybe we should back off on this until we've
considered it more carefully. Let me comment on this a but more generally.
...
One question is how far we want to go in this direction. It turns
out
that it's quite easy to make that extension for option-flag arguments
(or at least seems easy, there may be cases where this causes problems).
As regards bundle-members, I don't think it's going to be worth treating
them as a special case: they require an evaluation process
...
But we have a parser to handle all
those cases, so I think we should either use it or not, rather than
trying special means to detect stuff inside bundles.
Ok, so this now sounds a bit like "the mighty parser will come to the
rescue", so let's take the var-example a bit further:
<hansl-future>
bundle b
p = 3
list l = ser1 ser2
b.l = l
b.p = p
var b.p b.l
</hansl-future>
Is this possible to achieve without "dangerous" modifications to gretl
that in turn are likely to lead to subtle bugs in the future?
If not, then my opinion is to have the documented rule that bundle
members cannot be used as regular variable names in commands. (If there
are cases where it still works, well good luck with that, but it's not
part of the spec then.)
Given that the use of bundles is to move them around between functions,
a substitute feature might be a command to "unpack" all the bundle
members in one go into the function's namespace to avoid multiple lines
of trivial copying (like "p = b.p"). However, the problem here would be
possible name clashes with other function-scope variables. Perhaps the
bundle name could be used as a prefix to minimize this problem, "bin_p"
instead of "p" or something like that. But I guess this kind of
operation is tricky especially if the bundle is passed in pointerized form.
Anyway, coming back to the var-example above, if it is possible without
expecting other disruptions, then why not allow it.
thanks,
sven
3098
days inactive
3100
days old
6 comments
3 participants
participants (3)
-
Allin Cottrell -
oleg_komashko＠ukr.net -
Sven Schreiber