Re: [Rd] surprising behaviour of names<-
Berwin A Turlach wrote: > On Sat, 14 Mar 2009 07:22:34 +0100 > Wacek Kusnierczyk wrote: > > [...] > >>> Well, I don't see any new object created in my workspace after >>> x <- 4 >>> names(x) <- "foo" >>> Do you? >>> >>> >> of course not. that's why i'd say the two above are *not* >> equivalent. >> >> i haven't noticed the 'in the c code'; do you mean the r interpreter >> actually generates, in the c code, such r expressions for itself to >> evaluate? >> > > As I said before, I have little knowledge about how the parser works and > what goes on under the hood; and I have also little time and > inclination to learn about it. > > But if you are interested in these details, then by all means invest > the time to investigate. > > berwin, you're playing radio erewan now. i talk about what the user sees at the interface, and you talk about c code. then you admit you don't know the code, and suggest i examine it if i'm interested. i incidentally am, but the whole point was that the user should not be forced to look under the hood to know the interface to a function. prefix 'names<-' seems to have a certain behaviour that is not properly documented. > Alternatively, you would hope that Simon eventually finishes the book > that he is writing on programming in R; as I understand it, that book > would explain part of these issues in details. Hopefully, along with > the book he makes the tools that he has for introspection available. > simon: i'd be happy to contribute in any way you might find useful. > i guess you have looked under the hood; point me to the relevant code. >>> No I did not, because I am not interested in knowing such intimate >>> details of R, but it seems you were interested. >>> >>> >> yes, but then your claim about what happens under the hood, in the c >> code, is a pure stipulation. >> > > I made no claim about what is going on under the hood because I have no > knowledge about these matters. But, yes, I was speculating of what > might go on. > owe me a beer. > >> and you got the example from the r language definition sec. 10.2, >> which says the forms are equivalent, with no 'under the hood, in the >> c code' comment. >> > > Trying to figure out what a writer/painter actually means/says beyond > the explicitly stated/painted, something that is summed up in Australia > (and other places) under the term "critical thinking", was not high in > the curriculum of your school, was it? :-) > sure, but probably not the way you seem to think about. have you incidentally read ferdydurke by gombrowicz? > >> you're just showing that your statements cannot be taken seriously. >> > > Usually, my statement can be taken seriously, unless followed by some > indication that I said them tongue-in-cheek. Of course, statements > that I allegedly made but were in fact put into my mouth cannot, and > should not, be taken seriously. > i'm talking about your speculations about what the parser does (wrt. infix and prefix forms having exactly the same parse tree), rather vague statements such as "'names<-'(x,'foo') should create (more or less) a parse tree equivalent to that expression", and other statements (surely, qualified with 'assuming', 'strongly suggests', and the like), coupled with your admitting that you in fact donæt know what happens there, is not particularly reassuring. > yes, *if* you are able to predict the refcount of the object passed to 'names<-' *then* you can predict what 'names<-' will do, [...] >>> I think Simon pointed already out that you seem to have a wrong >>> picture of what is going on. [...] >>> >> so what you quote effectively talks about a specific refcount >> mechanism. it's not refcount that would be used by the garbage >> collector, but it's a refcount, or maybe refflag. >> > > Fair enough, if you call this a refcount then there is no problem. > Whenever I came across the term refcount in my readings, it was > referring to different mechanisms, typically mechanisms that kept exact > track on how often an object was referred too. So I would not call the > value of the named field a refcount. And we can agree to call it from > now on a refcount as long as we realise what mechanism is really used. > the major point of the discussion was that 'names<-' will sometimes modify and othertimes copy its argument. you chose to justify this by looking under the hood, and i suppose you were pretty clear what i meant by refcount, because it should have been clear from the context. > > >> yes, that's my opinion: the effects of implementation tricks should >> not be observable by the user, because they can lead to hard to >> explain and debug behaviour in the user's program. you surely don't >> suggest that all users consult the source code before writing >> programs in r. >> > > Indeed, I am not suggesting
Re: [Rd] surprising behaviour of names<-
On Sat, 14 Mar 2009 07:22:34 +0100 Wacek Kusnierczyk wrote: [...] > > Well, I don't see any new object created in my workspace after > > x <- 4 > > names(x) <- "foo" > > Do you? > > > > of course not. that's why i'd say the two above are *not* > equivalent. > > i haven't noticed the 'in the c code'; do you mean the r interpreter > actually generates, in the c code, such r expressions for itself to > evaluate? As I said before, I have little knowledge about how the parser works and what goes on under the hood; and I have also little time and inclination to learn about it. But if you are interested in these details, then by all means invest the time to investigate. Alternatively, you would hope that Simon eventually finishes the book that he is writing on programming in R; as I understand it, that book would explain part of these issues in details. Hopefully, along with the book he makes the tools that he has for introspection available. > >> i guess you have looked under the hood; point me to the relevant > >> code. > > > > No I did not, because I am not interested in knowing such intimate > > details of R, but it seems you were interested. > > > > yes, but then your claim about what happens under the hood, in the c > code, is a pure stipulation. I made no claim about what is going on under the hood because I have no knowledge about these matters. But, yes, I was speculating of what might go on. > and you got the example from the r language definition sec. 10.2, > which says the forms are equivalent, with no 'under the hood, in the > c code' comment. Trying to figure out what a writer/painter actually means/says beyond the explicitly stated/painted, something that is summed up in Australia (and other places) under the term "critical thinking", was not high in the curriculum of your school, was it? :-) > you're just showing that your statements cannot be taken seriously. Usually, my statement can be taken seriously, unless followed by some indication that I said them tongue-in-cheek. Of course, statements that I allegedly made but were in fact put into my mouth cannot, and should not, be taken seriously. > >> yes, *if* you are able to predict the refcount of the object > >> passed to 'names<-' *then* you can predict what 'names<-' will do, > >> [...] > > > > I think Simon pointed already out that you seem to have a wrong > > picture of what is going on. [...] > > so what you quote effectively talks about a specific refcount > mechanism. it's not refcount that would be used by the garbage > collector, but it's a refcount, or maybe refflag. Fair enough, if you call this a refcount then there is no problem. Whenever I came across the term refcount in my readings, it was referring to different mechanisms, typically mechanisms that kept exact track on how often an object was referred too. So I would not call the value of the named field a refcount. And we can agree to call it from now on a refcount as long as we realise what mechanism is really used. > yes, that's my opinion: the effects of implementation tricks should > not be observable by the user, because they can lead to hard to > explain and debug behaviour in the user's program. you surely don't > suggest that all users consult the source code before writing > programs in r. Indeed, I am not suggesting this. Only users who use/rely on features that are not sufficiently documented would have to study the source code to find out what the exact behaviour is. But, of course, this could be fraught with danger since the behaviour could change without warning. > i have indeed learned what prefix 'names<-' does and now i know that > the surprising behaviour is due to the observability of the internal > optimization. > > thanks to simon, peter, and you for your answers which allowed me to > learn this ugly detail. You are welcome. Cheers, Berwin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] surprising behaviour of names<-
On Fri, 13 Mar 2009, William Dunlap wrote: Would it make anyone any happier if the manual said that the replacement functions should not be called in the form xNew <- `func<-` (xOld, value) and should only be used as func(xToBeChanged) <- value ? That was my reaction, too. The discussion reminded me of old comp.lang.c threads about i=i++ and similar issues. The anomalies in xNew <- `func<-` (xOld, value) arise precisely because it isn't supposed to be used that way. My other proposal for 'rigidly defined areas of doubt and uncertainty' has been the evaluation order of the *apply family (eg, does apply process the columns left to right, or right to left, or however it feels like?). -thomas Thomas Lumley Assoc. Professor, Biostatistics tlum...@u.washington.eduUniversity of Washington, Seattle __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
