Re: [Rd] Small inconsistency with boxplot
Dear R-core team,
I think I found a small inconsistency in the boxplot function. I don't want
to post it as a bug since I'm not sure this might be considered as one
according to the FAQ --- and this is not a major problem. Don't hesitate to
tell me if I'm wrong.
If you try to do a boxplot on a matrix and set the at argument to some
vector different from 1:n, n is the number of columns of your matrix, then
some boxplots will be hidden since the default xlim value will be set to
c(0.5, n + 0.5) during the call of the bxp function.
Currently you can easily bypass this problem by setting xlim appropriately
when calling the boxplot function.
Yes. And the help page for bxp even has the following note:
\note{
if \code{add = FALSE}, the default is \code{xlim = c(0.5, n +0.5)}.
It will usually be a good idea to specify the latter if the x axis
has a log scale or \code{at} is specified or \code{width} is far from
uniform.
}
which clearly documents the current behavior.
(and one could say also ``excuses'' the current behavior)
In this sense, there's really no bug ... ;-) and you were
very wise (or at least cautious :-) *not* to post it as bug ..
I think it will be better if all boxplots were always shown unless the xlim
argument is specified. (I realized this behavior when I tried to do boxplots
on conditional simulations of a stochastic process ; in which case the
suggested behavior might be useful.)
I do agree that such a change would be more ``logical'' i.e.,
according to The Rule of Least Surprise
(a good software design principle of providing a default behavior
of least surprise to the user).
Here's an example
par(mfrow = c(1, 3))
data - matrix(rnorm(10 * 50), 50)
colnames(data) - letters[1:10]
x.pos - seq(-10, 10, length = 10)
boxplot(data, at = x.pos) ## only the last 5 boxplots will appear
boxplot(data, at = 1:10) ## all boxplots will appear
boxplot(data, at = x.pos, xlim = range(x.pos) + c(-0.5, 0.5)) ## all boxplots
will be shown
I tried to do a patch if you want to change the current behavior --- note
this is my first patch ever so maybe I'm doing it wrong.
it looks good.
In the end, I would use
xlim - range(at, finite=TRUE) + c(-0.5, 0.5)
There's one ***BIG*** question though:
How probable is it that it breaks someone else's code.
Note that boxplot() and bxp() are *REALLY* old traditional S
functions
(and for all the young guys: Boxplots where invented/proposed
by the famous John W Tukey, co-inventor of the FFT, the word
bit; exploratory data analysis, etc etc.
Then (partly) at Bell Labs, who via John Chambers and
co-workers also donated the S language and hence R to the world !)
and therefore you can expect many many uses of boxplot() in
other code...
and hence, it could well be that some code has (probably
implicitly) *relied* on the current more surprising behavior.
I'd still advocate to the change the default here,
but we really have to discuss this, as a change also may have
adverse consequences.
Martin Maechler, ETH Zurich (and R Core)
*** Downloads/R-2.14.0/src/library/graphics/R/boxplot.R Mon Oct 3
00:02:21 2011
--- boxplot.R Thu Nov 17 23:02:45 2011
***
*** 203,209
}
if(is.null(pars$xlim))
! xlim - c(0.5, n + 0.5)
else {
xlim - pars$xlim
pars$xlim - NULL
--- 203,209
}
if(is.null(pars$xlim))
! xlim - c(min(at) - 0.5, max(at) + 0.5)
else {
xlim - pars$xlim
pars$xlim - NULL
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strange behavior from cex=*
Someone ambitious could find problems like
this using random input testing like I talked
about at useR last summer.
http://www.burns-stat.com/pages/Present/random_input_test_annotated.pdf
Testing graphics would be more labor intensive
than the testing I do, but you could think of it
as a video game.
On 17/11/2011 00:29, Duncan Murdoch wrote:
On 11-11-16 5:26 PM, Ben Bolker wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11-11-16 05:18 PM, peter dalgaard wrote:
On Nov 16, 2011, at 22:38 , Ben Bolker wrote:
Someone inquired on StackOverflow about apparently non-deterministic
graphics behaviour in R. I noticed that they were using cex=* and
discovered some potentially weird behavior.
It can be reproduced much more simply (well, not the hang, but bad
enough):
In a plain R application console (OSX Snow Leopard),
for (i in 1:100) plot(1:10,cex=*)
will _sometimes_ show big circles, indicating random data being
picked up.
The cex is by definition numeric, so you can't expect to be able to
pass a character string, but the code should check.
Looks (?) like the check could go in FixupCex (which already tests for
isReal, isInteger, and isLogical) in src/main/plot.c , unless there is a
wish to catch it earlier/in R code.
Yes, that's where the check was missed. I'll fix it. The other
parameters appear to have been checked properly.
It's mildly surprising to me that people can continue to find odd
cases like this after more than 10 years (and imagine how many
cumulative hours of R use ...) [I'm assuming that this hole has been
present for a log time: I don't have the patience to do the SVN
archaeology to find out how long.]
So now you can prove me wrong about the other parameters...
Duncan Murdoch
On repeated runs of the same code I can get different PNGs. If I set
the number of runs high enough, I seem to be able to get R to hang.
If I do a single version plotting to an interactive graphics window I
can get the point sizes to jump around as I resize the window (someone
reported being able to reproduce that behaviour in the Windows GUI
as well).
This is clearly a user error, but non-deterministic behaviour (and
hanging) are a little disturbing.
I haven't had a chance yet to try to dig in and see what's happening
but thought I would report to see if anyone else could
reproduce/figure
it out.
Ben Bolker
## n- 100 ## hangs R
n- 33
fn- paste(tmp,seq(n),png,sep=.)
for (i in seq(n)) {
png(fn[i])
plot(1:10,1:10,cex=*);
dev.off()
}
ff- subset(file.info(fn),select=size)
ff- ff[!duplicated(ff$size),,drop=FALSE]
table(ff$size)
require(png)
pngs- lapply(rownames(ff),readPNG)
png.to.img- function(x) matrix(rgb(x[,,1],x[,,2],x[,,3]),
nrow=dim(x)[1],ncol=dim(x)[2])
imgs- lapply(pngs,png.to.img)
par(mfrow=c(2,2))
lapply(imgs,function(x) {
plot(0:1,0:1,type=n,ann=FALSE,axes=FALSE)
rasterImage(x,0,0,1,1)
})
#
sessionInfo()
R Under development (unstable) (2011-10-06 r57181)
Platform: i686-pc-linux-gnu (32-bit)
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] glmmADMB_0.6.5 MASS_7.3-14 png_0.1-3
loaded via a namespace (and not attached):
[1] grid_2.15.0 lattice_0.19-33 nlme_3.1-102 tools_2.15.0
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOxDiKAAoJED2whTVMEyK9ThoIAIjyMpzZqsjUpJVbAb9K8IrL
LbSFh8zb+cZb90ABkFwJaZ2FNTKCjPrUzOYzxxHuU9AY0bdPQGbIm2hvQfzcuMlc
urS/ILIMzZEFSYkqkj0mWI9SADyJ+W0YeN/t3EuWy8nZqUkYQZ8M0GsuXjhtUL/i
hVJU0uuIWCOCHpeI3SQKoxviTE6MQFRXXWhCAJx01h8ee/5UQ5GSGB7Er2Zilld3
0sLI6dmoF7gbeYqz33MaEpQ7geJoW3tfnVbQWUlF86+jGGv5trIqWYIp33OYIxMO
u2YUq51vB+4uIRPFJ4Oyr+nJF0Z9NH4IJBipp/bF6wQ5u6JdXFqKTPeQ1V6m5qk=
=YajM
-END PGP SIGNATURE-
__
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
--
Patrick Burns
pbu...@pburns.seanet.com
twitter: @portfolioprobe
http://www.portfolioprobe.com/blog
http://www.burns-stat.com
(home of 'Some hints for the R beginner'
and 'The R Inferno')
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check: Undocumented class for class created with setOldClass()
Hi all, in a package, I register two S3 classes (namely ff_vector and ffdf) by calling setOldClass() in order to use them as slots in S4 classes. Now, R CMD check gives me the warning: Undocumented S4 classes: 'ff_vector' 'ffdf' Is there a way to avoid having to document classes I did not write? Or is this intended behaviour? Best regards, Andreas -- Andreas Borg Abteilung Medizinische Informatik Universitätsmedizin der Johannes Gutenberg-Universität Mainz Institut für Med. Biometrie, Epidemiologie und Informatik (IMBEI) Obere Zahlbacher Straße 69, 55131 Mainz Tel: +49 (0) 6131 17-5062 E-Mail: andreas.b...@uni-mainz.de __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call in R
Hi,
A probably very naive remark, but I believe that the probability of sum(
runif(1) ) = 5 is exactly 0.5. So why not just test that, and
generate the uniform values only if needed ?
Karl Forner
On Thu, Nov 17, 2011 at 6:09 PM, Raymond gw...@mail.missouri.edu wrote:
Hi R developers,
I am new to this forum and hope someone can help me with .Call in R.
Greatly appreciate any help!
Say, I have a vector called vecA of length 1, I generate a vector
called vecR with elements randomly generated from Uniform[0,1]. Both vecA
and vecR are of double type. I want to replace elements vecA by elements in
vecR only if sum of elements in vecR is greater than or equal to 5000.
Otherwise, vecR remain unchanged. This is easy to do in R, which reads
vecA-something;
vecR-runif(1);
if (sum(vecR)=5000)){
vecA-vecR;
}
Now my question is, if I am going to do the same thing in R using .Call.
How can I achieve it in a more efficient way (i.e. less computation time
compared with pure R code above.). My c code (called change_vecA.c)
using
.Call is like this:
SEXP change_vecA(SEXP vecA){
int i,vecA_len;
double sum,*res_ptr,*vecR_ptr,*vecA_ptr;
vecA_ptr=REAL(vecA);
vecA_len=length(vecA);
SEXP res_vec,vecR;
PROTECT(res_vec=allocVector(REALSXP, vec_len));
PROTECT(vecR=allocVector(REALSXP, vec_len));
res_ptr=REAL(res_vec);
vecR_ptr=REAL(vecR);
GetRNGstate();
sum=0.0;
for (i=0;ivecA_len;i++){
vecR_ptr[i]=runif(0,1);
sum+=vecR_ptr[i];
}
if (sum=5000){
/*copy vecR to the vector to be returned*/
for (i=0;ivecA_len;i++){
res_ptr[i]=vecR_ptr[i];
}
}
else{
/*copy vecA to the vector to be returned*/
for (i=0;ivecA_len;i++){
res_ptr[i]=vecA_ptr[i];
}
}
PutRNGstate();
UNPROTECT(2);
resturn(res);
}
My R wrapper function is
change_vecA-function(vecA){
dyn.load(change_vecA.so);
.Call(change_vecA,vecA);
}
Now my question is, due to two loops (one generates the random
vector and one determines the vector to be returned), can .Call still be
faster than pure R code (only one loop to copy vecR to vecA given condition
is met)? Or, how can I improve my c code to avoid redundant loops if any.
My
concern is if vecA is large (say of length 100 or even bigger), loops
in
C code can slow things down. Thanks for any help!
--
View this message in context:
http://r.789695.n4.nabble.com/Call-in-R-tp4080721p4080721.html
Sent from the R devel mailing list archive at Nabble.com.
__
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
Re: [Rd] .Call in R
On 11/18/2011 07:08 AM, Karl Forner wrote:
Hi,
A probably very naive remark, but I believe that the probability of sum(
runif(1) )= 5 is exactly 0.5. So why not just test that, and
generate the uniform values only if needed ?
My thought as well, but actually the deviates need to have mean .5 so
you'd do something like
repeat {
vecA - runif(1)
if (mean(vecA) .5) break
}
You'd do this 1/2 the time, and you'd have to itearte on average 1 /
(1/2) = 2 times before getting the vector satisfying the constraint, so
the expected number of iterations is 1/2 * 2 = 1, the same as in the
original implementation!
It does suggest that there is only one allocation required, if this were
coded at the C level. But since sum(), mean(), and runif() all go more
or less directly to C anyway it doesn't seem like this is the right
problem for a C solution.
Martin
Karl Forner
On Thu, Nov 17, 2011 at 6:09 PM, Raymondgw...@mail.missouri.edu wrote:
Hi R developers,
I am new to this forum and hope someone can help me with .Call in R.
Greatly appreciate any help!
Say, I have a vector called vecA of length 1, I generate a vector
called vecR with elements randomly generated from Uniform[0,1]. Both vecA
and vecR are of double type. I want to replace elements vecA by elements in
vecR only if sum of elements in vecR is greater than or equal to 5000.
Otherwise, vecR remain unchanged. This is easy to do in R, which reads
vecA-something;
vecR-runif(1);
if (sum(vecR)=5000)){
vecA-vecR;
}
Now my question is, if I am going to do the same thing in R using .Call.
How can I achieve it in a more efficient way (i.e. less computation time
compared with pure R code above.). My c code (called change_vecA.c)
using
.Call is like this:
SEXP change_vecA(SEXP vecA){
int i,vecA_len;
double sum,*res_ptr,*vecR_ptr,*vecA_ptr;
vecA_ptr=REAL(vecA);
vecA_len=length(vecA);
SEXP res_vec,vecR;
PROTECT(res_vec=allocVector(REALSXP, vec_len));
PROTECT(vecR=allocVector(REALSXP, vec_len));
res_ptr=REAL(res_vec);
vecR_ptr=REAL(vecR);
GetRNGstate();
sum=0.0;
for (i=0;ivecA_len;i++){
vecR_ptr[i]=runif(0,1);
sum+=vecR_ptr[i];
}
if (sum=5000){
/*copy vecR to the vector to be returned*/
for (i=0;ivecA_len;i++){
res_ptr[i]=vecR_ptr[i];
}
}
else{
/*copy vecA to the vector to be returned*/
for (i=0;ivecA_len;i++){
res_ptr[i]=vecA_ptr[i];
}
}
PutRNGstate();
UNPROTECT(2);
resturn(res);
}
My R wrapper function is
change_vecA-function(vecA){
dyn.load(change_vecA.so);
.Call(change_vecA,vecA);
}
Now my question is, due to two loops (one generates the random
vector and one determines the vector to be returned), can .Call still be
faster than pure R code (only one loop to copy vecR to vecA given condition
is met)? Or, how can I improve my c code to avoid redundant loops if any.
My
concern is if vecA is large (say of length 100 or even bigger), loops
in
C code can slow things down. Thanks for any help!
--
View this message in context:
http://r.789695.n4.nabble.com/Call-in-R-tp4080721p4080721.html
Sent from the R devel mailing list archive at Nabble.com.
__
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
--
Computational Biology
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109
Location: M1-B861
Telephone: 206 667-2793
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] round() ignores missing arguments if it is used inside another function where some arguments are missing.
I have stumbled across some behaviour in R that I really can't place,
and that makes coding a bit tricky. I know that I can work around it
when explicitly checking for missing arguments, but still...
I have two functions. I have a first function based on paste
fun1 - function(x,y){
print(missing(y))
paste(x,'X',sep=y)
}
If I try this function without specifying `y`, I get the (expected)
error message:
fun1(letters[1:6])
[1] TRUE
Error in paste(x, X, sep = y) :
argument y is missing, with no default
The second one with round :
fun2 - function(x,y){ print(missing(y)) round(x,digits=y) }
If I try this function without specifying `y`, it works unexpectedly
whereas it shouldn't :
fun2(100.1) [1] TRUE [1] 100
In my view, fun1 should definitely give the error message as well, as
it is not intended to have a default behaviour when y is missing.
Still, the round() function ignores the fact y is missing. Is this by
design, is there a check missing in round, or is something else going
on that I am overlooking?
Cheers
Joris
sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United Kingdom.1252
[2] LC_CTYPE=English_United Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
loaded via a namespace (and not attached):
[1] tools_2.14.0
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .Call in R
Because if you calculate the probability and then make uniform values,
nothing guarantees that the sum of those uniform values actually is
larger than 50,000. You only have 50% chance it is, in fact...
Cheers
Joris
On Fri, Nov 18, 2011 at 4:08 PM, Karl Forner karl.for...@gmail.com wrote:
Hi,
A probably very naive remark, but I believe that the probability of sum(
runif(1) ) = 5 is exactly 0.5. So why not just test that, and
generate the uniform values only if needed ?
Karl Forner
On Thu, Nov 17, 2011 at 6:09 PM, Raymond gw...@mail.missouri.edu wrote:
Hi R developers,
I am new to this forum and hope someone can help me with .Call in R.
Greatly appreciate any help!
Say, I have a vector called vecA of length 1, I generate a vector
called vecR with elements randomly generated from Uniform[0,1]. Both vecA
and vecR are of double type. I want to replace elements vecA by elements in
vecR only if sum of elements in vecR is greater than or equal to 5000.
Otherwise, vecR remain unchanged. This is easy to do in R, which reads
vecA-something;
vecR-runif(1);
if (sum(vecR)=5000)){
vecA-vecR;
}
Now my question is, if I am going to do the same thing in R using .Call.
How can I achieve it in a more efficient way (i.e. less computation time
compared with pure R code above.). My c code (called change_vecA.c)
using
.Call is like this:
SEXP change_vecA(SEXP vecA){
int i,vecA_len;
double sum,*res_ptr,*vecR_ptr,*vecA_ptr;
vecA_ptr=REAL(vecA);
vecA_len=length(vecA);
SEXP res_vec,vecR;
PROTECT(res_vec=allocVector(REALSXP, vec_len));
PROTECT(vecR=allocVector(REALSXP, vec_len));
res_ptr=REAL(res_vec);
vecR_ptr=REAL(vecR);
GetRNGstate();
sum=0.0;
for (i=0;ivecA_len;i++){
vecR_ptr[i]=runif(0,1);
sum+=vecR_ptr[i];
}
if (sum=5000){
/*copy vecR to the vector to be returned*/
for (i=0;ivecA_len;i++){
res_ptr[i]=vecR_ptr[i];
}
}
else{
/*copy vecA to the vector to be returned*/
for (i=0;ivecA_len;i++){
res_ptr[i]=vecA_ptr[i];
}
}
PutRNGstate();
UNPROTECT(2);
resturn(res);
}
My R wrapper function is
change_vecA-function(vecA){
dyn.load(change_vecA.so);
.Call(change_vecA,vecA);
}
Now my question is, due to two loops (one generates the random
vector and one determines the vector to be returned), can .Call still be
faster than pure R code (only one loop to copy vecR to vecA given condition
is met)? Or, how can I improve my c code to avoid redundant loops if any.
My
concern is if vecA is large (say of length 100 or even bigger), loops
in
C code can slow things down. Thanks for any help!
--
View this message in context:
http://r.789695.n4.nabble.com/Call-in-R-tp4080721p4080721.html
Sent from the R devel mailing list archive at Nabble.com.
__
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
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] round() ignores missing arguments if it is used inside another function where some arguments are missing.
On Nov 18, 2011, at 10:43 AM, Joris Meys wrote:
I have stumbled across some behaviour in R that I really can't place,
and that makes coding a bit tricky. I know that I can work around it
when explicitly checking for missing arguments, but still...
I have two functions. I have a first function based on paste
fun1 - function(x,y){
print(missing(y))
paste(x,'X',sep=y)
}
If I try this function without specifying `y`, I get the (expected)
error message:
fun1(letters[1:6])
[1] TRUE
Error in paste(x, X, sep = y) :
argument y is missing, with no default
The second one with round :
fun2 - function(x,y){ print(missing(y)) round(x,digits=y)}
If I try this function without specifying `y`, it works unexpectedly
whereas it shouldn't :
fun2(100.1)[1] TRUE[1] 100
In my view, fun1 should definitely give the error message as well, as
it is not intended to have a default behaviour when y is missing.
Still, the round() function ignores the fact y is missing. Is this by
design, is there a check missing in round, or is something else going
on that I am overlooking?
round
function (x, digits = 0) .Primitive(round)
it has a default so it is fine for digits to be missing since it will have
value 0 in that case ...
Cheers,
S
Cheers
Joris
sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United Kingdom.1252
[2] LC_CTYPE=English_United Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
loaded via a namespace (and not attached):
[1] tools_2.14.0
--
Joris Meys
Statistical consultant
Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics
tel : +32 9 264 59 87
joris.m...@ugent.be
---
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
__
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] round() ignores missing arguments if it is used inside another function where some arguments are missing.
On Fri, 2011-11-18 at 16:43 +0100, Joris Meys wrote:
I have stumbled across some behaviour in R that I really can't place,
and that makes coding a bit tricky. I know that I can work around it
when explicitly checking for missing arguments, but still...
I have two functions. I have a first function based on paste
fun1 - function(x,y){
print(missing(y))
paste(x,'X',sep=y)
}
If I try this function without specifying `y`, I get the (expected)
error message:
fun1(letters[1:6])
[1] TRUE
Error in paste(x, X, sep = y) :
argument y is missing, with no default
The second one with round :
fun2 - function(x,y){ print(missing(y)) round(x,digits=y)}
If I try this function without specifying `y`, it works unexpectedly
whereas it shouldn't :
fun2(100.1)[1] TRUE[1] 100
round() is implemented as:
round
function (x, digits = 0) .Primitive(round)
using the .Primitive means of calling C code. `?.Primitve` refers you to
the R Internals manual, which basically states that how the compiled
functions should be called and number of arguments etc is stored in a
table. This table is given here:
http://svn.r-project.org/R/trunk/src/main/names.c
The relevant part of which is:
/* printnamec-entry offset evalarity pp-kind precedence
rightassoc
* ---- -- - --- --
--*/
/* Mathematical Functions */
/* primitives: these are group generic and so need to eval args (possibly
internally) */
{round, do_Math2, 10001, 0, -1, {PP_FUNCALL, PREC_FN,
0}},
the eval column indicates features of how arguments are evaluated and
what have you. A value of 0 equates to 000 and the last 0 indicates
whether arguments are to be evaluated with 0 indicating no evaluation
and 1 evaluation.
round is indicated to not evaluate its arguments. I don't follow the C
code well enough to know if it should be catching the missing argument
further on - it must be because it is falling back to the default, but
the above explains that the not evaluating arguments is intended.
G
In my view, fun1 should definitely give the error message as well, as
it is not intended to have a default behaviour when y is missing.
Still, the round() function ignores the fact y is missing. Is this by
design, is there a check missing in round, or is something else going
on that I am overlooking?
Cheers
Joris
sessionInfo()
R version 2.14.0 (2011-10-31)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United Kingdom.1252
[2] LC_CTYPE=English_United Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods
[7] base
loaded via a namespace (and not attached):
[1] tools_2.14.0
--
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Dr. Gavin Simpson [t] +44 (0)20 7679 0522
ECRC, UCL Geography, [f] +44 (0)20 7679 0565
Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-free packages in CRAN
Jordi, I think you are misunderstanding a few things here. First, R doesn't endorse anything - it is a program, it does what you tell it to do. Second, whoever runs R-forge doesn't endorse the packages hosted on it, either. It's just an infrastructure, with no claim about endorsement of the package hosted there (just like github, sourceforge etc. don't say anything about the software hosted there). Third, LGPL is a GNU license and also a open source license (in fact far more free than GPL - see Software Licenses on GNU pages). If anyone shared your interpretation, there would be no GNU/Linux since glibc is LGPL licensed and so are parts of gcc (and hence according to your argument neither can be a GNU project). Note that a lot of GNU libraries are licensed under LGPL. The fact that you personally may not like licenses other than GPL is completely irrelevant. There are many other open source licenses and there is nothing wrong with using them. It is entirely up to the developer to decide how they feel about their code - whether they want it to be restricted by GPL or more free with some other open source license. Instead of forcing our views on users, we are empowering them to filter packages according to the license they feel comfortable with. As for giving access to proprietary software - I think the argument is the exact opposite of what you are saying. By having the ability to leverage functionality (be it proprietary) that doesn't exist in R/Octave/.., you are making the free software stronger. If people realize that it is a desirable functionality, then they will create a free alternative since only a part of the community can use it. However, if such link did not exist, then users may choose to abandon the free software and use a commercial product instead (AFAIR in your example it was Matlab that has a link to Mosek). That would also weaken the possibility of a free alternative for the package. Cheers, Simon On Nov 17, 2011, at 1:06 PM, Jordi Gutiérrez Hermoso wrote: Hello. This is in relation to the discussion below: http://sourceforge.net/mailarchive/forum.php?thread_name=CAPHS2gwmxJGF9Cy8%3DSEGasQcVRg_Lqu-ndCdVhO-r1LJsRQGuA%40mail.gmail.comforum_name=octave-dev If this is the wrong place to discuss this issue, I would be thankful for a redirection to the appropriate forum. As Henrik says, R or some organisation that acts in R's name, has accepted his non-free plugin: http://rmosek.r-forge.r-project.org/ Yes, it is non-free, even if it's LGPL, because it's linking to both R and MOSEK, which is a GPL+proprietary whole. There is no actual GPL violation because it's avoiding binary distribution. However, I'm concerned with the overall message this sends. I was under the impression that R is part of the GNU project, and as an Octave developer, I have thought of R as being a fellow GNU-in-arms comrade. I have proudly recommended R to people, both on technical merits and sound philosophical principles. I don't see R as a competitor to Octave, but as an esteemed colleague. I am, however, a little concerned that R seems to be endorsing a project that is in turn endorsing non-free software. This seems to be against what an important aspect of what GNU should do: promote free software and discourage the proliferation of non-free software. While you may argue that the plugin is free, it is absolutely useless without the non-free package, so R is ultimately recommending its users to use a non-free package. This seems like a problem to me. I see several possible solutions: 1) R could stop calling itself part of the GNU project. This would make me very sad, and I hope R doesn't take this route. As I said, I'm proud to be part of the same organisation that R is currently part of. 2) R could stop endorsing R-Forge. This obviously seems like a much worse alternative. 3) R-Forge could remove the offending package. I also hope it doesn't come to this. 4) The authors of MOSEK could make it free. Note: free does not mean money is forbidden. One option for MOSEK could be to dual-license it: MOSEK is GPL, but anyone who wants to lock it up has to pay for alternative license terms. FFTW and Qt are two prominent free commercial packages that have followed this route. I really would much prefer (4), or if it can't be achieved, (3). But I encourage the R users and contributors to support the aims of the GNU project and to stand together with the Octave community in this regard. Thank you for your time, - Jordi G. H. __ 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] round() ignores missing arguments if it is used inside another function where some arguments are missing.
You can also see the odd behavior without wrapping round in another function: round(100.1, digits=) [1] 100 On 11/18/2011 10:19 AM, Joris Meys wrote: On Fri, Nov 18, 2011 at 5:10 PM, Gavin Simpsongavin.simp...@ucl.ac.uk wrote: round is indicated to not evaluate its arguments. I don't follow the C code well enough to know if it should be catching the missing argument further on - it must be because it is falling back to the default, but the above explains that the not evaluating arguments is intended. G So if I understand it right, the y argument is not evaluated in the fun2 function but deeper in the C code. that explains the lack of the error message, thanks! I keep on learning every day. Cheers Joris __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-free packages in CRAN
2011/11/18 Simon Urbanek simon.urba...@r-project.org: I think you are misunderstanding a few things here. First, R doesn't endorse anything - it is a program, It is also an organisation and that organisation has a website. Someone is responsible for the contents of that website and the views espoused in it. Saying that R was just a shorthand for the organisation built around R Software isn't amoral. Software is deeply related to what we people can and should be able to do. People are responsible for what their software does. it does what you tell it to do. Second, whoever runs R-forge doesn't endorse the packages hosted on it, either. It's just an infrastructure, with no claim about endorsement of the package hosted there The R organisation is referring to that website, it's hosted at the same top-level domain, it looks like the R organisation is endorsing R Forge, and R-Forge is endorsing non-free software. Third, LGPL is a GNU license and also a open source license I'm a little sad by members of GNU using the term open source. More importantly than open source, it's a free license. And this is besides the point. The wrapper is LGPL, but it's a wrapper for a non-free library. If anyone shared your interpretation, there would be no GNU/Linux since glibc is LGPL licensed and so are parts of gcc (and hence according to your argument neither can be a GNU project). Note that a lot of GNU libraries are licensed under LGPL. This is a strawman. I'm not saying the LGPL is non-free. I'm saying the combination of that wrapper with MOSEK is non-free. The fact that you personally may not like licenses other than GPL This is another strawman. I didn't say I disliked licenses other than the GPL. I said R shouldn't endorse a project that endorses non-free software. As for giving access to proprietary software - I think the argument is the exact opposite of what you are saying. By having the ability to leverage functionality (be it proprietary) that doesn't exist in R/Octave/.., you are making the free software stronger. I don't see how MOSEK is making free software stronger. It's not encouraging the usage of more free software. It's encouraging the use of MOSEK. MOSEK should not be endorsed by an organisation that is supposed to promote free software. If these really are your views and they're representative of the R project, then the solution seems to be to make R stop calling itself part of the GNU project. I hope it doesn't do this. - Jordi G. H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-free packages in R-Forge
I'm sorry about the tone of my previous email. Let me try again in a cleaner way. The problem is: R or the organisation behind R via its infrastructure seems to be endorsing R-Forge, and R-Forge is hosting at least one project whose sole purpose is to link R with non-free software. This looks like endorsement of non-free software, which is contrary to the aims of the GNU project, of which R today claims to be a part. There are several solutions, but the only workable ones I see are to either sever ties with the GNU project, clearly remove the endorsement of the non-free project, or to make the non-free project free. Of these, it is my sincere hope that the last one happens. That is all. - Jordi G. H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-free packages in R-Forge
On Nov 18, 2011, at 1:00 PM, Jordi Gutiérrez Hermoso wrote: I'm sorry about the tone of my previous email. Let me try again in a cleaner way. The problem is: R or the organisation behind R via its infrastructure seems to be endorsing R-Forge, and R-Forge is hosting at least one project whose sole purpose is to link R with non-free software. This looks like endorsement of non-free software, which is contrary to the aims of the GNU project, of which R today claims to be a part. Are you aware that R has two other major trunks besides the Linux one? Those of us with Mac or Windows hardware/software devices might be threatened with discontinuation of our access to R if your logic prevails. There are several solutions, but the only workable ones I see are to either sever ties with the GNU project, clearly remove the endorsement of the non-free project, or to make the non-free project free. Of these, it is my sincere hope that the last one happens. This entire argument seems quasi-religious. You seem to be claiming that there is a non-free moral and legal sinfulness that is passed by way of links on websites. There do not seem to be any boundaries to this process that are discernable from your writings. That is all. - Jordi G. H. David Winsemius, MD West Hartford, CT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-free packages in R-Forge
You are, of course, missing the obvious solution, which is to do nothing. The endorsement of a non-free project seems to me to reside only in your imagination. The primary product produced by The R Project for Statistical Computing is the statistical software environment R, which is released under the GPL. It is free software under anyone's definition. One can safely infer that members of the R Project clearly endorse the goals of the GNU Project (as you can see, for example, from the fact that the only hyperlinks from the What is R? web page point to FSF or GNU). I think that there is no chance that members of the R project would voluntarily sever its ties with GNU over this issue. It's also not clear that there is any formal process for something becoming a GNU project. If there were, you could then go to the GNU organization or to FSF and convince them to take some action to force the R project to stop calling itself a GNU project. (I strongly suspect that there are neither copyright nor trademark nor other enforceable agreements to cause anything to happen in that regard.) Now, the web site for the R project does point from its related projects page to R-Forge as a framework where packages that work with R can be developed. It also displays prominent links to CRAN and to Bioconductor as locations where users can obtain R packages. In that sense, I would be willing to agree that the R project endorses R-Rorge, CRAN, and Bioconductor. However, I strongly object to the idea that this includes an endorsement of all (or even *any*) of the packages developed or hosted on those three other sites. There are plenty of R packages in all of those locations that are provided under licenses other than GPL, LGPL, or PAL. Some of those licenses are clearly non-free (in both the liberty and dollar senses). For example, I use the mclust package (available from CRAN) all the time. The license for this package requires an annual payment of a licensing fee for non-academic use, which limits modification and redistribution. I have developed my own packages that depend on mclust. The code that I wrote is available under the Perl Artistic License. But if anyone wants to use my pacakge, they still have to conform to the terms of use defined by the license for mclust, on which my package depends. I don't think that the University of Washington shoudl be prevented from specifying the license terms it wants for mclust. And I don't think users (academic or otherwise) would get any beenfits if mclust was prevented from being made available through CRAN. As far as I can tell, the situation with mclust is directly analogous to the situation you are complaining about with MOSEK being hosted at R-Forge. Here's my suggestion. Stop trying to prevent users who want to talk to MOSEK from R from getting a package that will accomplish that task. Your real problem seems to be that MOSEK is not free. So do what Stallman did when he objected to the fact that UNIX was not free. (Or MOTIF. Or lots of other stuff.) Get some developers together, work in a clean environment where they won't violate any copyright in the existing code, and develop a free alternative. Kevin On 11/18/2011 12:00 PM, Jordi Gutiérrez Hermoso wrote: I'm sorry about the tone of my previous email. Let me try again in a cleaner way. The problem is: R or the organisation behind R via its infrastructure seems to be endorsing R-Forge, and R-Forge is hosting at least one project whose sole purpose is to link R with non-free software. This looks like endorsement of non-free software, which is contrary to the aims of the GNU project, of which R today claims to be a part. There are several solutions, but the only workable ones I see are to either sever ties with the GNU project, clearly remove the endorsement of the non-free project, or to make the non-free project free. Of these, it is my sincere hope that the last one happens. That is all. - Jordi G. H. __ 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] DSC?
Could whoever is in charge of the next DSC contact me? We might be able to co-host it with interface in Houston, May 16-18 2012. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Windows binaries: Version and revision strings show (2006-00-00 r00000)
FYI, for the last few revision the version string for both R v2.14.0 patched and R devel are not correct for the Windows binaries. This is what R --version and sessionInfo() report since a couple of days: R version 2.14.0 Patched (2006-00-00 r0) R Under development (unstable) (2006-00-00 r0) Also, r0 is listed as the revision on: http://cran.r-project.org/bin/windows/base/rdevel.html http://cran.r-project.org/bin/windows/base/rpatched.html /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-free packages in CRAN
2011/11/18 Jordi Gutiérrez Hermoso jord...@octave.org: I don't see how MOSEK is making free software stronger. It's not encouraging the usage of more free software. It's encouraging the use of MOSEK. MOSEK should not be endorsed by an organisation that is supposed to promote free software. If these really are your views and they're representative of the R project, then the solution seems to be to make R stop calling itself part of the GNU project. I hope it doesn't do this. - Jordi G. H. I'm not going into the discussion about which license represents what. I hate politics and ideological discussions because of all the blabla. I'm a statistician. I work with facts. Fact : Simon is not the R-project, the R-core or the R community. He's one guy, and a pretty smart one that is. Fact : At my department several people use R only because they have access to non-GPL programs through R: because they can load Excel and SPSS files if they have to, connect to SQLServer and Access, ... Fact : They often don't use Octave for exactly the same reason: They don't have access to the tools they need. They're using Matlab instead. We do have SPlus on the servers too. Guess how many people are using that... Fact : I get paid for statistical advice. I pay for a hammer. I pay for a bike. If I have to pay for a tool I need on my computer, I pay for it. If there's a free alternative that can get me as far, I use that one and support their community with a gift if I care enough about the tool. Which reminds me... Fact : If I see too many quasi-religious statements, tool goes out and I leave the building. You're not doing your cause a favor here. Cheers Joris Being religious about free software never helped the cause. And by __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Mathematical Modelling, Statistics and Bio-Informatics tel : +32 9 264 59 87 joris.m...@ugent.be --- Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] round() ignores missing arguments if it is used inside another function where some arguments are missing.
On Fri, Nov 18, 2011 at 9:34 AM, Kevin R. Coombes kevin.r.coom...@gmail.com wrote: You can also see the odd behavior without wrapping round in another function: round(100.1, digits=) [1] 100 Hmm... is there a reason for why the parser accepts that construct? Some example: parse(text=f(a=)) expression(f(a=)) parse(text=f[a=]) expression(f[a=]) parse(text=(a=)) Error in parse.default(text = (a=)) : text:1:4: unexpected ')' 1: (a=) /Henrik On 11/18/2011 10:19 AM, Joris Meys wrote: On Fri, Nov 18, 2011 at 5:10 PM, Gavin Simpsongavin.simp...@ucl.ac.uk wrote: round is indicated to not evaluate its arguments. I don't follow the C code well enough to know if it should be catching the missing argument further on - it must be because it is falling back to the default, but the above explains that the not evaluating arguments is intended. G So if I understand it right, the y argument is not evaluated in the fun2 function but deeper in the C code. that explains the lack of the error message, thanks! I keep on learning every day. Cheers Joris __ 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] Windows binaries: Version and revision strings show (2006-00-00 r00000)
Which 'Windows binaries'? Mine are correct, so you need to take this up with the builder (named on CRAN). No one else on R-devel can do anything about this. On Fri, 18 Nov 2011, Henrik Bengtsson wrote: FYI, for the last few revision the version string for both R v2.14.0 patched and R devel are not correct for the Windows binaries. This is what R --version and sessionInfo() report since a couple of days: R version 2.14.0 Patched (2006-00-00 r0) R Under development (unstable) (2006-00-00 r0) Also, r0 is listed as the revision on: http://cran.r-project.org/bin/windows/base/rdevel.html http://cran.r-project.org/bin/windows/base/rpatched.html /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- 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
