Hi Jiefei and Duncan, I suspect what is likely happening is that one of ENSURE_NAMEDMAX or MARK_NOT_MUTABLE are being hit for x. These used to set named to 3, but now set it to 7 (ie the previous and current NAMEDMAX value, respectively).
Because these are macros rather than C functions, its not easy to figure out why one of them is being invoked from do_isvector (a cursory exploration didn't reveal what was going on, at least to me) and I don't have the time to dig super deeply into this right now, but perhaps Luke or Tomas know why this is happening of the top of their head. Sorry I can't be of more help. ~G On Fri, Jul 12, 2019 at 11:47 AM Duncan Murdoch <murdoch.dun...@gmail.com> wrote: > On 12/07/2019 1:22 p.m., King Jiefei wrote: > > Hi, > > > > I just found a strange increase in the reference number and I'm wondering > > if there is any reason for it, here is the code. > > > >> a=c(1,2,3) > >> .Internal(inspect(a)) > > @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(1)] (len=3, tl=0) 1,2,3 > >> is.vector(a) > > [1] TRUE > >> .Internal(inspect(a)) > > @0x000000001bf0b9b0 14 REALSXP g0c3 [NAM(7)] (len=3, tl=0) 1,2,3 > > > > The variable *a* initially has one reference number, after calling > > *is.vector* function, the reference number goes to 7, which I believe is > > the highest number that is allowed in R. I also tried the other R > > functions, *is.atomic, is.integer* and *is.numeric* do not increase the > > reference number, but *typeof *will do. Is it intentional? > > is.vector() is a closure that calls .Internal. is.atomic(), > is.integer() and is.numeric() are all primitives. > > Generally speaking closures that call .Internal are easier to implement > (e.g. is.vector can use the regular mechanism to set a default for its > second argument), but less efficient in CPU time. From it's help page, > it appears that the logic for is.vector() is a lot more complex than for > the others, so that implementation does make sense. > > So why does NAMED go to 7? Initially, the vector is bound to a. Within > is.vector, it is bound to the local variable x. At this point there are > two names bound to the same object, so it has to be considered > immutable. There's really no difference between any of the values of 2 > or more in the memory manager. (But see > http://developer.r-project.org/Refcnt.html for some plans. That > document is from about 5 years ago; I don't know the current state.) > > Duncan Murdoch > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
