Re: [Rd] Inheritance before ANY...
> "CG" == Christophe Genolini
> on Tue, 09 Jun 2009 22:11:51 +0200 writes:
CG> Hi all,
CG> I am programming using S4. I define two classes, "B" is inheriting from
CG> "A". Apparently (at least since version 2.9.0 ?), when the correct
CG> signature is not find,
CG> R prefers to chose a signature in the ancestor BEFORE a signature in
the
CG> class. This is very strange to me...
CG> If I define plot for ("A",missing) and ("B",ANY), calling
CG> plot("B",missing), I would expect R to chose plot("B",ANY) before
CG> plot("A",missing)
CG> -- (translate from french)
CG> Note : method with signature "A#missing" chose for function "plot",
CG> signature cible "B#missing".
CG> "B#ANY" could also be compatible
Yes, method dispatch had indirectly been greatly improved
in 2.9.0, as the elimination of duplicate superclasses and a
consistent (superclass) ordering was introduced.
Look at
?Methods
and skip to its references (simply "sr" in ESS),
finding
Chambers, John M.(2009) _Developments in Class Inheritance and
Method Selection_ http://stat.stanford.edu/~jmc4/classInheritance.pdf>.
which is very recommended, and, BTW, as I just notice, has been
updated in the very last few days,
judging from my earlier reading; the updates include new
features of class definition / method dispatch in the situation
where S3 and S4 are intermingled.
Regards,
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cmdscale & non-Euclidean dissimilarities
Dear R gurus,
I think that cmdscale() function has problems with non-Euclidean
distances which have negative eigenvalues. The problems are two-fold:
(1) Wrong eigenvalue is removed: there will be at least one zero
eigenvalue in cmdscale, and the function assumes it is the last one.
With non-Euclidean dissimilarities you will have negative eigenvalues,
and the zero eigenvalue will be the last positive one before negative
eigenvalues. Now the function returns the zero eigenvalue and
corresponding zero-eigenvector, but drops the last negative eigenvalue
(which has larger absolute value than any other negative eigenvalue).
(2) Gower (1985) says that with non-Euclidean matrices and negative
eigenvalues you will have imaginary axes, and the distances on imaginary
axes (negative eigenvalues) should be subtracted from the distances on
real axes (positive eigenvalues). The formulation in the article is like
this (Gower 1985, p. 93):
"""
f_{ii} + f_{jj} - 2 f_{ij} = d_{ij}^2 =
\sum_{p=1}^r (l_{pi} - l_{pj})^2 - \sum_{p=r+1}^{r+s} (l_{pi} - l_{pj})^ 2
This is the usual "Pythagorean" representation of squared distances in
terms of coordinates $l_{pi} (p = 1, 2 \ldots r+s)$, except that for
$p>r$ the coordinates become purely imaginary.
"""
This also suggests that for GOF (goodness of fit) measure of cmdscale()
the negative eigenvalues should be subtracted from the sum of positive
eigenvalues. Currently, the function uses two ways: the sum of abs
values of eigenvalues (and it should be sum of eigenvalues with their
signs), and the sum of above-zero eigenvalues for the total. The latter
makes some sense, but the first looks non-Gowerian.
Reference
Gower, J. C. (1985) Properties of Euclidean and non-Euclidean distance
matrices. Linear Algebra and its Applications 67, 81--97.
The following change seems to avoid both problems. The change removes
only the eigenvalue that is closest to the zero. There may be more than
one zero eigenvalue (or of magnitude 1e-17), but this leaves the rest
there. It also changes the way the first alternative of GOF is
calculated. This changes the code as little as possible, and it still
leaves behind some cruft of the old code that assumed that last
eigenvalue is the zero eigenvalue.
--- R/src/library/stats/R/cmdscale.R(revision 48741)
+++ R/src/library/stats/R/cmdscale.R(working copy)
@@ -56,6 +56,9 @@
x[non.diag] <- (d[non.diag] + add.c)^2
}
e <- eigen(-x/2, symmetric = TRUE)
+zeroeig <- which.min(abs(e$values))
+e$values <- e$values[-zeroeig]
+e$vectors <- e$vectors[ , -zeroeig, drop = FALSE]
ev <- e$values[1L:k]
if(any(ev < 0))
warning(gettextf("some of the first %d eigenvalues are < 0", k),
@@ -63,9 +66,9 @@
points <- e$vectors[, 1L:k, drop = FALSE] %*% diag(sqrt(ev), k)
dimnames(points) <- list(rn, NULL)
if (eig || x.ret || add) {
-evalus <- e$values[-n]
+evalus <- e$values
list(points = points, eig = if(eig) ev, x = if(x.ret) x,
ac = if(add) add.c else 0,
- GOF = sum(ev)/c(sum(abs(evalus)), sum(evalus[evalus > 0])))
+ GOF = sum(ev)/c(sum(evalus), sum(evalus[evalus > 0])))
} else points
}
Best wishes, Jari Oksanen
--
Jari Oksanen -- Dept Biology, Univ Oulu, FI-90014 Oulu, Finland
email jari.oksa...@oulu.fi, homepage http://cc.oulu.fi/~jarioksa/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reduce: extra args wishlist?
On Sat, 6 Jun 2009, Ben Bolker wrote:
Is there a reason that Reduce() doesn't take a "..." argument that
would allow arbitrary extra arguments to be passed through to the function?
Here is a little example of how this would be convenient:
z <- list(
data.frame(state=c("California"),
cases=0),
data.frame(state=c("California","Massachusetts"),
cases=c(1,2)),
data.frame(state=c("California","Massachusetts","Arizona"),
cases=c(1,2,17)))
## read in revised version of Reduce()
Reduce(merge,z,by="state",all=TRUE)
The change is simple -- just add "..." to every call to the function
in Reduce() -- patch is included below my signature ...
It's not a big deal -- I could also do
Reduce(function(x,y) { merge(x,y,by="state",all=TRUE) }, z)
but there doesn't seem to be a good reason not to allow it ...
I think the idiom of the languages from which this comes would indeed
to be use an anonymous function, and in R to use ... and no braces, as
in
Reduce(function(...) merge(..., by="state", all=TRUE), z)
But that's not the (ony) R idiom, so I am happy to add a ... argument
to Reduce. Unfortunately the patch below is backwards (you have diffs
from old to new in 'patch' format), and we do need to patch the
documentation (which gets a bit ugly as ... has a different meaning
for another function on the Reduce help page). I think I have sorted
these out, and will commit to R-devel shortly.
cheers
Ben Bolker
--
Ben Bolker
Associate professor, Biology Dep't, Univ. of Florida
bol...@ufl.edu / www.zoology.ufl.edu/bolker
GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc
*** /home/ben/funprog.R.new 2009-06-06 18:30:56.0 -0400
--- src/library/base/R/funprog.R2009-02-12 10:39:32.0 -0500
***
*** 15,21
# http://www.r-project.org/Licenses/
Reduce <-
! function(f, x, init, right = FALSE, accumulate = FALSE, ...)
{
mis <- missing(init)
len <- length(x)
--- 15,21
# http://www.r-project.org/Licenses/
Reduce <-
! function(f, x, init, right = FALSE, accumulate = FALSE)
{
mis <- missing(init)
len <- length(x)
***
*** 47,57
if(!accumulate) {
if(right) {
for(i in rev(ind))
! init <- f(x[[i]], init, ...)
}
else {
for(i in ind)
! init <- f(init, x[[i]], ...)
}
init
}
--- 47,57
if(!accumulate) {
if(right) {
for(i in rev(ind))
! init <- f(x[[i]], init)
}
else {
for(i in ind)
! init <- f(init, x[[i]])
}
init
}
***
*** 64,76
if(right) {
out[[len]] <- init
for(i in rev(ind)) {
! init <- f(x[[i]], init, ...)
out[[i]] <- init
}
} else {
out[[1L]] <- init
for(i in ind) {
! init <- f(init, x[[i]], ...)
out[[i]] <- init
}
}
--- 64,76
if(right) {
out[[len]] <- init
for(i in rev(ind)) {
! init <- f(x[[i]], init)
out[[i]] <- init
}
} else {
out[[1L]] <- init
for(i in ind) {
! init <- f(init, x[[i]])
out[[i]] <- init
}
}
***
*** 78,91
if(right) {
out[[len]] <- init
for(i in rev(ind)) {
! init <- f(x[[i]], init, ...)
out[[i]] <- init
}
}
else {
for(i in ind) {
out[[i]] <- init
! init <- f(init, x[[i]], ...)
}
out[[len]] <- init
}
--- 78,91
if(right) {
out[[len]] <- init
for(i in rev(ind)) {
! init <- f(x[[i]], init)
out[[i]] <- init
}
}
else {
for(i in ind) {
out[[i]] <- init
! init <- f(init, x[[i]])
}
out[[len]] <- init
}
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reduce: extra args wishlist?
Prof Brian Ripley wrote: > I think the idiom of the languages from which this comes would indeed > to be use an anonymous function, and in R to use ... and no braces, as > in > > Reduce(function(...) merge(..., by="state", all=TRUE), z) > > But that's not the (ony) R idiom, so I am happy to add a ... argument > to Reduce. Unfortunately the patch below is backwards (you have diffs > from old to new in 'patch' format), and we do need to patch the > documentation (which gets a bit ugly as ... has a different meaning > for another function on the Reduce help page). I think I have sorted > these out, and will commit to R-devel shortly. Hmm. Thanks. Sorry about the patch glitch. (On my Ubuntu system, patch has a -R flag that would seem to take care of that ...) I accepted Kurt's explanation. I'm curious what the protocol is when R-core members differ? (I would have guessed that conservatism would rule, or the opinion of the original author of the functions (I don't know who contributed Reduce et al.), but perhaps Kurt doesn't have strong feelings about this ... cheers Ben -- Ben Bolker Associate professor, Biology Dep't, Univ. of Florida bol...@ufl.edu / www.zoology.ufl.edu/bolker GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc signature.asc Description: OpenPGP digital signature __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Reduce: extra args wishlist?
If ... is not available you can get a minor reduction using fn$ in gsubfn. Any function call prefaced by fn$ allows the use of formulas as functions (and perl-like interpolation of strings) in the call args (subject to certain rules that determine which args are interpreted and which not). The LHS of the formula specifies the args but if omitted then it uses the free variables from the RHS in the order encountered: > library(gsubfn) > fn$Reduce(~ merge(x, y, by = "state", all = TRUE), z) state cases.x cases.y cases 1California 0 1 1 2 Massachusetts NA 2 2 3 Arizona NA NA17 See http://gsubfn.googlecode.com for more. On Wed, Jun 10, 2009 at 10:06 AM, Ben Bolker wrote: > Prof Brian Ripley wrote: >> I think the idiom of the languages from which this comes would indeed >> to be use an anonymous function, and in R to use ... and no braces, as >> in >> >> Reduce(function(...) merge(..., by="state", all=TRUE), z) >> >> But that's not the (ony) R idiom, so I am happy to add a ... argument >> to Reduce. Unfortunately the patch below is backwards (you have diffs >> from old to new in 'patch' format), and we do need to patch the >> documentation (which gets a bit ugly as ... has a different meaning >> for another function on the Reduce help page). I think I have sorted >> these out, and will commit to R-devel shortly. > > Hmm. Thanks. Sorry about the patch glitch. (On my Ubuntu system, > patch has a -R flag that would seem to take care of that ...) > > I accepted Kurt's explanation. I'm curious what the protocol is when > R-core members differ? (I would have guessed that conservatism would > rule, or the opinion of the original author of the functions (I don't > know who contributed Reduce et al.), but perhaps Kurt doesn't have > strong feelings about this ... > > cheers > Ben > > > > -- > Ben Bolker > Associate professor, Biology Dep't, Univ. of Florida > bol...@ufl.edu / www.zoology.ufl.edu/bolker > GPG key: www.zoology.ufl.edu/bolker/benbolker-publickey.asc > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .Rhistory created with wrong permissions (PR#13752)
Hi,
This is with a centos 5.3 x86_64 system, using R 2.8.1 (details below).
In a directory where R is invoked, at the end of a session R offers to
"Save workspace image". Replying yes creates/updates at least two files
in the current directory: .Rhistory and .RData.
.Rhistory is created with permissions 0600, therefore it effectively
ignores umask. In particular, .Rhistory cannot be group-readable, which
can be problematic in some environments.
This is not the case for .RData (created 0666, modified by umask as
usual), so I doubt that the .Rhistory permissions are restrictive by design?
If not, it would be better to create .Rhistory 0666 and let the user
control the actual permissions through umask.
Regards,
Nicolas Thierry-Mieg
*
Steps to reproduce:
[nthie...@tryo ~]$ mkdir ttt
[nthie...@tryo ~]$ cd ttt
[nthie...@tryo ttt]$ R
> y<-3
> q()
Save workspace image? [y/n/c]: y
[nthie...@tryo ttt]$ ls -la
total 20
drwxr-xr-x 2 nthierry timb 4096 Jun 10 16:21 .
drwxr-x--- 80 nthierry timb 4096 Jun 10 15:18 ..
-rw-r--r-- 1 nthierry timb 61 Jun 10 16:21 .RData
-rw--- 1 nthierry timb9 Jun 10 16:21 .Rhistory
[nthie...@tryo ttt]$
Using strace on the R process shows the following, which seems to
confirm that the problem comes from R itself:
open(".RDataTmp", O_WRONLY|O_CREAT|O_TRUNC, 0666)
rename(".RDataTmp", ".RData")
open(".Rhistory", O_WRONLY|O_CREAT|O_TRUNC, 0600)
*
> version
platform x86_64-redhat-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 8.1
year 2008
month 12
day22
svn rev47281
language R
version.string R version 2.8.1 (2008-12-22)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reference counting bug related to break and next in loops
Thanks for the report.
It turns out that a similar issue arises in while() loops without
break/next being involved because the test expression is evaluated
after the final body evaluation. After some discussion we decided it
was simplest both for implementation and documentation to have the
value of a loop expression always be NULL. This is now implemented in
R-devel.
luke
On Tue, 2 Jun 2009, William Dunlap wrote:
One of our R users here just showed me the following problem while
investigating the return value of a while loop. I added some
information
on a similar bug in for loops. I think he was using 2.9.0
but I see the same problem on today's development version of 2.10.0
(svn 48703).
Should the semantics of while and for loops be changed slightly to avoid
the memory
buildup that fixing this to reflect the current docs would entail? S+'s
loops return nothing useful - that change was made long ago to avoid
memory buildup resulting from semantics akin the R's present semantics.
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
Forwarded (and edited) message
below---
--
I think I have found another reference counting bug.
If you type in the following in R you get what I think is the wrong
result.
i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) { break }; i =
i + 1; y}; q
[1] 42 42 42 42 42 42 42 42 9 10
I had expected [1] 42 42 42 42 42 42 42 8 9 10 which is what you get
if you add 0 to y in the last statement in the while loop:
i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) { break }; i =
i + 1; y + 0}; q
[1] 42 42 42 42 42 42 42 8 9 10
Also,
i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) { break };
i<-i+1 ; if (i<=8&&i>3)next ; cat("Completing iteration", i, "\n"); y};
q
Completing iteration 2
Completing iteration 3
[1] 42 42 42 42 42 42 42 42 9 10
but if the last statement in the while loop is y+0 instead of y I get
the
expected result:
i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) { break };
i<-i+1 ; if (i<=8&&i>3)next ; cat("Completing iteration", i, "\n");
y+0L}; q
Completing iteration 2
Completing iteration 3
[1] 42 42 3 4 5 6 7 8 9 10
A background to the problem is that in R a while-loop returns the value
of the last iteration. However there is an exception if an iteration is
terminated by a break or a next. Then the value is the value of the
previously completed iteration that did not execute a break or next.
Thus in an extreme case the value of the while may be the value of the
very first iteration even though it executed a million iterations.
Thus to implement that correctly one needs to keep a reference to the
value of the last non-terminated iteration. It seems as if the current R
implementation does that but does not increase the reference counter
which explains the odd behavior.
The for loop example is
z<-{ tmp<-rep(pi,10);for(i in 1:10){ tmp[i]<-i^2;if(i==9)break ; if
(i<9&&i>3)next ; tmp } }
z
[1] 1.00 4.00 9.00 16.00 25.00 36.00
49.00
[8] 64.00 81.00 3.141593
z<-{ tmp<-rep(pi,10);for(i in 1:10){ tmp[i]<-i^2;if(i==9)break ; if
(i<9&&i>3)next ; tmp+0 } }
z
[1] 1.00 4.00 9.00 3.141593 3.141593 3.141593 3.141593
3.141593
[9] 3.141593 3.141593
I can think of a couple of ways to solve this.
1. Increment the reference counter. This solves the bug but may
have serious performance implications. In the while example above it
needs to copy y in every iteration.
2. Change the semantics of while loops by getting rid of the
exception described above. When a loop is terminated with a break the
value of the loop would be NULL. Thus there is no need to keep a
reference to the value of the last non-terminated iteration.
Any opinions?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: l...@stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Rhistory created with wrong permissions (PR#13752)
nicolas.thierry-m...@imag.fr wrote:
Hi,
This is with a centos 5.3 x86_64 system, using R 2.8.1 (details below).
In a directory where R is invoked, at the end of a session R offers to
"Save workspace image". Replying yes creates/updates at least two files
in the current directory: .Rhistory and .RData.
.Rhistory is created with permissions 0600, therefore it effectively
ignores umask. In particular, .Rhistory cannot be group-readable, which
can be problematic in some environments.
This is not the case for .RData (created 0666, modified by umask as
usual), so I doubt that the .Rhistory permissions are restrictive by design?
I`m not sure, but it may be by design. For example, users sometimes use
passwords to connections, which one might not want accidentally recorded
in a readable file.
Paul
If not, it would be better to create .Rhistory 0666 and let the user
control the actual permissions through umask.
Regards,
Nicolas Thierry-Mieg
*
Steps to reproduce:
[nthie...@tryo ~]$ mkdir ttt
[nthie...@tryo ~]$ cd ttt
[nthie...@tryo ttt]$ R
> y<-3
> q()
Save workspace image? [y/n/c]: y
[nthie...@tryo ttt]$ ls -la
total 20
drwxr-xr-x 2 nthierry timb 4096 Jun 10 16:21 .
drwxr-x--- 80 nthierry timb 4096 Jun 10 15:18 ..
-rw-r--r-- 1 nthierry timb 61 Jun 10 16:21 .RData
-rw--- 1 nthierry timb9 Jun 10 16:21 .Rhistory
[nthie...@tryo ttt]$
Using strace on the R process shows the following, which seems to
confirm that the problem comes from R itself:
open(".RDataTmp", O_WRONLY|O_CREAT|O_TRUNC, 0666)
rename(".RDataTmp", ".RData")
open(".Rhistory", O_WRONLY|O_CREAT|O_TRUNC, 0600)
*
> version
platform x86_64-redhat-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status
major 2
minor 8.1
year 2008
month 12
day22
svn rev47281
language R
version.string R version 2.8.1 (2008-12-22)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
La version française suit le texte anglais.
This email may contain privileged and/or confidential in...{{dropped:26}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reference counting bug related to break and next in loops
Thanks Luke.
I used codetools::walkCode to look for functions that returned the
value of a loop and found a surprising number in base R.
However, it looks like non of these functions were written to return
anything useful (the side effects were important), so the change
to loop-returns-NULL should let such functions use less
memory (and time) and make them correspond better to their
documentation.
E.g., fixup.libraries.URLs is not documented to return anything
and it returns the value of for loop:
$`src/library/utils/R/windows/linkhtml.R`[[2]]
function(lib.loc = .libPaths())
{
for (lib in lib.loc) {
if(lib == .Library) next
pg <- sort(.packages(all.available = TRUE, lib.loc = lib))
for(pkg in pg)
try(fixup.package.URLs(file.path(lib,pkg)), silent = TRUE)
}
}
Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com
> -Original Message-
> From: l...@stat.uiowa.edu [mailto:l...@stat.uiowa.edu]
> Sent: Wednesday, June 10, 2009 1:05 PM
> To: William Dunlap
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] reference counting bug related to break and
> next in loops
>
> Thanks for the report.
>
> It turns out that a similar issue arises in while() loops without
> break/next being involved because the test expression is evaluated
> after the final body evaluation. After some discussion we decided it
> was simplest both for implementation and documentation to have the
> value of a loop expression always be NULL. This is now implemented in
> R-devel.
>
> luke
>
> On Tue, 2 Jun 2009, William Dunlap wrote:
>
> > One of our R users here just showed me the following problem while
> > investigating the return value of a while loop. I added some
> > information
> > on a similar bug in for loops. I think he was using 2.9.0
> > but I see the same problem on today's development version of 2.10.0
> > (svn 48703).
> >
> > Should the semantics of while and for loops be changed
> slightly to avoid
> > the memory
> > buildup that fixing this to reflect the current docs would
> entail? S+'s
> > loops return nothing useful - that change was made long ago to avoid
> > memory buildup resulting from semantics akin the R's
> present semantics.
> >
> > Bill Dunlap
> > TIBCO Software Inc - Spotfire Division
> > wdunlap tibco.com
> >
> > Forwarded (and edited) message
> >
> below-
> --
> > --
> >
> > I think I have found another reference counting bug.
> >
> > If you type in the following in R you get what I think is the wrong
> > result.
> >
> >> i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) {
> break }; i =
> > i + 1; y}; q
> > [1] 42 42 42 42 42 42 42 42 9 10
> >
> > I had expected [1] 42 42 42 42 42 42 42 8 9 10 which is
> what you get
> > if you add 0 to y in the last statement in the while loop:
> >
> >> i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) {
> break }; i =
> > i + 1; y + 0}; q
> > [1] 42 42 42 42 42 42 42 8 9 10
> >
> > Also,
> >
> >> i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) { break };
> > i<-i+1 ; if (i<=8&&i>3)next ; cat("Completing iteration",
> i, "\n"); y};
> > q
> > Completing iteration 2
> > Completing iteration 3
> > [1] 42 42 42 42 42 42 42 42 9 10
> >
> > but if the last statement in the while loop is y+0 instead
> of y I get
> > the
> > expected result:
> >
> >> i = 1; y = 1:10; q = while(T) { y[i] = 42; if (i == 8) { break };
> > i<-i+1 ; if (i<=8&&i>3)next ; cat("Completing iteration", i, "\n");
> > y+0L}; q
> > Completing iteration 2
> > Completing iteration 3
> > [1] 42 42 3 4 5 6 7 8 9 10
> >
> > A background to the problem is that in R a while-loop
> returns the value
> > of the last iteration. However there is an exception if an
> iteration is
> > terminated by a break or a next. Then the value is the value of the
> > previously completed iteration that did not execute a break or next.
> > Thus in an extreme case the value of the while may be the
> value of the
> > very first iteration even though it executed a million iterations.
> >
> > Thus to implement that correctly one needs to keep a
> reference to the
> > value of the last non-terminated iteration. It seems as if
> the current R
> > implementation does that but does not increase the reference counter
> > which explains the odd behavior.
> >
> > The for loop example is
> >
> >> z<-{ tmp<-rep(pi,10);for(i in 1:10){ tmp[i]<-i^2;if(i==9)break ; if
> > (i<9&&i>3)next ; tmp } }
> >> z
> > [1] 1.00 4.00 9.00 16.00 25.00 36.00
> > 49.00
> > [8] 64.00 81.00 3.141593
> >> z<-{ tmp<-rep(pi,10);for(i in 1:10){ tmp[i]<-i^2;if(i==9)break ; if
> > (i<9&&i>3)next ; tmp+0 } }
> >> z
> > [1] 1.00 4.00 9.00 3.141593 3.141593 3.141593 3.141593
> > 3.141593
> > [9] 3.141593 3.141593
> >
> > I can think of a couple of ways to solve this.
> >
> > 1. Increment the reference counter. Th
