function string get_rnames(matrix M)    string s = sprintf("%d",M)    nss = nlines(s)    string line    scalar i = 1    strings S = array(nss)    loop while getline(s, line) -q        S[i]= sprintf("%s",  line)        i++    endloop    ret = ""    if nelem(strsplit(S[1])) == 2        loop i = 1..nss -q            ret = ret~" "~strsplit(S[i])[1]        endloop        ret = strstrip(ret)    endif    return ret end function # example M = I(2) M[1,1] = NA rownames(M, "a b") eval get_rnames(M) Is there a less roundabout way to extract row names of a matrix

Am 03.02.2018 um 03:33 schrieb Allin Cottrell: > On Sat, 3 Feb 2018, oleg_komashko(a)ukr.net wrote: >> Is there a less roundabout way to extract row names >> of a matrix > > OK, alright! By popular demand, there's now a rowname() function in git. Thanks! I've just reviewed the situation with colnames/colname/rownames, however, and I must say I find it not really obvious that colname --and now also rowname-- *gets* the names, while colnames/rownames *puts* names. The labeling seems confusing to me. Could we perhaps rename the new rowname to something like rnameget (or similar), and perhaps introduce a similar alias like cnameget for colname? And a further possible extension: Similar to strsplit(), the functions colname and rowname (or their new aliases) might also return an array of strings of *all* names in the case that the second index argument is omitted. (With some room for discussion on what to do in case of a vector.)

On Sat, 3 Feb 2018, Sven Schreiber wrote: > Am 03.02.2018 um 03:33 schrieb Allin Cottrell: >> On Sat, 3 Feb 2018, oleg_komashko(a)ukr.net wrote: > >>> Is there a less roundabout way to extract row names >>> of a matrix >> >> OK, alright! By popular demand, there's now a rowname() function in git. > > Thanks! > > I've just reviewed the situation with colnames/colname/rownames, however, > and I must say I find it not really obvious that colname --and now also > rowname-- *gets* the names, while colnames/rownames *puts* names. The > labeling seems confusing to me. > > Could we perhaps rename the new rowname to something like rnameget (or > similar), and perhaps introduce a similar alias like cnameget for colname? > > And a further possible extension: Similar to strsplit(), the functions > colname and rowname (or their new aliases) might also return an array of > strings of *all* names in the case that the second index argument is > omitted. Might as well strike while the iron is hot: that's now in git.

On Sat, 3 Feb 2018, Allin Cottrell wrote: > On Sat, 3 Feb 2018, Sven Schreiber wrote: > >> Am 03.02.2018 um 03:33 schrieb Allin Cottrell: >>> On Sat, 3 Feb 2018, oleg_komashko(a)ukr.net wrote: >> >>>> Is there a less roundabout way to extract row names >>>> of a matrix >>> >>> OK, alright! By popular demand, there's now a rowname() function in git. >> >> Thanks! >> >> I've just reviewed the situation with colnames/colname/rownames, however, >> and I must say I find it not really obvious that colname --and now also >> rowname-- *gets* the names, while colnames/rownames *puts* names. The >> labeling seems confusing to me. >> >> Could we perhaps rename the new rowname to something like rnameget (or >> similar), and perhaps introduce a similar alias like cnameget for colname? >> >> And a further possible extension: Similar to strsplit(), the functions >> colname and rowname (or their new aliases) might also return an array of >> strings of *all* names in the case that the second index argument is >> omitted. > > Might as well strike while the iron is hot: that's now in git. Why not go all the way, then? How about {c|r}name{get|set}?

Does it mean in all packages colnames() and rownames() should be renamed?

On Sat, 3 Feb 2018, Riccardo (Jack) Lucchetti wrote:

>> On Sat, 3 Feb 2018, Sven Schreiber wrote:

>>> --and now also rowname-- *gets* the names, while colnames/rownames >>> *puts* names.

> Why not go all the way, then? How about {c|r}name{get|set}? OK, good idea, nice and logical. That's now in git.

On Sat, 3 Feb 2018, Sven Schreiber wrote: > Am 03.02.2018 um 18:40 schrieb oleg_komashko(a)ukr.net: >> Does it mean in all packages colnames() and rownames() >> should be renamed? > > No, I cannot imagine such a thing. Perhaps at some point in the > future, but first any deprecated functions would be removed from the > documentation so that they are being used less and less. But the old > syntax would still be supported for some time. Just to be clear: the syntax as such is unchanged for colnames() and rownames(), although these functions have now been renamed. And the old names still work OK as aliases, for as long as need be.

Am 03.02.2018 um 18:54 schrieb Allin Cottrell: > On Sat, 3 Feb 2018, Sven Schreiber wrote: > >> Am 03.02.2018 um 18:40 schrieb oleg_komashko(a)ukr.net: >>> Does it mean in all packages colnames() and rownames() >>> should be renamed? >> >> No, I cannot imagine such a thing. Perhaps at some point in the future, >> but first any deprecated functions would be removed from the documentation >> so that they are being used less and less. But the old syntax would still >> be supported for some time. > > Just to be clear: the syntax as such is unchanged for colnames() and > rownames(), although these functions have now been renamed. And the old > names still work OK as aliases, for as long as need be. Hm, I've just tested current git (on Linux), and your example from this thread now fails, gretl is saying that the parser doesn't recognize 'rownames'. So the old names perhaps haven't been reinstalled as aliases yet?

On Mon, 5 Feb 2018, Sven Schreiber wrote: > Hm, I've just tested current git (on Linux), and your example from this > thread now fails, gretl is saying that the parser doesn't recognize > 'rownames'. So the old names perhaps haven't been reinstalled as aliases > yet? Hmm, the aliases have been added but they're not actually working. It seems that function-aliases have a problem that hasn't been noticed before: in "standalone" use they work only if there's assignment. So err = colnames(M) works OK, but not simply colnames(M). That's obviously a bug and it should be fixed shortly.