[Rd] Re: Variable labels (was Re: [R] Reading SAS version 8 d ata into

[Warnes, Gregory R]

> From: fharrell@virginia.edu [mailto:fharrell@virginia.edu]
> 
[snip]
> 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:
> 
[snip]
> 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?

-Greg


LEGAL NOTICE
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: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._