[R] attr vs attributes

Duncan Murdoch murdoch.duncan at gmail.com
Sat May 11 01:13:42 CEST 2013 

On 13-05-10 2:06 PM, William Dunlap wrote:
> Thanks.  I looks like my example worked because the value of the new
> attribute had a length greater than 1.  That difference in behavior
> smells like a bug.

Yes, definitely looks like one.  I'll submit the bug report; I hope 
someone else will fix it.

Duncan Murdoch

>
>    > { x <- 1 ; attributes(x)[["attrName"]] <- 2012 ; str(x) }
>    Error in attributes(x)[["attrName"]] <- 2012 :
>     attributes must be a list or NULL
>    > { x <- 1 ; attributes(x)[["attrName"]] <- 2012:2013 ; str(x) }
>     atomic [1:1] 1
>    - attr(*, "attrName")= int [1:2] 2012 2013
>
> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com
>
> From: Murat Tasan [mailto:mmuurr at gmail.com]
> Sent: Friday, May 10, 2013 10:56 AM
> To: William Dunlap
> Cc: r-help at r-project.org
> Subject: Re: [R] attr vs attributes
>
> sure, here's a series of commands/outputs (using R 3.0.0):
>
>> x <- letters[1:4]
>> y <- "foo"
>> attributes(x)
> NULL
>> attributes(x)[[y]] <- "bar"
> Error in attributes(x)[[y]] <- "bar" : attributes must be a list or NULL
>> attr(x, y) <- "bar"
>> attributes(x)
> $foo
> [1] "bar"
>
>> attributes(x)[[y]] <- "newbar"
>> attributes(x)
> $foo
> [1] "newbar"
>
>>
>
> cheers!
>
> -m
>
>
> On Fri, May 10, 2013 at 12:31 PM, William Dunlap <wdunlap at tibco.com<mailto:wdunlap at tibco.com>> wrote:
>>> attributes(my_obj)[[my_attr_name]] <- my_attr_value
>>
>> ...fails when my_obj doesn't already have an attribute named my_attr_name.
> Do you have an example of this?  In R-2.15.3 I don't see that problem:
>     > my_obj <- 37:41
>     > my_attr_name <- "myAttr"
>     > my_attr_value <- as.roman(2012:2013)
>     > attributes(my_obj)[[my_attr_name]] <- my_attr_value
>     > my_obj
>     [1] 37 38 39 40 41
>     attr(,"myAttr")
>     [1] MMXII  MMXIII
>
>    > attributes(my_obj)[["anotherAttrName"]] <- "another attribute value"
>    > my_obj
>    [1] 37 38 39 40 41
>    attr(,"myAttr")
>    [1] MMXII  MMXIII
>    attr(,"anotherAttrName")
>    [1] "another attribute value"
>
> Bill Dunlap
> Spotfire, TIBCO Software
> wdunlap tibco.com<http://tibco.com>
>
>
>> -----Original Message-----
>> From: r-help-bounces at r-project.org<mailto:r-help-bounces at r-project.org> [mailto:r-help-bounces at r-project.org<mailto:r-help-bounces at r-project.org>] On Behalf
>> Of Murat Tasan
>> Sent: Friday, May 10, 2013 8:16 AM
>> To: Duncan Murdoch
>> Cc: r-help at r-project.org<mailto:r-help at r-project.org>
>> Subject: Re: [R] attr vs attributes
>>
>> thanks, both.
>>
>> the only real difference between the two approaches that i can see is when
>> assigning _new_ attributes to an object where the attribute name is itself
>> variable.
>> something like this:
>>
>>> attributes(my_obj)[[my_attr_name]] <- my_attr_value
>>
>> ...fails when my_obj doesn't already have an attribute named my_attr_name.
>> BUT(!) it does work just fine when the attribute named my_attr_name is
>> already attached to my_obj.
>>
>> i guess in the end attr(...) is just easier, but i can also see a spot of
>> confusion in the 'attributes(x)[[y]] <- z' working sometimes for folks and
>> sometimes not.
>>
>> (to be clear, it's pretty easy to figure out when it does and doesn't work,
>> but if there's a new programmer coming along and it works the first time,
>> when the upstream code changes a bit (i.e. the attribute name changes) and
>> this attribute-setting line then fails, it could be very confusing :-)
>>
>> thanks for the thoughts!
>>
>> cheers,
>>
>> -m
>>
>>
>>
>>
>> On Fri, May 10, 2013 at 10:58 AM, Duncan Murdoch
>> <murdoch.duncan at gmail.com<mailto:murdoch.duncan at gmail.com>>wrote:
>>
>>> On 10/05/2013 10:50 AM, Rui Barradas wrote:
>>>
>>>> Hello,
>>>>
>>>> There's at least one example where only the form attr(x, "foo") <- "bar"
>>>> would work, not the other form. If you want to set attributes
>>>> programatically, use the first form, like in the function below. Note
>>>> that the example is artificial.
>>>>
>>>>
>>>> setAttr <- function(x, attrib, value){
>>>>          attr(x, attrib) <- value
>>>>          x
>>>> }
>>>>
>>>> x <- 1:4
>>>> setAttr(x, "foo", "bar")
>>>>
>>>>
>>>> You cannot make
>>>>
>>>> attribute(x)$attrib <- value
>>>>
>>>
>>> But
>>>
>>> attributes(x)[[attrib]] <- value
>>>
>>> would be fine.  I don't know why Murat thought there would be different
>>> consistency checks; I'd assume the main difference would be that attr()
>>> would be quicker.  (It does a lot less: attributes(x)[[attrib]] <- value
>>> essentially does
>>>
>>> temp <- attributes(x)
>>> temp[[attrib]] <- value
>>> attributes(x) <- temp
>>>
>>> and there are a lot of wasted operations there.)
>>>
>>> Duncan Murdoch
>>>
>>>
>>>
>>>>
>>>> Hope this helps,
>>>>
>>>> Rui Barradas
>>>>
>>>> Em 09-05-2013 18:35, Murat Tasan escreveu:
>>>>> hi all -- i looked through the R Language Definition document, but
>>>> couldn't
>>>>> find any particular warning or example that would clarify the best use
>>>> of
>>>>> attribute setting for R objects.
>>>>>
>>>>> let x be some R object, and i'd like to add attribute "foo" with value
>>>>> "bar".
>>>>>
>>>>> case 1:
>>>>>> attr(x, "foo") <- "bar"
>>>>>
>>>>> case 2:
>>>>>> attributes(x)$foo <- "bar"
>>>>>
>>>>> in both cases, attributes(x) reveals the appropriate setting has taken
>>>>> place.
>>>>> i'm assuming that attr(...) is 'safer' in the sense that perhaps
>>>>> consistency checks are made?
>>>>> (almost like a generic accessor/setter method?)
>>>>> but i also haven't seen any examples where case 2 (above) would bad...
>>>> is
>>>>> there are trivial such example out there?
>>>>>
>>>>> BTW -- the cause for interest here is when dealing with dendrogram
>>>> objects,
>>>>> for which much of the useful data are stored as attributes, and where
>>>>> running dendrapply means having to explicitly set attribute values to
>>>>> retain the tree structure in the resulting object.
>>>>>
>>>>> cheers,
>>>>>
>>>>> -m
>>>>>
>>>>>        [[alternative HTML version deleted]]
>>>>>
>>>>> ______________________________**________________
>>>>> R-help at r-project.org<mailto:R-help at r-project.org> mailing list
>>>>> https://stat.ethz.ch/mailman/**listinfo/r-
>> help<https://stat.ethz.ch/mailman/listinfo/r-help>
>>>>> PLEASE do read the posting guide http://www.R-project.org/**
>>>> posting-guide.html <http://www.R-project.org/posting-guide.html>
>>>>> and provide commented, minimal, self-contained, reproducible code.
>>>>>
>>>>
>>>> ______________________________**________________
>>>> R-help at r-project.org<mailto:R-help at r-project.org> mailing list
>>>> https://stat.ethz.ch/mailman/**listinfo/r-
>> help<https://stat.ethz.ch/mailman/listinfo/r-help>
>>>> PLEASE do read the posting guide http://www.R-project.org/**
>>>> posting-guide.html <http://www.R-project.org/posting-guide.html>
>>>> and provide commented, minimal, self-contained, reproducible code.
>>>>
>>>
>>>
>>
>>        [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-help at r-project.org<mailto:R-help at r-project.org> mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
>
> 	[[alternative HTML version deleted]]
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>

More information about the R-help mailing list