Re: [Gretl-devel] array functions
On Wed, 13 Jan 2016, Sven Schreiber wrote:
Am 02.01.2016 um 01:37 schrieb Allin Cottrell:
> Given the fixes we've accumulated, and given that the New Year is upon
> us, I'm thinking we should do a new release soon.
Always welcome!
> However, I'm now thinking that the merger is not such a good idea, on
> account of the ambiguity of something like the following:
>
> <hansl>
> matrix m = {1, 3, 5}
> matrices M = array(m[2])
> </hansl>
>
> Do we read this as a request to create an array with 3 empty matrix
> slots, or as a request to create an array with one member, namely the
> second element of m, taken as a 1 x 1 matrix?
I'm not sure that this is really a problem with the two functions and
their merging. Instead the ambiguity seems to come from the eternal
problem of scalar-vs.-one-element-matrix.
Not really, IMO. Subject to correction (I mean, special cases I may
have overlooked), I think that "eternal problem" is pretty much
solved: the general intent is that anywhere a scalar is wanted a 1x1
matrix is also accepted, and vice versa.
My concern about the mooted merger of array() and mkarray() is that
this would create a unique situation where a scalar and a 1x1 matrix
_cannot_ be treated as equivalent.
Therefore, a possible solution might be to introduce some syntax
such
that users can coerce the result to a matrix or to a scalar. For
example, using enclosing braces {} might be extended to mean "I want
this to be/remain a matrix". If casting to matrix isn't possible, this
would be an error. So,
matrices M = array({m[2]})
would mean a one-element array with element {3}. Or use a function mat()
or matrix() to do the coercing. For coercing to a scalar I don't have a
concrete suggestion right now, except also a function scalar(), but
there are various possibilities.
That's a possibility, but my hypothesis is that array() would be the
only case where this apparatus would actually be needed.
Allin