[Rd] Re: Variable labels (was Re: [R] Reading SAS version 8 d
Warnes, Gregory R
Sun, 26 Aug 2001 01:15:20 -0400
> From: email@example.com [mailto:firstname.lastname@example.org]
> I think your code is more complex that is really needed.
> The problem with defaulting to deparse(...) is that
> multiple function pass-throughs return the wrong result:
> So I don't see a large role for the deparse(...) method.
Actually one of the reasons that I included the deparse(...) method was to
create a 'drop-in' substitute for the current calls to deparse(...) that are
found throughout the code and that would be backward-compatible. Having
such a call will immensely simplify changing existing code.
It's true that the variable names don't get correctly handled once you down
a layer of function calls, but that applies AFAIK to the current
deparse(...) method as well.
> The Hmisc library already defines label<- so if you
> are willing to use another name for your version that
> would prevent confusion from users of Hmisc.
I don't think there will be a problem as long as the functions do exactly
the same thing. To that end, perhaps we should agree on a common set of
functions and keep them in sync. I expect that your functions are better
tested than mine, since they've been available for some time.
> The problem of labels being retained after you do
> arithmetic on the variable is a real one, and one
> I've put up with for a long time with S-Plus. It would
> be nice if R could prevent that but that is getting tricky.
> What I've wanted more generally is the ability for the
> user to specify a vector of attribute names in options()
> that would be preserved upon subsetting. That way I
> wouldn't have to go to trouble to write local versions
> of [.factor, etc. that carry the 'label' attribute.
> Im my usage, 'label's are always logically carried
> forward for subsetting.
It seems to be a good idea to preserve the labels during subset operations.
What are the possible cons?
Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this E-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents of this E-mail or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately.
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: email@example.com