8:39 p.m.
Hi,
I've noticed some things which may be quirks in relation to the 'mle' block.
- If I wrongly insert several "params" lines I get a weird data error
instead of a syntax error, so it took me a while to realize my mistake.
Could that be made clearer?
- In the guide in Listings 26.1 and 26.2 and throughout other places in
ch. 26 the "genr" keyword is used. I think we want to replace that with
series/scalar etc. - In that context there the rationale for using it is
not quite clear to me, since it is surrounded by the cleaner use of
series/scalar... Anything I'm missing?
- I've been struggling without success to tell the mle command what the
parameters should be called. The background being that I need to specify
a single composite vector to accommodate several specifications. In the
guide (ch.26) I saw a similar problem, and there the workaround was to
silence mle and instead semi-manually invoke the modprint apparatus. But
wouldn't it be more efficient if simply the wanted names could be
injected, replacing the generic stuff that is in the $parnames accessor?
Also because for modprint the additional stats then have to be put
together manually.
- Also relating to 'modprint': no on-the-fly construction of the matrix
input seems possible, i.e. directly using $coeff~$stderr didn't work.
- Back to mle: its $model bundle has a "rho" member of value 1.#QNAN
which seems spurious in that context. (Fallout from the biprobit rho??)
Well, so much for that.
thanks
Sven
9:51 p.m.
On Sun, 7 Feb 2021, Sven Schreiber wrote:
I've noticed some things which may be quirks in relation to the
'mle' block.
- If I wrongly insert several "params" lines I get a weird data error
instead of a syntax error, so it took me a while to realize my mistake.
Could that be made clearer?
OK, it's now clearer in git. The translatable error message is "Only
one 'params' specification is allowed".
- In the guide in Listings 26.1 and 26.2 and throughout other places
in
ch. 26 the "genr" keyword is used. [...]
Those instances are now replaced with more modern syntax in git.
- I've been struggling without success to tell the mle command
what the
parameters should be called. The background being that I need to specify
a single composite vector to accommodate several specifications. In the
guide (ch.26) I saw a similar problem, and there the workaround was to
silence mle and instead semi-manually invoke the modprint apparatus. But
wouldn't it be more efficient if simply the wanted names could be
injected, replacing the generic stuff that is in the $parnames accessor?
Feature request?
- Also relating to 'modprint': no on-the-fly construction of
the matrix
input seems possible, i.e. directly using $coeff~$stderr didn't work.
I can't think of any command that accepts a formula to produce a
matrix when a matrix argument is wanted.
- Back to mle: its $model bundle has a "rho" member of
value 1.#QNAN
which seems spurious in that context. (Fallout from the biprobit rho??)
Nothing to do with biprobit: "rho" is a regular member of the gretl
MODEL struct, and it gets included in the $model bundle on that
basis, even if it's not applicable and hence "nan" (nicely decorated
by Microsoft above!). For instance, it's there in $model after OLS.
We could, of course, drop it when it's not applicable (as opposed
to, applicable but couldn't be calculated, if that ever arises).
Allin
11:02 p.m.
On Sun, 7 Feb 2021, Allin Cottrell wrote:
On Sun, 7 Feb 2021, Sven Schreiber wrote:
> relating to 'modprint': no on-the-fly construction of the matrix
> input seems possible, i.e. directly using $coeff~$stderr didn't work.
I can't think of any command that accepts a formula to produce a matrix when
a matrix argument is wanted.
But then, there aren't many such commands; and in several commands
where a scalar argument is wanted a simple formula is accepted. So
now in git we'll accept something like the above "$coeff~$stderr".
No spaces allowed in the matrix-generating expression, for reasons
that should be clear from the signature of the command.
Allin
11:18 p.m.
Am 08.02.2021 um 00:02 schrieb Allin Cottrell:
On Sun, 7 Feb 2021, Allin Cottrell wrote:
> On Sun, 7 Feb 2021, Sven Schreiber wrote:
>
>> relating to 'modprint': no on-the-fly construction of the matrix
>> input seems possible, i.e. directly using $coeff~$stderr didn't work.
>
> I can't think of any command that accepts a formula to produce a
> matrix when a matrix argument is wanted.
But then, there aren't many such commands; and in several commands where
a scalar argument is wanted a simple formula is accepted. So now in git
we'll accept something like the above "$coeff~$stderr". No spaces
allowed in the matrix-generating expression, for reasons that should be
clear from the signature of the command.
Thanks Allin - but also thanks for pointing out the limitations there.
I'm wondering whether that might cause further confusion down the road.
Perhaps it would be better to leave things as they were (ever sharpening
the information content of the error messages...) ?
Do I understand correctly that using some kind of function in there
would be OK for the parser?
(Stupid example, not that I really want to use it:
mshape($coeff ~ $stderr, rows($coeff), 2) )
thanks
sven
11:58 p.m.
On Mon, 8 Feb 2021, Sven Schreiber wrote:
Am 08.02.2021 um 00:02 schrieb Allin Cottrell:
> On Sun, 7 Feb 2021, Allin Cottrell wrote:
>
>> On Sun, 7 Feb 2021, Sven Schreiber wrote:
>>
>>> relating to 'modprint': no on-the-fly construction of the matrix
>>> input seems possible, i.e. directly using $coeff~$stderr didn't work.
>>
>> I can't think of any command that accepts a formula to produce a
>> matrix when a matrix argument is wanted.
>
> But then, there aren't many such commands; and in several commands where
> a scalar argument is wanted a simple formula is accepted. So now in git
> we'll accept something like the above "$coeff~$stderr". No spaces
> allowed in the matrix-generating expression, for reasons that should be
> clear from the signature of the command.
Thanks Allin - but also thanks for pointing out the limitations there.
I'm wondering whether that might cause further confusion down the road.
Perhaps it would be better to leave things as they were (ever sharpening
the information content of the error messages...) ?
Do I understand correctly that using some kind of function in there
would be OK for the parser?
(Stupid example, not that I really want to use it:
mshape($coeff ~ $stderr, rows($coeff), 2) )
That would definitely not work. Arguments to _commands_ are
space-separated, so what gretl would see in this case is
arg1="mshape($coeff", arg2="~", ... and we're way off the rails.
I can easily rescind acceptance of a space-free matrix
specification, other than just the name of a matrix, if that's going
to be confusing, and put in a more precise error message, such as
"The name of a matrix is expected".
Allin
10:36 a.m.
Am 08.02.2021 um 00:58 schrieb Allin Cottrell:
I can easily rescind acceptance of a space-free matrix
specification,
other than just the name of a matrix, if that's going to be confusing,
and put in a more precise error message, such as "The name of a matrix
is expected".
My feeling is that since in formulas spaces are not significant and even
wanted in terms of style and readability, requiring their absence is not
good. I like that error message you propose.
If we're talking about special syntax, maybe requiring parentheses to
delimit the arguments would be an option, as in:
modprint ($coeff ~ $stderr) names
I think that would be easy to explain to users (like me in this case).
thanks
sven
10:59 a.m.
Am 07.02.2021 um 22:51 schrieb Allin Cottrell:
On Sun, 7 Feb 2021, Sven Schreiber wrote:
> - I've been struggling without success to tell the mle
command what the
> parameters should be called. The background being that I need to specify
> a single composite vector to accommodate several specifications. In the
> guide (ch.26) I saw a similar problem, and there the workaround was to
> silence mle and instead semi-manually invoke the modprint apparatus. But
> wouldn't it be more efficient if simply the wanted names could be
> injected, replacing the generic stuff that is in the $parnames accessor?
Feature request?
I guess so, but I'm not exactly clear in what direction.
Since the problem rests with the content of $model.parnames, perhaps one
idea would be a new --parnames=myarray option to mle?
thanks
sven
11:15 a.m.
On Mon, 8 Feb 2021, Sven Schreiber wrote:
Am 07.02.2021 um 22:51 schrieb Allin Cottrell:
> On Sun, 7 Feb 2021, Sven Schreiber wrote:
>> - I've been struggling without success to tell the mle command what the
>> parameters should be called. The background being that I need to specify
>> a single composite vector to accommodate several specifications. In the
>> guide (ch.26) I saw a similar problem, and there the workaround was to
>> silence mle and instead semi-manually invoke the modprint apparatus. But
>> wouldn't it be more efficient if simply the wanted names could be
>> injected, replacing the generic stuff that is in the $parnames accessor?
>
> Feature request?
I guess so, but I'm not exactly clear in what direction.
Since the problem rests with the content of $model.parnames, perhaps one
idea would be a new --parnames=myarray option to mle?
A relatively clean and long-term (but not completely painless, I'm
afraid) solution would be switching from the command form to the function
form.
Something like
modprint($coeff ~ sqrt(diag($vcv)), $model.parnames)
would be quite easy to arrange, and would also make it quite easy to add
extra optional arguments if required. We could also envisage storing the
output as a string under $result.
The only problem vould be adding another of the command/function
duplications we currently have in hansl (sprintf, diff...) that I'm not
overly fond of.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
11:51 a.m.
Am 08.02.2021 um 12:15 schrieb Riccardo (Jack) Lucchetti:
On Mon, 8 Feb 2021, Sven Schreiber wrote:
The only problem vould be adding another of the command/function
duplications we currently have in hansl (sprintf, diff...) that I'm not
overly fond of.
This is of course a deviation from the mle naming problem, but in
principle I agree, the mixture of commands and functions is a bit of a
mess. Sometimes I think commands should be top-level only: script or
console, but not inside (user-defined) functions. Maybe we should even
aim for _full_ duplication of all commands as built-in functions, such
that inside user-defined functions one doesn't have to use commands?
But currently we have _some_ duplication without a clear guideline.
cheers
sven
9:11 p.m.
Am 08.02.2021 um 11:59 schrieb Sven Schreiber:
Am 07.02.2021 um 22:51 schrieb Allin Cottrell:
> On Sun, 7 Feb 2021, Sven Schreiber wrote:
>> - I've been struggling without success to tell the mle command what the
>> parameters should be called. The background being that I need to specify
>> a single composite vector to accommodate several specifications. In the
>> guide (ch.26) I saw a similar problem, and there the workaround was to
>> silence mle and instead semi-manually invoke the modprint apparatus. But
>> wouldn't it be more efficient if simply the wanted names could be
>> injected, replacing the generic stuff that is in the $parnames accessor?
>
> Feature request?
I guess so, but I'm not exactly clear in what direction.
Since the problem rests with the content of $model.parnames, perhaps one
idea would be a new --parnames=myarray option to mle?
Here's another idea: What about using the rownames of a vector for the
printout? Something like this in quasi-hansl:
# initialize
matrix cf = zeros(3)
# labels
rnameset(cf, "income invest price")
# estimate
mle loglik = ...some function of cf...
...
params cf
end mle
And the printout would substitute c[1], c[2], c[3] with income/invest/price.
thanks
sven
9:33 a.m.
Am 09.02.2021 um 22:11 schrieb Sven Schreiber:
Am 08.02.2021 um 11:59 schrieb Sven Schreiber:
> Am 07.02.2021 um 22:51 schrieb Allin Cottrell:
>> On Sun, 7 Feb 2021, Sven Schreiber wrote:
>>> wouldn't it be more efficient if simply the wanted
names could be
>>> injected, replacing the generic stuff that is in the $parnames
>>> accessor?
>>
>> Feature request?
>
> I guess so, but I'm not exactly clear in what direction.
>
> Since the problem rests with the content of $model.parnames, perhaps one
> idea would be a new --parnames=myarray option to mle?
Here's another idea: What about using the rownames of a vector
for the
printout? Something like this in quasi-hansl:
# initialize
matrix cf = zeros(3)
# labels
rnameset(cf, "income invest price")
...
And the printout would substitute c[1], c[2], c[3] with
income/invest/price.
Ping - this thread kind of died out, but the need is still there.
thanks
sven
1401
days inactive
1413
days old
10 comments
3 participants
participants (3)
-
Allin Cottrell -
Riccardo (Jack) Lucchetti -
Sven Schreiber