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