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
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 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=)") : :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 Simpson >> 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] Non-free packages in CRAN
2011/11/18 Jordi Gutiérrez Hermoso : > > 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
[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
[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
Re: [Rd] Non-free packages in R-Forge
Jordi: Why do you want to reduce demand for Octave by forcing people who want to link to a commercial product to abandon Octave? Are you familiar with Shapiro and Varian (1998) Information Rules: A Strategic Guide to the Network Economy (Harvard Bus. Sch. Pr.)? Varian is now the Chief Economist at Google, and his ideas seem to have contributed substantially to their success. The book explains that if you want to increase the market for your product, you need to make it as easy as possible for potential users to use (for as many different purposes). I've used Matlab, and I want to start using Octave. If I can connect from only one of these products to some third party software that I'd like also to use, that's a reason to use the more flexible product. Spencer On 11/18/2011 10:32 AM, Jordi Gutiérrez Hermoso wrote: Let me give a little more context of why this is important. As you can read in this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=CAPHS2gwmxJGF9Cy8%3DSEGasQcVRg_Lqu- ndCdVhO-r1LJsRQGuA%40mail.gmail.com&forum_name=octave-dev The author of MOSEK basically created a non-free library and wants to link it to both Octave and R. Normally this would be a GPL violation; however the author of MOSEK has worked around the GPL by making a wrapper and making the user do the linking, effectively neutering the copyleft of the GPL (and yes, the GPL is not nice, and this non-niceness of the GPL is a feature). I am trying to reject this in Octave. We do not want to condone the proliferation of non-free software. Instead, I invite the makers of MOSEK to make the library free. However, the author has pointed out that R has accepted his plugin, why can't Octave? And this is why I appeal to the GNUness of R, if it still has it. If Octave and R are part of the same organisation, we have to stand together on this, and together pressure the maker of MOSEK to release MOSEK as free software and stop trying to work around the GPL with wrappers and avoiding binary distribution. I am inviting R to work together with Octave on this. If we are both using the GPL and both part of GNU, what good is it if the GPL can be worked around and if we don't both stand for the same principles? This isn't about prohibiting R from running on Windows or Mac (Octave also runs on both because it's the only way to reach those users), nor about meaningless ideology, but about bringing about a very practical result: more free software for the community, more source for everyone. So, please, users and developers and overseers of R, work with us. If we are on the same team, can we work towards the same goals? - 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] 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
Re: [Rd] Non-free packages in R-Forge
Let me give a little more context of why this is important. As you can read in this thread: http://sourceforge.net/mailarchive/forum.php?thread_name=CAPHS2gwmxJGF9Cy8%3DSEGasQcVRg_Lqu- ndCdVhO-r1LJsRQGuA%40mail.gmail.com&forum_name=octave-dev The author of MOSEK basically created a non-free library and wants to link it to both Octave and R. Normally this would be a GPL violation; however the author of MOSEK has worked around the GPL by making a wrapper and making the user do the linking, effectively neutering the copyleft of the GPL (and yes, the GPL is not nice, and this non-niceness of the GPL is a feature). I am trying to reject this in Octave. We do not want to condone the proliferation of non-free software. Instead, I invite the makers of MOSEK to make the library free. However, the author has pointed out that R has accepted his plugin, why can't Octave? And this is why I appeal to the GNUness of R, if it still has it. If Octave and R are part of the same organisation, we have to stand together on this, and together pressure the maker of MOSEK to release MOSEK as free software and stop trying to work around the GPL with wrappers and avoiding binary distribution. I am inviting R to work together with Octave on this. If we are both using the GPL and both part of GNU, what good is it if the GPL can be worked around and if we don't both stand for the same principles? This isn't about prohibiting R from running on Windows or Mac (Octave also runs on both because it's the only way to reach those users), nor about meaningless ideology, but about bringing about a very practical result: more free software for the community, more source for everyone. So, please, users and developers and overseers of R, work with us. If we are on the same team, can we work towards the same goals? - 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 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. It seems to me that you have a rather RMS-like mindset, as opposed to Simon's more pragmatic approach, which frankly, as a FOSS supporter and useR of R for 10 years, I prefer. If you feel so strongly about your position, then take it up with the FSF and pursue it there! This is degenerating into a philosophical debate, based on your opinion alone, which is not going to be resolved in this forum. Move on. Marc Schwartz __ 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
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 CRAN
2011/11/18 Simon Urbanek : > 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] 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 Simpson 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] .Call in R
Yes indeed. My mistake. On Fri, Nov 18, 2011 at 4:45 PM, Joris Meys wrote: > 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 > 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 > 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;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;i >> res_ptr[i]=vecR_ptr[i]; > >>} > >> } > >> else{ > >>/*copy vecA to the vector to be returned*/ > >>for (i=0;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 > [[alternative HTML version deleted]] __ 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 5:10 PM, Gavin Simpson 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 -- 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] 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.com&forum_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/listin
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] 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] .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 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 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;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;i> res_ptr[i]=vecR_ptr[i]; >> } >> } >> else{ >> /*copy vecA to the vector to be returned*/ >> for (i=0;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
[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
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, Raymond 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;i=5000){ /*copy vecR to the vector to be returned*/ for (i=0;ihttp://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
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 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;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;i res_ptr[i]=vecR_ptr[i]; >} > } > else{ >/*copy vecA to the vector to be returned*/ >for (i=0;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
[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] 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
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