Re: [Gretl-devel] array functions
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.
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.
Note that if we did not merge the two functions, then
matrices M = array(m[2])
would unambiguously select the first of these alternates, while
matrices M = mkarray(m[2])
would unambiguously select the second.
We could just legislate that one of these interpretations is favoured,
in which the user wanting the other one would have to take an extra step:
scalar n = m[2]
matrices M = array(n)
# OR
matrix m2 = m[2]
matrices M = array(m2)
This is basically the coercing that I suggested above, but requiring
extra lines.
But I think it may be cleaner to retain both functions (and of course,
document both).
I'm not against it, except for one thing: I think the name "array" is
not as clear as could be. Intuitively without prior knowledge I would
expect that it does what "mkarray" does. So I would prefer something
like "defarray" or "allocarray" or something like that. But of course
there is the backwards-compatibility issue; so perhaps this would be an
argument for a merge.
Second issue: at present the "print" command as applied to an array
gives fairly minimal information. For example, the input
<hansl>
strings S = mkarray("happy", "new", "year")
print S
</hansl>
produces the output
? print S
Array of strings, length 3
But we also have the undocumented function putarray(), which gives a
basic printout of the array members, as in
? putarray(S)
happy
new
year
Here, I'd like to canvas the options (a) keep what we have right now and
document putarray(), or (b) make the "print" command do what putarray()
does, and scrap putarray(). (Bear in mind that the array in question
might contain huge matrices rather than short strings.)
What about a type of --verbosity switch or option here? For example,
"print S --verbose" could imitate the current putarray() output.
Also, for an array of matrices something in-between could be useful,
printing the dimensions of each matrix element, but not the contents.
cheers,
sven