wvenable@arcola.stats.adelaide.edu.au
1999-Apr-22 03:45 UTC
Assigning to a list within a loop (PR#175)
We noticed this bug in more complex code, but this succinctly describes the phenomenon. If you do not re-initialize a each time in the following loop, the final value only is assigned to all places when the loop is complete.> a <- b <- list() > for(i in 1:5) {+ a$alpha <- i + b[[i]] <- a + }> unlist(b)alpha alpha alpha alpha alpha 5 5 5 5 5 If a is re-created each time, however the correct behaviour happens:> b <- list() > for(i in 1:5) {+ a <- list(alpha = i) + b[[i]] <- a + }> unlist(b)alpha alpha alpha alpha alpha 1 2 3 4 5> version_ platform i586-unknown-linux arch i586 os linux system i586, linux status status.rev 0 major 0 minor 64.0 year 1999 month April day 8 language R>Bill Venables & Berwin Turlach. -- ----------------------------------------------------------------- Bill Venables, Statistician, CMIS Environmetrics Project. Physical address: Postal address: CSIRO Marine Laboratories, PO Box 120, 233 Middle St, Cleveland, Queensland Cleveland, Qld, 4163 AUSTRALIA AUSTRALIA Telephone: +61 7 3826 7251 Email: Bill.Venables@cmis.csiro.au Fax: +61 7 3826 7304 -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
On Thu, 22 Apr 1999 wvenable@arcola.stats.adelaide.edu.au wrote:> We noticed this bug in more complex code, but this succinctly > describes the phenomenon. > > If you do not re-initialize a each time in the following loop, > the final value only is assigned to all places when the loop is > complete. > > > a <- b <- list() > > for(i in 1:5) { > + a$alpha <- i > + b[[i]] <- a > + } > > unlist(b) > alpha alpha alpha alpha alpha > 5 5 5 5 5 > > If a is re-created each time, however the correct behaviour > happens: > > > > b <- list() > > for(i in 1:5) { > + a <- list(alpha = i) > + b[[i]] <- a > + } > > unlist(b) > alpha alpha alpha alpha alpha > 1 2 3 4 5 > > > version > _ > platform i586-unknown-linux > arch i586 > os linux > system i586, linux > status > status.rev 0 > major 0 > minor 64.0 > year 1999 > month April > day 8 > language R > > > > Bill Venables & Berwin Turlach. >I think that worse things could happen, the problem seems to be around line 1486 of subassign (the first line is missing in the current source) 1486 if( NAMED(y) ) y = duplicate(y); 1487 VECTOR(x)[offset] = y; 1488 break; 1489 I think that you need to duplicate y, and have added that line; but perhaps what you need to do is to increment NAMED of y(???) I'll commit it if Ross doesn't yell too loud -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- 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 _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
Before I go too far down the wrong track we need to think a little bit
about how "options" is going to behave in a threaded environment. The
reason for this is that S uses "options" to control most of the error
handling.
I'm sure that we want thread specific behaviour and that seems to imply
that "options" is going to have to be thread specific. Without
worrying
about how we are going to achieve that, does anyone have any qualms
about this?
Duncan has said that in S, when he threaded it, options was a frame 0
object and frame 0 was thread specific. We don't really have frames.
Conceptually it seems that we are going to have to stick an environment
between GlobalEnv and any evaluation envs where that environment
contains thread specific items (perhaps all assignments along that
thread).
As for error handling S offers:
error, interrupt, and warning.expression
as options. All of which are supposed to be expressions with no
arguments (no free variables I assume) that are evaluated when an
error, an interrupt or a warning occurs (if warning.expression is
non-null then options("warn") is ignored).
I should get those in today.
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._