[Rd] for loop over S4
Hello,
Consider this :
setClass(track, representation(x=numeric, y=numeric))
[1] track
o - new( track, x = 1, y = 2 )
for( i in o ){
+ cat( hello\n)
+ }
Error: invalid type/length (S4/1) in vector allocation
This happens at those lines of do_for:
n = LENGTH(val);
PROTECT_WITH_INDEX(v = allocVector(TYPEOF(val), 1), vpi);
because allocVector( S4SXP, 1) does not make sense.
What about detecting S4SXP and attempt to call as.list, similarly to
what lapply does ?
as.list.track - function(x, ...){ list( x = x...@x, y = x...@y ) }
lapply( o, identity )
$x
[1] 1
$y
[1] 2
That would make for loops more generic, and make it possible to
implement custom iterators. I'm attaching a patch to eval.c that does
just that. For example :
setClass(iterator, representation(to=integer))
[1] iterator
o - new( iterator, to = 4L )
setGeneric( as.list )
[1] as.list
setMethod( as.list, iterator, function(x, ...) {
+ seq_len( x...@to )
+ })
[1] as.list
for( i in o ){
+ cat( i, \n )
+ }
1
2
3
4
Obviously that is the cheap way of doing it, something better would be
to abstract a bit more what is an iterator.
For example in java iterators implement just two methods : hasNext()
that indicates if there is a next object and next() that returns the
next object.
For the long story, one motivation for this is actually to deal with
java iterators (with the devel version of rJava, and this patch), you
might do something like this:
v - new( J(java/util/Vector) )
v$add( new( J(java/awt/Point), 10L, 10L ) )
[1] TRUE
v$add( new( J(java/lang/Double), 10 ) )
[1] TRUE
for( item in v ){
+ print( item$getClass()$getName() )
+ }
[1] java.awt.Point
[1] java.lang.Double
Where the as.list method for java object references returns a list that
is filled by iterating over the object if it implements the Iterable
interface.
The drawback here is that one has to first fully retrieve the list, by
iterating in java, and then process it in R, by iterating again in R.
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/BcPw : celebrating R commit #5
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
`- http://tr.im/yw8E : New R package : sos
Index: src/main/eval.c
===
--- src/main/eval.c (revision 50047)
+++ src/main/eval.c (working copy)
@@ -1046,6 +1046,17 @@
PROTECT(val = eval(val, rho));
defineVar(sym, R_NilValue, rho);
+/* deal with the S4 case, try to dispatch to as.list */
+if( TYPEOF(val) == S4SXP ){
+ SEXP expr ;
+ /* probably should use DispatchOrEval here */
+ PROTECT( expr = lang2(install(as.list), val ));
+ PROTECT( ans = eval( expr, rho ) ) ;
+ val = ans ;
+ UNPROTECT(3); /* expr, ans and val from above*/
+ PROTECT(val);
+}
+
/* deal with the case where we are iterating over a factor
we need to coerce to character - then iterate */
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] names drop for columns from data.frame (PR#14002)
Full_Name: Francisco Vera Version: 2.9.2 OS: Windows Submission from: (NULL) (74.248.242.164) Run the following commands: a-data.frame(x=1:2,y=3:4,row.names=c(i,j)) names(a$x) names(a[,1]) For names(a$x) I get NULL instead of c(i,j). Same thing happens with names(a[,1]). It works fine for rows, i.e., names(a[1,]) gives what is supposed to. It also works fine for matrices. If you issue the commands b-matrix(1:4,ncol=2,dimnames=list(c(x,y),c(i,j))) names(b[,1]) names(b[1,]) Thanks __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Sweave output encoding in R-2.10.0beta on Windows (Rgui - Rterm)
Dear developers,
I have come across a (somewhat strange) change in the encoding of Sweave
output from R-2.9.2pat to R-2.10.0beta (apparently specific to Rgui) on
Windows installations. Of course, the NEWS file contains quite a few
changes concerning encoding, but I was not able to locate an entry which
explains the observed behaviour. I am not very familiar with
encodings/locales/codepages, but I will try to explain my observations
as best I can.
In R-2.9.2pat, when invoking R via Rgui --vanilla (output of
seesionInfo() below), the output of Sweave for .rnw files containing
german umlaute (latin1-encoded) is again latin1-encoded (the resulting
.tex-file compiles with \usepackage[latin1]{inputenc} and
\usepackage[german]{babel}).
In R-2.10.0beta, however, when invoking R via Rgui --vanilla (output of
seesionInfo() below), some of Sweave's output (more precisely, Soutput
environments containing german umlaute, Sinput environments with german
umlaute are still latin1) is utf-8 encoded (with some extra characters
at the start and the end, which could be BOMs). Surprisingly, when R is
invoked from (Windows) command line (R --vanilla or Rterm --vanilla),
the encoding is completely latin1 again (as in R-2.9.2pat). So, the
change to utf-8 encoding for parts of Sweave's output seems to be
specific to Rgui.
Of course, I can work around this problem by using Rterm instead of Rgui
when Sweav'ing, but I am not sure if the current behaviour of R via Rgui
is as intended.
I will try to attach the .rnw - file as well as the resulting .tex -
files (and hope, that the attachements pass through).
Best wishes,
Martin
sessionInfo() for R-2.9.2pat (same for Rgui, R, Rterm):
R version 2.9.2 Patched (2009-09-24 r50041)
i386-pc-mingw32
locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
sessionInfo() for R-2.10.0beta (same for Rgui, R, Rterm):
R version 2.10.0 beta (2009-10-11 r50037)
i386-pc-mingw32
locale:
[1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252
[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C
[5] LC_TIME=German_Germany.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
--
Dr. Martin Becker
Statistics and Econometrics
Saarland University
Campus C3 1, Room 206
66123 Saarbruecken
Germany
\documentclass{article}
\usepackage{c:/Programme/R/R-2.10.0beta/share/texmf/Sweave}
\usepackage[latin1]{inputenc}
%\usepackage[utf8x]{inputenc}
\usepackage[german]{babel}
\begin{document}
=
Umlaute - c(ä,ö,ü,ß)
Umlaute
@
\end{document}
\documentclass{article}
\usepackage{c:/Programme/R/R-2.10.0beta/share/texmf/Sweave}
\usepackage[latin1]{inputenc}
%\usepackage[utf8x]{inputenc}
\usepackage[german]{babel}
\begin{document}
\begin{Schunk}
\begin{Sinput}
Umlaute - c(ä, ö, ü, ß)
Umlaute
\end{Sinput}
\begin{Soutput}
[1] ä ö ü ß
\end{Soutput}
\end{Schunk}
\end{document}
\documentclass{article}
\usepackage{c:/Programme/R/R-2.10.0beta/share/texmf/Sweave}
\usepackage[latin1]{inputenc}
%\usepackage[utf8x]{inputenc}
\usepackage[german]{babel}
\begin{document}
\begin{Schunk}
\begin{Sinput}
Umlaute - c(ä, ö, ü, ß)
Umlaute
\end{Sinput}
\begin{Soutput}
[1] ä ö ü ß
\end{Soutput}
\end{Schunk}
\end{document}
\documentclass{article}
\usepackage{c:/Programme/R/R-2.10.0beta/share/texmf/Sweave}
\usepackage[latin1]{inputenc}
%\usepackage[utf8x]{inputenc}
\usepackage[german]{babel}
\begin{document}
\begin{Schunk}
\begin{Sinput}
Umlaute - c(ä, ö, ü, ß)
Umlaute
\end{Sinput}
\begin{Soutput}
[1] ä ö ü ß
\end{Soutput}
\end{Schunk}
\end{document}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unexpected behavior in list of lexical closures (PR#14004)
Full_Name: Elliott Forney
Version: 2.9.2
OS: Linux, Fedora 10
Submission from: (NULL) (129.82.47.235)
The following code creates a list of functions that are lexically closed over a
single argument. If a print statement is included then each function in the
list evaluates to a different value. If the print statement is not included
then each function evaluates to something different, as expected. I am
convinced that this behavior is not correct as one would not expect the presence
of a lone print statement to alter the behavior of a program.
Please let me know if you have any questions and thank you for your time. The
sample code follows:
## returns a function that sums input with 5
funk - function(input)
{
## expected behavior if either of
## the following lines is uncommented
# print(input)
# input - input
## function to sum input with 5
## lexical closure over input
function()
{
input + 5
}
}
## create a list different funk's
funk.list - list()
for (i in 1:5)
{
## just some values to sum over
test.vector - 1:i
## add funk that sums test.vector with 5
funk.list[[i]] - funk(sum(test.vector))
}
## print result of evaluating each funk
## They are all the same unless print or
## reflexive assignment is uncommented!!
for (i in 1:5)
print(funk.list[[i]]())
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Sweave output encoding in R-2.10.0beta on Windows (Rgui - Rterm)
Ok,
apparently the most interesting attachement did not pass the filters
(probably because of the utf-8 encoding...).
Maybe it is still helpful to copypaste the Sweave output (with uft-8
part) for R-2.10.0beta invoked via Rgui --vanilla:
\documentclass{article}
\usepackage{c:/Programme/R/R-2.10.0beta/share/texmf/Sweave}
\usepackage[latin1]{inputenc}
%\usepackage[utf8x]{inputenc}
\usepackage[german]{babel}
\begin{document}
\begin{Schunk}
\begin{Sinput}
Umlaute - c(ä, ö, ü, ß)
Umlaute
\end{Sinput}
\begin{Soutput}
ÿþ[1] ä ö ü ßÿþ
\end{Soutput}
\end{Schunk}
\end{document}
Best wishes,
Martin
Martin Becker wrote:
Dear developers,
I have come across a (somewhat strange) change in the encoding of
Sweave output from R-2.9.2pat to R-2.10.0beta (apparently specific to
Rgui) on Windows installations. Of course, the NEWS file contains
quite a few changes concerning encoding, but I was not able to locate
an entry which explains the observed behaviour. I am not very familiar
with encodings/locales/codepages, but I will try to explain my
observations as best I can.
In R-2.9.2pat, when invoking R via Rgui --vanilla (output of
seesionInfo() below), the output of Sweave for .rnw files containing
german umlaute (latin1-encoded) is again latin1-encoded (the resulting
.tex-file compiles with \usepackage[latin1]{inputenc} and
\usepackage[german]{babel}).
In R-2.10.0beta, however, when invoking R via Rgui --vanilla (output
of seesionInfo() below), some of Sweave's output (more precisely,
Soutput environments containing german umlaute, Sinput environments
with german umlaute are still latin1) is utf-8 encoded (with some
extra characters at the start and the end, which could be BOMs).
Surprisingly, when R is invoked from (Windows) command line (R
--vanilla or Rterm --vanilla), the encoding is completely latin1 again
(as in R-2.9.2pat). So, the change to utf-8 encoding for parts of
Sweave's output seems to be specific to Rgui.
Of course, I can work around this problem by using Rterm instead of
Rgui when Sweav'ing, but I am not sure if the current behaviour of R
via Rgui is as intended.
I will try to attach the .rnw - file as well as the resulting .tex -
files (and hope, that the attachements pass through).
Best wishes,
Martin
sessionInfo() for R-2.9.2pat (same for Rgui, R, Rterm):
R version 2.9.2 Patched (2009-09-24 r50041)
i386-pc-mingw32
locale:
LC_COLLATE=German_Germany.1252;LC_CTYPE=German_Germany.1252;LC_MONETARY=German_Germany.1252;LC_NUMERIC=C;LC_TIME=German_Germany.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
sessionInfo() for R-2.10.0beta (same for Rgui, R, Rterm):
R version 2.10.0 beta (2009-10-11 r50037)
i386-pc-mingw32
locale:
[1] LC_COLLATE=German_Germany.1252 LC_CTYPE=German_Germany.1252 [3]
LC_MONETARY=German_Germany.1252 LC_NUMERIC=C [5]
LC_TIME=German_Germany.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Dr. Martin Becker
Statistics and Econometrics
Saarland University
Campus C3 1, Room 206
66123 Saarbruecken
Germany
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected behavior in list of lexical closures (PR#14004)
On 13/10/2009 1:50 AM, elliott.for...@gmail.com wrote:
Full_Name: Elliott Forney
Version: 2.9.2
OS: Linux, Fedora 10
Submission from: (NULL) (129.82.47.235)
This is not a bug, just a consequence of lazy evaluation. Arguments are
not evaluated when passed, but when first used. Since the input
argument is never evaluated in the commented version of funk below, it
isn't evaluated until one of the output functions is evaluated.
It's a good practice to force the evaluation of arguments to function
builders like this, for exactly the reason you saw. (The force()
function is one way to do it, but any expression evaluating the argument
will work.
Duncan Murdoch
The following code creates a list of functions that are lexically closed over a
single argument. If a print statement is included then each function in the
list evaluates to a different value. If the print statement is not included
then each function evaluates to something different, as expected. I am
convinced that this behavior is not correct as one would not expect the presence
of a lone print statement to alter the behavior of a program.
Please let me know if you have any questions and thank you for your time. The
sample code follows:
## returns a function that sums input with 5
funk - function(input)
{
## expected behavior if either of
## the following lines is uncommented
# print(input)
# input - input
## function to sum input with 5
## lexical closure over input
function()
{
input + 5
}
}
## create a list different funk's
funk.list - list()
for (i in 1:5)
{
## just some values to sum over
test.vector - 1:i
## add funk that sums test.vector with 5
funk.list[[i]] - funk(sum(test.vector))
}
## print result of evaluating each funk
## They are all the same unless print or
## reflexive assignment is uncommented!!
for (i in 1:5)
print(funk.list[[i]]())
__
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
Re: [Rd] for loop over S4
Hello,
Here is a more complete patch implementing an iterating scheme inspired
from the java Iterable/Iterator design.
Nothing is changed for non S4 objects.
The patch contains 4 generic functions :
is.iterable : indicates if an object is iterable. The default method
returns FALSE
iterator: returns the iterator associated with an iterable object. the
idea is that this function is only called if the object is iterable.
hasNext: indicates if an iterator has more elements. The default method
returns FALSE
getNext: returns the next element of the iterator
Here is an example:
require( methods )
setClass( SimpleIterable, representation( to=integer ) )
setClass(SimpleIterator, representation(to=integer, env =
environment) )
setMethod(is.iterable, SimpleIterable, function(x) TRUE )
setMethod(iterator, SimpleIterable, function(x){
env - new.env()
assign( i , 0L, envir = env )
new( SimpleIterator, to = x...@to, env = env )
} )
setMethod( hasNext, SimpleIterator, function(x){
res - x...@env[[i]] x...@to
res
} )
setMethod( getNext, SimpleIterator, function(x){
new.i - x...@env[[i]] + 1L
assign( i, new.i, envir = x...@env )
new.i
} )
o - new( SimpleIterable, to = 10L )
for( i in o ){
+ if( i == 3L ) next
+ if( i == 5L ) break
+ cat( i, \n )
+ }
1
2
4
Here is an example iterating over a java Iterable object (the methods
would need a bit more error trapping) without fetching all the elements
in advance:
require( rJava )
.jinit()
setMethod( is.iterable, jobjRef, function(x){
.jinherits( x, java/lang/Iterable )
} )
setMethod( iterator, jobjRef, function(x){
.jcall( x, Ljava/util/Iterator;, iterator )
} )
setMethod( hasNext, jobjRef, function(x){
.jcall( x, Z, hasNext )
} )
setMethod( getNext, jobjRef, function(x){
.jcall( x, Ljava/lang/Object;, next )
} )
v - new( J(java/util/Vector ) )
v$add( new( J(java/lang/Double ), 10.2 ) )
[1] TRUE
v$add( new( J(java/awt/Point), 10L, 10L ) )
[1] TRUE
for( i in v){
+ print( i$getClass()$getName() )
+ }
[1] java.lang.Double
[1] java.awt.Point
While I'm on this, in the usual for loop :
- why is the switch inside the for. The code would be slighly more
efficient if it was the other way ?
- why so many calls to TYPEOF, is it not always going to return the same
type ?
- why recreating v each time ?
(I probably miss something here)
Romain
On 10/13/2009 11:09 AM, Romain Francois wrote:
Hello,
Consider this :
setClass(track, representation(x=numeric, y=numeric))
[1] track
o - new( track, x = 1, y = 2 )
for( i in o ){
+ cat( hello\n)
+ }
Error: invalid type/length (S4/1) in vector allocation
This happens at those lines of do_for:
n = LENGTH(val);
PROTECT_WITH_INDEX(v = allocVector(TYPEOF(val), 1), vpi);
because allocVector( S4SXP, 1) does not make sense.
What about detecting S4SXP and attempt to call as.list, similarly to
what lapply does ?
as.list.track - function(x, ...){ list( x = x...@x, y = x...@y ) }
lapply( o, identity )
$x
[1] 1
$y
[1] 2
That would make for loops more generic, and make it possible to
implement custom iterators. I'm attaching a patch to eval.c that does
just that. For example :
setClass(iterator, representation(to=integer))
[1] iterator
o - new( iterator, to = 4L )
setGeneric( as.list )
[1] as.list
setMethod( as.list, iterator, function(x, ...) {
+ seq_len( x...@to )
+ })
[1] as.list
for( i in o ){
+ cat( i, \n )
+ }
1
2
3
4
Obviously that is the cheap way of doing it, something better would be
to abstract a bit more what is an iterator.
For example in java iterators implement just two methods : hasNext()
that indicates if there is a next object and next() that returns the
next object.
For the long story, one motivation for this is actually to deal with
java iterators (with the devel version of rJava, and this patch), you
might do something like this:
v - new( J(java/util/Vector) )
v$add( new( J(java/awt/Point), 10L, 10L ) )
[1] TRUE
v$add( new( J(java/lang/Double), 10 ) )
[1] TRUE
for( item in v ){
+ print( item$getClass()$getName() )
+ }
[1] java.awt.Point
[1] java.lang.Double
Where the as.list method for java object references returns a list that
is filled by iterating over the object if it implements the Iterable
interface.
The drawback here is that one has to first fully retrieve the list, by
iterating in java, and then process it in R, by iterating again in R.
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/BcPw : celebrating R commit #5
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
`- http://tr.im/yw8E : New R package : sos
Index: src/main/eval.c
===
--- src/main/eval.c (revision 50053)
+++ src/main/eval.c (working copy)
@@ -1025,15 +1025,67 @@
do_browser(call, op, R_NilValue, rho);
Re: [Rd] for loop over S4
Oops, forgot to add the R code.
On 10/13/2009 03:42 PM, Romain Francois wrote:
Hello,
Here is a more complete patch implementing an iterating scheme inspired
from the java Iterable/Iterator design.
Nothing is changed for non S4 objects.
The patch contains 4 generic functions :
is.iterable : indicates if an object is iterable. The default method
returns FALSE
iterator: returns the iterator associated with an iterable object. the
idea is that this function is only called if the object is iterable.
hasNext: indicates if an iterator has more elements. The default method
returns FALSE
getNext: returns the next element of the iterator
Here is an example:
require( methods )
setClass( SimpleIterable, representation( to=integer ) )
setClass(SimpleIterator, representation(to=integer, env =
environment) )
setMethod(is.iterable, SimpleIterable, function(x) TRUE )
setMethod(iterator, SimpleIterable, function(x){
env - new.env()
assign( i , 0L, envir = env )
new( SimpleIterator, to = x...@to, env = env )
} )
setMethod( hasNext, SimpleIterator, function(x){
res - x...@env[[i]] x...@to
res
} )
setMethod( getNext, SimpleIterator, function(x){
new.i - x...@env[[i]] + 1L
assign( i, new.i, envir = x...@env )
new.i
} )
o - new( SimpleIterable, to = 10L )
for( i in o ){
+ if( i == 3L ) next
+ if( i == 5L ) break
+ cat( i, \n )
+ }
1
2
4
Here is an example iterating over a java Iterable object (the methods
would need a bit more error trapping) without fetching all the elements
in advance:
require( rJava )
.jinit()
setMethod( is.iterable, jobjRef, function(x){
.jinherits( x, java/lang/Iterable )
} )
setMethod( iterator, jobjRef, function(x){
.jcall( x, Ljava/util/Iterator;, iterator )
} )
setMethod( hasNext, jobjRef, function(x){
.jcall( x, Z, hasNext )
} )
setMethod( getNext, jobjRef, function(x){
.jcall( x, Ljava/lang/Object;, next )
} )
v - new( J(java/util/Vector ) )
v$add( new( J(java/lang/Double ), 10.2 ) )
[1] TRUE
v$add( new( J(java/awt/Point), 10L, 10L ) )
[1] TRUE
for( i in v){
+ print( i$getClass()$getName() )
+ }
[1] java.lang.Double
[1] java.awt.Point
While I'm on this, in the usual for loop :
- why is the switch inside the for. The code would be slighly more
efficient if it was the other way ?
- why so many calls to TYPEOF, is it not always going to return the same
type ?
- why recreating v each time ?
(I probably miss something here)
Romain
On 10/13/2009 11:09 AM, Romain Francois wrote:
Hello,
Consider this :
setClass(track, representation(x=numeric, y=numeric))
[1] track
o - new( track, x = 1, y = 2 )
for( i in o ){
+ cat( hello\n)
+ }
Error: invalid type/length (S4/1) in vector allocation
This happens at those lines of do_for:
n = LENGTH(val);
PROTECT_WITH_INDEX(v = allocVector(TYPEOF(val), 1), vpi);
because allocVector( S4SXP, 1) does not make sense.
What about detecting S4SXP and attempt to call as.list, similarly to
what lapply does ?
as.list.track - function(x, ...){ list( x = x...@x, y = x...@y ) }
lapply( o, identity )
$x
[1] 1
$y
[1] 2
That would make for loops more generic, and make it possible to
implement custom iterators. I'm attaching a patch to eval.c that does
just that. For example :
setClass(iterator, representation(to=integer))
[1] iterator
o - new( iterator, to = 4L )
setGeneric( as.list )
[1] as.list
setMethod( as.list, iterator, function(x, ...) {
+ seq_len( x...@to )
+ })
[1] as.list
for( i in o ){
+ cat( i, \n )
+ }
1
2
3
4
Obviously that is the cheap way of doing it, something better would be
to abstract a bit more what is an iterator.
For example in java iterators implement just two methods : hasNext()
that indicates if there is a next object and next() that returns the
next object.
For the long story, one motivation for this is actually to deal with
java iterators (with the devel version of rJava, and this patch), you
might do something like this:
v - new( J(java/util/Vector) )
v$add( new( J(java/awt/Point), 10L, 10L ) )
[1] TRUE
v$add( new( J(java/lang/Double), 10 ) )
[1] TRUE
for( item in v ){
+ print( item$getClass()$getName() )
+ }
[1] java.awt.Point
[1] java.lang.Double
Where the as.list method for java object references returns a list that
is filled by iterating over the object if it implements the Iterable
interface.
The drawback here is that one has to first fully retrieve the list, by
iterating in java, and then process it in R, by iterating again in R.
Romain
--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/BcPw : celebrating R commit #5
|- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc
`- http://tr.im/yw8E : New R package : sos
Index: src/library/base/R/iterators.R
===
--- src/library/base/R/iterators.R (revision 0)
+++ src/library/base/R/iterators.R (revision 0)
@@ -0,0 +1,36 @@
+# File src/library/base/R/iterators.R
+# Part
[Rd] beta build problem
I am having the following problem building R-beta_2009-10-12_r50045.tar.gz on Ubuntu 9.04 - the Jaunty Jackalope Paul ... make[2]: Entering directory `/home/paul/toolchain/R/R-beta/src/library/Recommended' begin installing recommended package boot gzip: invalid option -- 'x' Try `gzip --help' for more information. tar: This does not look like a tar archive tar: Error exit delayed from previous errors Warning in utils::untar(pkg, exdir = tmpdir) : '/bin/gzip -dc boot.tgz | /home/paul/Mybin/gtar -xf '-' -C '/tmp/RtmpIEcemZ/R.INSTALL327b23c6'' returned error code 512 ERROR: error unpacking tarball make[2]: *** [boot.ts] Error 1 make[2]: Leaving directory `/home/paul/toolchain/R/R-beta/src/library/Recommended' make[1]: *** [recommended-packages] Error 2 make[1]: Leaving directory `/home/paul/toolchain/R/R-beta/src/library/Recommended' make: *** [stamp-recommended] Error 2 p...@dell-laptop:~/toolchain/R/R-beta$ La version française suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le présent courriel peut contenir de l'information privilégiée ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires désignés est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans délai à l'expéditeur un message électronique pour l'aviser que vous avez éliminé de votre ordinateur toute copie du courriel reçu. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] weigths in nls (PR#13991)
Message: 6
Date: Fri, 09 Oct 2009 10:35:51 -0600
From: Tony Plate tpl...@acm.org
Subject: Re: [Rd] weigths in nls (PR#13991)
To: stephen.b...@cibc.com
Cc: r-b...@r-project.org, r-de...@stat.math.ethz.ch
Message-ID: 4acf6667.4060...@acm.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
This is expected behavior from the way nls() is written. The nls()
function has a ... argument, which means that additional arguments are
allowed.
Under Arguments the docs say:
|...| Additional optional arguments. None are used at present.
As far as I can see in the code, nothing at all is done with the
additional arguments (consistent with the docs). I guess the ...
argument is there to allow for future development (though I'm not sure
what is gained by including ... as a formal argument now, and not just
adding it in the future if and when it is needed.)
In general, the use of ... arguments does add flexibility, but it takes
away some error-checking.
you are completely right: if `...' is not used at the moment (and that's
the situation for quite some years now) and if it does cause pitfalls
for the user like this one (the mistyping of 'weights' is especially
easy), why not remove it? or, for now, add a test to nls right in the
beginning whether `...' is empty or not and, in case it's not empty to
abort, since a non-empty `...' list at the moment is proof of an invalid
(or at least unintended) call of `nls'?
-- Tony Plate
stephen.b...@cibc.com wrote:
Potential bug:
I mistyped weights in the call ('weigths') and it did not produce any error=
message. The coefs were exactly the same like without weights, so I was su=
spicious and when weights(nls1) gave NULL, I saw my typo.
Usually the function will say Unused arguments, which shows you the error=
, but not nls.
Regards
Stephen
[[alternative HTML version deleted]]
__
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
Re: [Rd] beta build problem
Whatever '/home/paul/Mybin/gtar' is, it is not a tar unpacker so you will need to specify the TAR environment variable when you configure R. 'gtar' is very commonly GNU tar (it is on Fedora Linux for example and on most third-party toolsets for e.g. Solaris and AIX). It is an unwise choice of name for a personal script. On Tue, 13 Oct 2009, Paul Gilbert wrote: I am having the following problem building R-beta_2009-10-12_r50045.tar.gz on Ubuntu 9.04 - the Jaunty Jackalope Paul ... make[2]: Entering directory `/home/paul/toolchain/R/R-beta/src/library/Recommended' begin installing recommended package boot gzip: invalid option -- 'x' Try `gzip --help' for more information. tar: This does not look like a tar archive tar: Error exit delayed from previous errors Warning in utils::untar(pkg, exdir = tmpdir) : '/bin/gzip -dc boot.tgz | /home/paul/Mybin/gtar -xf '-' -C '/tmp/RtmpIEcemZ/R.INSTALL327b23c6'' returned error code 512 ERROR: error unpacking tarball make[2]: *** [boot.ts] Error 1 make[2]: Leaving directory `/home/paul/toolchain/R/R-beta/src/library/Recommended' make[1]: *** [recommended-packages] Error 2 make[1]: Leaving directory `/home/paul/toolchain/R/R-beta/src/library/Recommended' make: *** [stamp-recommended] Error 2 p...@dell-laptop:~/toolchain/R/R-beta$ La version fran??aise suit le texte anglais. This email may contain privileged and/or confidential information, and the Bank of Canada does not waive any related rights. Any distribution, use, or copying of this email or the information it contains by other than the intended recipient is unauthorized. If you received this email in error please delete it immediately from your system and notify the sender promptly by email that you have done so. Le pr??sent courriel peut contenir de l'information privil??gi??e ou confidentielle. La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute diffusion, utilisation ou copie de ce courriel ou des renseignements qu'il contient par une personne autre que le ou les destinataires d??sign??s est interdite. Si vous recevez ce courriel par erreur, veuillez le supprimer imm??diatement et envoyer sans d??lai ?? l'exp??diteur un message ??lectronique pour l'aviser que vous avez ??limin?? de votre ordinateur toute copie du courriel re??u. [[alternative HTML version deleted]] -- 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
