Hi, when using cnameset (and presumably also rnameset) w

On Sat, 16 Jan 2021, Sven Schreiber wrote: > Hi, > when using cnameset (and presumably also rnameset) with input that > doesn't match the dimensions, nothing happens. See here: > > <hansl> > matrix m = ones(2)    # column > cnameset(m, defarray("a","b")) # doesn't match, should give an error? > print m > </hansl> > > I wonder if an error should be thrown instead? Or else perhaps the first > available elements of the array should be used? Meybe, but it's operating per documentation: requiring a number of strings equal to the number of columns and returning non-zero on error. ? matrix m = ones(2) Generated matrix m ? eval cnameset(m, defarray("a","b"))

Am 16.01.2021 um 13:21 schrieb Artur Tarassow: > Am 16.01.21 um 01:41 schrieb Allin Cottrell: >> Meybe, but it's operating per documentation: requiring a number of >> strings equal to the number of columns and returning non-zero on error. > as it returns an error value, I don't think an error should be thrown > (which would lead to a full stop I guess - if not catched). The user is > responsible for testing the returned value in this case. Right, I overlooked the fact that an error code is provided by the function, sorry.

What about the other issue with the right number of --but partly empty-- strings? Checking errmsg(err) shows an 'invalid argument' error. My workaround is now to insert a one-blank string " " instead of an empty string "" in those places. I think, however, that it's a valid aim to only label a subset of the rows or columns, isn't it?

On Sat, 16 Jan 2021, Allin Cottrell wrote: > On Sat, 16 Jan 2021, Sven Schreiber wrote: > >> I think, however, that it's a valid aim to only label a subset of >> the rows or columns, isn't it? > > Not sure about that; we can debate it. On reflection, I don't like it: seems to me it would give a "broken" look to a matrix, to have only certain columns or rows labeled. But still, we can debate it.

Am 16.01.2021 um 19:03 schrieb Allin Cottrell: > On Sat, 16 Jan 2021, Sven Schreiber wrote: > > Actually I'm a bit uneasy about that, even though it's documented. It's > common in libgretl C code, and in many library APIs, to return 0 on > success or a non-zero code on failure. It's then up to the caller to > check the return value and decide what to do in case of error (which > might or might not be to abort execution). But it's not common in > scripting languages, including hansl. Generally, one expects that if a > command or function fails, execution of the script will halt, unless one > takes special measures ("catch" in hansl). Different paradigms, but > we're mixing them up, to a degree. > > So I would be in favour (not right now, just before release, of course) > of revising the relatively few gretl functions that do the "return an > error code" thing: let them actually fail on error, like the great > majority of functions. Sounds good - I guess that was also the reason why it didn't occur to me that the function would signal an error like that. I can collect of affected functions, unless you already know which ones would be in it?