On Tue, 6 Oct 2020, Sven Schreiber wrote:
Am 06.10.2020 um 12:18 schrieb Riccardo (Jack) Lucchetti:
> On Tue, 6 Oct 2020, Sven Schreiber wrote:
>>> Well, I thought that it'd be nice if the description of nelem()
>>> mentioned the fact that this function is the preferred way of inferring
>>> the "size" of an object, including scalars. In fact, we could make
>>> nelem() functionally equivalent to nobs() for series.
>> Interesting idea; although for value added perhaps some differentiation
>> from nobs() might also be good. Say, working not over the current sample
>> but over the entire range (or something else, just a thought).
>> If the trend is to generalize nelem(), could it also become an alias for
>> strlen()? Or again, some variant thereof to provide value added?
> Or maybe, for the sake of keeping the namespace as small as possible, we
> could deprecate nobs() and strlen() in favour of nelem() and remove them
> in due course.
Not sure about that; nobs() has been there since 2003, this would
potentially be a very nasty change, and with little payoff I guess.
I agree. Besides, nobs() gives the number of valid observations in
the current sample range and that, it seems to me, is rather
different from giving the "size" of an object as nelem() does. I
tend to think that nelem should be confined to objects that have an
unambiguous, non-context dependent size.
As for strlen() I just checked and just recently it was extended to
string-valued series (and arrays). My guess is that nelem shouldn't do
that, so probably keep that as well?
Good point. I've just updated the strlen doc to reflect that
And talking about undocumented extensions, maybe we should mention
that nelem() can be applied to strings, in which case it returns the
number of bytes as opposed to the number of UTF-8 characters. Or we
could get rid of that.