Re: [Rd] Mentor for GSOC '10: Symbolic Regression in R
Thank you for your comments. I was indeed looking to use Rcpp for integration for the C++ portions where compiled code would have performance benefits while sticking to R code elsewhere. I've had some previous bad experiences with Swig for interfacing C code with Python code but it looks like Rcpp is much more friendlier. And thanks for the support! Chillu On Thu, Mar 4, 2010 at 1:18 PM, Romain Francois rom...@r-enthusiasts.comwrote: Hello, I can't offer to mentor because I don't know anything about symbolic regression. However, since you have R/C++ as the skills requirements, I would strongly recommend that you use Rcpp as an enabling technology, so that you can be productive on C++/symbolic regressions as opposed to manage R API quirks. Also, you can count on some implicit support through Rcpp mailing list. https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel Good luck finding a mentor, this sounds like a cool project. Romain On 03/03/2010 08:17 PM, Chidambaram Annamalai wrote: Hi all, I am looking to extend the regression and data analysis capabilities of R through Symbolic Regression that can potentially find implicit equation relationships in the input data. You can find my project proposal at: http://rwiki.sciviews.org/doku.php?id=developers:projects:gsoc2010:syrfr I am looking for a mentor to guide me through the summer on the project under the Google Summer Of Code program (GSOC 2010) with relevant experience in Symbolic Regression or Genetic Programming in general. Chillu -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/OIXN : raster images and RImageJ |- http://tr.im/OcQe : Rcpp 0.7.7 `- http://tr.im/O1wO : highlight 0.1-5 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] dots for sample -- implicitGeneric
CB == Claudia Beleites cbelei...@units.it on Sun, 28 Feb 2010 19:31:42 +0100 writes: CB Dear R-Developers, CB could 'sample' gain a ... argument? As you may know, adding '...' also has drawbacks, most notably that you lose automatic checking of correctly specified argument names (when the function is called). OTOH, R has now (since 2.9.0) had sample.int() as a fast and robust alternative. CB As a convenience function, I added a sample Method to my hyperSpec CB class. This function however has a flag indicating whether the results CB should be returned directly as a hyperSpec object or rather as indices CB that give a random sample. CB For the moment, I use SetGeneric to add the dots argument, but this of CB course gives a warning that the base function sample is overwritten (and CB my colleagues are almost as scared of warnings as of errors...) and they are not the only ones ... For a while now, we have (in 'methods') the possibility to make functions implicit generic, see ?implicitGeneric , exactly for purposes like (I think) you have here ( and notably to ensure that if *different* packages do this, they get compatible versions of the generic, and hence all the different method definitions will be attached to the same generic ) Namely, you'd want to define S4 methods (and hence make 'sample' an S4 generic) with new arguments in your package. So, yes, I now have added 'sample' to the list of functions that we make implicitGeneric in R. -- Get a version of R-devel, (svn revision = 51202) and try the following: setClass(foo, contains=vector) [1] foo setMethod(sample, foo, function(x, size, myArg, ...) sprintf(sample(foo, myArg=%s)\n,myArg)) Restoring the implicit generic function for ‘sample’ from package ‘base’ into package ‘.GlobalEnv’; the generic differs from the default conversion (Formal arguments differ: (x, size, replace, prob), (x, size, replace, prob, ...)) Creating a new generic function for sample in .GlobalEnv [1] sample sample(new(foo), myArg = 64) [1] sample(foo, myArg=64)\n Best regards, Martin Maechler, ETH Zurich CB Thanks, CB Claudia CB -- CB Claudia Beleites CB Dipartimento dei Materiali e delle Risorse Naturali CB Università degli Studi di Trieste CB Via Valerio 2 CB I-34127 Trieste CB ITALY __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R CMD check data reading
Hello, I have a test script that works fine when I copy and paste it into a R session. I have the script in the tests directory of the package. But when I do R CMD check on the package it runs all the tests OK on my first dataset in the script, then I make a call to load() for the second dataset, and it gives Error in readChar(con, 5L, useBytes = TRUE) : cannot open the connection Calls: load - load.default - readChar Execution halted At least I think that's where it is happening. None of my cat() statements in the script go to the screen, so it's only a guess based on the Calls: in the above message. How could the script work when copied and pasted into a session, but fail under R CMD check ? I'm out of ideas on this one. - Dario Strbenac Research Assistant Cancer Epigenetics Garvan Institute of Medical Research Darlinghurst NSW 2010 Australia __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] (PR#14226) -- Re: libgfortran misplaced in Mac OS X R install (PR#14226)
I am the guy who compiles the OpenMx binaries. We would be delighted to place our package on CRAN, once the project is stable enough so that we are comfortable releasing it to the larger public. Let's try to track down where I made a mistake. Our Makevars.in file contains the line: PKG_LIBS=$(FLIBS) $(BLAS_LIBS) $(LAPACK_LIBS) In addition, on the build machine I noticed that a copy of libgfortran.2.dylib exists at /usr/local/lib. I believe the Xcode install placed a copy of it there. To create the binary release, I run R CMD INSTALL --build. The beta test users install the package using the following script: http://openmx.psyc.virginia.edu/getOpenMx.R. On Wed, Mar 3, 2010 at 9:48 AM, Tim Brick tbr...@virginia.edu wrote: From: Simon Urbanek simon.urba...@r-project.org Date: March 3, 2010 8:32:52 AM MST To: tbr...@virginia.edu Cc: r-de...@stat.math.ethz.ch, r-b...@r-project.org Subject: Re: [Rd] libgfortran misplaced in Mac OS X R install (PR#14226) This is not an R bug so please don't abuse R-bugs. It is likely a bug in the way OpenMx binaries are distributed by someone (you didn't even say where you got them from) - OpenMx is not even on CRAN so take that to whoever gave you the binaries. On CRAN we use the correct paths. Cheers, Simon On Mar 2, 2010, at 11:45 , tbr...@virginia.edu wrote: Full_Name: Timothy Brick Version: 2.10 OS: Mac OS X (seen on both 10.6 and 10.5) Submission from: (NULL) (63.255.24.5) When using install.packages in R on Mac OS X, packages that require gfortran throws an error (Example below from installation of OpenMx package): Loading required package: OpenMx Error in dyn.load(file, DLLpath = DLLpath, ...) : unable to load shared library '/Library/Frameworks/R.framework/Resources/library/OpenMx/libs/i386/OpenMx.so': dlopen(/Library/Frameworks/R.framework/Resources/library/OpenMx/libs/i386/OpenMx.so, 6): Library not loaded: /usr/local/lib/libgfortran.2.dylib Referenced from: /Library/Frameworks/R.framework/Resources/library/OpenMx/libs/i386/OpenMx.so Reason: image not found libgfortran.2.dylib does exist, but in /Library/Frameworks/R.framework/Versions/2.10/Resouces/lib/libgfortran.2.dylib (or /2.9/, depending on version installed). A workaround at present involves creating a symbolic link from the above file to /usr/local/lib/libgfortran.2.dylib, however this requires sudo access and is confusing for novice users. There is more discussion of this bug as it relates to OpenMx at: http://openmx.psyc.virginia.edu/thread/316 Posts on other forums indicate a similar issue with other packages including vegan and lme4: http://r-forge.r-project.org/forum/forum.php?thread_id=728forum_id=194 https://stat.ethz.ch/pipermail/r-sig-mac/2009-May/006210.html Those are very old posts and those were temporary issues in the CRAN build system that have been promptly resolved. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#14226) -- Re: libgfortran misplaced in Mac OS X R install (PR#14226)
Hi Michael, On Mar 3, 2010, at 12:01 , Michael Spiegel wrote: I am the guy who compiles the OpenMx binaries. We would be delighted to place our package on CRAN, once the project is stable enough so that we are comfortable releasing it to the larger public. Let's try to track down where I made a mistake. Our Makevars.in file contains the line: PKG_LIBS=$(FLIBS) $(BLAS_LIBS) $(LAPACK_LIBS) In addition, on the build machine I noticed that a copy of libgfortran.2.dylib exists at /usr/local/lib. I believe the Xcode install placed a copy of it there. No, it is part of the GNU Fortran installation. Anything you compile with a Fortran requires that you have that Fortran installed at run time, because Fortran uses its own run-time libraries (if the Fortran you compiled with used dynamic libraries). This implies that if you distribute your package you have to tell users to install the same Fortran you used to compile it. However, unlike other unices Mac users don't necessarily have development tools installed, so on CRAN we make an effort to modify the binaries such that they work even without the tools they have been compiled with. There are several possible approaches, but since R itself already uses the same Fortran, we ship a copy of the Fortran libraries inside R and modify packages such that they use it instead of the one from dev tools (see below for details). To create the binary release, I run R CMD INSTALL --build. That is not sufficient to create a binary of your package, because it contains a configure script (this is unrelated to the above - see R- admin 2.6). What you want to use is something like this (assuming R 2.10.1 Leopard build and Fortran from CRAN): R --arch=i386 CMD INSTALL OpenMx_0.2.9-1147.tar.gz R --arch=x86_64 CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz R --arch=ppc CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz cd /Library/Frameworks/R.framework/Versions/2.10/Resources/library # fix the Fortran paths to point to R 2.10 instead for lib in `ls OpenMx/libs/*/*.so`; do install_name_tool -change /usr/local/lib/libgfortran.2.dylib \ /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib \ $lib done # change permissions for distribution sudo chown -Rh root:admin OpenMx sudo chmod -R g+w OpenMx # pack it up tar fvcz ~/OpenMx_0.2.9-1147.tgz OpenMx You can check that you have the correct paths using otool -L: ginaz:library$ otool -L OpenMx/libs/*/*.so OpenMx/libs/i386/OpenMx.so: OpenMx.so (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRblas.dylib (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRlapack.dylib (compatibility version 2.10.0, current version 2.10.1) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libR.dylib (compatibility version 2.10.0, current version 2.10.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation (compatibility version 150.0.0, current version 476.19.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 242.0.0) OpenMx/libs/ppc/OpenMx.so: OpenMx.so (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRblas.dylib (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRlapack.dylib (compatibility version 2.10.0, current version 2.10.1) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libR.dylib (compatibility version 2.10.0, current version 2.10.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation (compatibility version 150.0.0, current version 476.19.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 242.0.0) OpenMx/libs/x86_64/OpenMx.so: OpenMx.so (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRblas.dylib (compatibility version 0.0.0, current version 0.0.0)
Re: [Rd] dots for sample -- implicitGeneric
Dear Martin, Martin Maechler wrote: CB == Claudia Beleites cbelei...@units.it on Sun, 28 Feb 2010 19:31:42 +0100 writes: CB Dear R-Developers, CB could 'sample' gain a ... argument? As you may know, adding '...' also has drawbacks, most notably that you lose automatic checking of correctly specified argument names (when the function is called). Yes, I'm aware of that - and was silently wondering whether one could do something against it (besides having nicely behaved functions without ... at the end of the call chain). OTOH, R has now (since 2.9.0) had sample.int() as a fast and robust alternative. Yes. I had a quick thought whether I should do sample (my.object) = new object with a subset of my.object's spectra and sample.int (my.object) = indices for use with my.object I decided that this is bad, as I would expect that a function somefun.int does *expect* rather than *return* the integer. The other thought was to have an additional function isample that returns indices. Which after rethinking seems the right thing to do. However this doesn't solve the implicitGeneric problem: if the object is returned I'd like to allow users to pass short messages that end up in the object's logbook. But this can easily be postponed until R 2.11 is released and sample has the implicit generic also for normal users (= my colleagues who already complain if I ask them to update their R to the official release). CB As a convenience function, I added a sample Method to my hyperSpec CB class. This function however has a flag indicating whether the results CB should be returned directly as a hyperSpec object or rather as indices CB that give a random sample. CB For the moment, I use SetGeneric to add the dots argument, but this of CB course gives a warning that the base function sample is overwritten (and CB my colleagues are almost as scared of warnings as of errors...) and they are not the only ones ... For a while now, we have (in 'methods') the possibility to make functions implicit generic, see ?implicitGeneric , exactly for purposes like (I think) you have here ( and notably to ensure that if *different* packages do this, they get compatible versions of the generic, and hence all the different method definitions will be attached to the same generic ) Yes, thank you - that's what I really wanted! I'll do my homework and reread the chaper in Chambers' book. Namely, you'd want to define S4 methods (and hence make 'sample' an S4 generic) with new arguments in your package. Exactly. So, yes, I now have added 'sample' to the list of functions that we make implicitGeneric in R. Thanks a lot. -- Get a version of R-devel, (svn revision = 51202) and try the following: setClass(foo, contains=vector) [1] foo setMethod(sample, foo, function(x, size, myArg, ...) sprintf(sample(foo, myArg=%s)\n,myArg)) Restoring the implicit generic function for ‘sample’ from package ‘base’ into package ‘.GlobalEnv’; the generic differs from the default conversion (Formal arguments differ: (x, size, replace, prob), (x, size, replace, prob, ...)) Creating a new generic function for sample in .GlobalEnv [1] sample sample(new(foo), myArg = 64) [1] sample(foo, myArg=64)\n Wonderful. Works like a charm. Thanks a lot. Thanks for your kind help, Claudia Best regards, Martin Maechler, ETH Zurich CB Thanks, CB Claudia CB -- CB Claudia Beleites CB Dipartimento dei Materiali e delle Risorse Naturali CB Università degli Studi di Trieste CB Via Valerio 2 CB I-34127 Trieste CB ITALY __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Claudia Beleites Dipartimento dei Materiali e delle Risorse Naturali Università degli Studi di Trieste Via Alfonso Valerio 6/a I-34127 Trieste phone: +39 0 40 5 58-37 68 email: cbelei...@units.it __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rmpi on CentOS (64bit)
On Mar 4, 2010, at 1:24 AM, Patrick Connolly wrote: On Wed, 03-Mar-2010 at 01:46PM -0600, Marc Schwartz wrote: | Patrick, just as an FYI, I did not see which variant of CentOS you | are using, but: Apologies. I didn't mention it's 5.4 No problem. | CentOS 4, which is based upon RHEL 4, is in turn based upon Fedora | Core 3 (2004). | CentOS 5, which is based upon RHEL 5, is in turn based upon Fedora | Core 6 (2006). | So to reinforce, there is a substantial and intentional lag between | RHEL/CentOS and Fedora. Recall that RHEL and CentOS are targeted | for stable server use, whereas Fedora is a bleeding edge distro. Yes. For that reason, I wished to get Rmpi working on CentOS. I use Fedora 11 at home and I'm a bit put off by the 300-500 Mb of updates most weeks. It's nice using the new stuff, but those updates periodically screw up what had been working well. I wouldn't want that on a production machine. Looks as though I'll have to do so anyway. My Linux skills aren't up to sorting out this CentOS lot, and I should at least get it started: it's likely there's not much difference between F11 and F12 for this task. This could well be a case where Debian would be the easiest way to go, but I couldn't convince the IT people to go down such a new track. Ours is very much an rpm site. In any case, my only Debian-type experience is with Mepis (where I got Rmpi working in 20 minutes, but I don't think that makes me a Debian pro). Thanks for the hints. BTW, just as happenstance this morning, I found the following blog posting, that may or may not be of help to you for Rmpi on Fedora: http://www.r-bloggers.com/r-tips-installing-rmpi-on-fedora-linux/ Notwithstanding the IT people issues, you could perhaps consider Ubuntu LTS, which provides a hybrid-ish approach of having a fairly up to date desktop Linux distro with longer term post-release support. Moving to a Debian based distro of course also avails you of the significant work that folks like Dirk have put in place to make most CRAN packages easily available via apt. There was a similar hybrid attempt for Fedora a few years ago, called Fedora Legacy, but it was effectively DOA. There were folks who wanted and argued for longer post release support, to avoid the frequent release update cycle. Not surprisingly, with the exception of a core group, the majority of those who wanted it were not willing to provide the substantial voluntary resources to actually make it successful. Not to mention, it was anathema to Fedora's raison d'etre and there were heated discussions on the Fedora lists. F13 is scheduled for release mid-May, which means that F11 goes EOL mid-June. So you will need to think about moving any F11 based systems to F12 or F13 in the not too distant future. That's the challenge of Fedora's life cycle, with twice per year major releases, so one has to make an informed decision as to the willingness to be on a fast track. It is one of the reasons that I moved to OSX a year ago, after 8 years on RH/Fedora, along with growing frustration over the poor nature of Linux hardware support from the GPU vendors (especially nVidia) at the time. As they say, the only good thing about banging your head against the wall, is that it feels so good when you stop. To contrast, RHEL has a 7 year life cycle, which of course carries over to CentOS, again reflecting server versus desktop requirements. You can see more information here: http://www.redhat.com/security/updates/errata/ So each RHEL/CentOS major release lives during roughly 14 Fedora major releases. There are also various rumors and speculations about RHEL 6, its release date and which version of Fedora it will be based upon, with some suggesting F12 or F13: http://lwn.net/Articles/364405/ http://jason.roysdon.net/2010/01/29/red-hat-enterprise-linux-6-speculation/ HTH, Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug reporting system inquiry plus a bug report related to sort
Is the bug-reporting system working okay? Two days ago, I submitted the following bug report via email to r-b...@r-project.org. I didn't see a confirmation, and it didn't see it at http://bugs.r-project.org/. Now, http://bugs.r-project.org/ seems to be down. Anyway, here's the bug report related to sort.list and sort(..., index.return = TRUE) with na.last = NA I think that both sort.list(x, na.last = NA) and sort(x, na.last = NA, index.return = TRUE)$ix give incorrect answers with na.last. With na.last, both of these return answers equivalent to sort.list(na.omit(x)), and I think they should be the equivalent of order(x, na.last=NA) as follows. x - c(1L, 6L, NA, 2L) order(x, na.last = NA) # right [1] 1 4 2 sort.list(x, na.last = NA, method = radix) # wrong, I think [1] 1 3 2 sort.list(x, na.last = NA, method = quick) # wrong [1] 1 3 2 sort(x, na.last = NA, index.return = TRUE)$ix # wrong [1] 1 3 2 I've included a patch for the radix and shell methods of sort.list. The sort and quick method of sort.list (which uses sort) look more challenging. With the patch, I get: sort.list(x, na.last = NA, method = radix) # good [1] 1 4 2 sort.list(x, na.last = NA, method = shell) # good [1] 1 4 2 sort.list(x, na.last = NA, method = quick) # still bad [1] 1 3 2 By the way, having the radix sort is great. It's really fast for factors. - Tom Tom Short Electric Power Research Institute (EPRI) sessionInfo() R version 2.10.1 (2009-12-14) i386-pc-mingw32 locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug reporting system inquiry plus a bug report related to sort
On Mar 4, 2010, at 9:29 AM, Tom Short wrote: Is the bug-reporting system working okay? Two days ago, I submitted the following bug report via email to r-b...@r-project.org. I didn't see a confirmation, and it didn't see it at http://bugs.r-project.org/. Now, http://bugs.r-project.org/ seems to be down. Anyway, here's the bug report related to sort.list and sort(..., index.return = TRUE) with na.last = NA I think that both sort.list(x, na.last = NA) and sort(x, na.last = NA, index.return = TRUE)$ix give incorrect answers with na.last. With na.last, both of these return answers equivalent to sort.list(na.omit(x)), and I think they should be the equivalent of order(x, na.last=NA) as follows. x - c(1L, 6L, NA, 2L) order(x, na.last = NA) # right [1] 1 4 2 sort.list(x, na.last = NA, method = radix) # wrong, I think [1] 1 3 2 sort.list(x, na.last = NA, method = quick) # wrong [1] 1 3 2 sort(x, na.last = NA, index.return = TRUE)$ix # wrong [1] 1 3 2 I've included a patch for the radix and shell methods of sort.list. The sort and quick method of sort.list (which uses sort) look more challenging. With the patch, I get: sort.list(x, na.last = NA, method = radix) # good [1] 1 4 2 sort.list(x, na.last = NA, method = shell) # good [1] 1 4 2 sort.list(x, na.last = NA, method = quick) # still bad [1] 1 3 2 By the way, having the radix sort is great. It's really fast for factors. - Tom Tom Short Electric Power Research Institute (EPRI) sessionInfo() R version 2.10.1 (2009-12-14) i386-pc-mingw32 locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base Tom, See this recent follow up posting from Peter: http://tolstoy.newcastle.edu.au/R/e9/devel/10/02/0375.html There has been talk over the years of moving to Bugzilla, but I am not clear on present status. Perhaps the link on the main R Project page needs to be removed or better, updated to a link with a status update on the R bug reporting process. Of course, that does not help folks using bug.report(), which presumably needs to be updated as well. HTH, Marc Schwartz __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug reporting system inquiry plus a bug report related to sort
On Thu, Mar 04, 2010 at 09:39:41AM -0600, Marc Schwartz wrote: There has been talk over the years of moving to Bugzilla, but I am not clear on present status. IMHO Bugzilla is too challenging for normal users/human beeings (even developers are often not able to extract the info they need). So JIRA (http://www.atlassian.com/software/jira/) might be a much better choice - usually it is not a problem to ask for and get a license for free for OpenSource projects ... Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R logo as SVG ?
On Wed, Mar 03, 2010 at 05:42:24PM +0100, Henrik Bengtsson wrote: Hi Henrik, My Wednesday procrastination: There's quite some number of decimals in the SVG and some whitespace, so some dummy trimming gives: x - readLines(http://developer.r-project.org/Logo/Rlogo-1.svg;); ... Cool :). However, wrt. ressource consumption when the image gets loaded/rendered, I think there is no noticable gain. But anyway, reducing the package size is always a good thing :) ! Thanx, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug reporting system inquiry plus a bug report related to sort
On Mar 4, 2010, at 10:10 AM, Jens Elkner wrote: On Thu, Mar 04, 2010 at 09:39:41AM -0600, Marc Schwartz wrote: There has been talk over the years of moving to Bugzilla, but I am not clear on present status. IMHO Bugzilla is too challenging for normal users/human beeings (even developers are often not able to extract the info they need). So JIRA (http://www.atlassian.com/software/jira/) might be a much better choice - usually it is not a problem to ask for and get a license for free for OpenSource projects ... Jira was discussed a couple of years ago: http://tolstoy.newcastle.edu.au/R/e5/devel/08/09/0006.html I presume that the disposition towards non-FOSS platforms remains. FWIW, the company that I work for uses Bugzilla (and SVN) on RHEL for our own internal development and bug/issue reporting processes. We have both clients and employees using our Bugzilla platform. The key to having a successful result is not the software, but that the end users and developers can interact with a base of information that enables productive conversation. That places a certain burden on those reporting the bugs/issues to understand both when and how to report bugs, including providing sufficient information on the platform, versions, code and data to reliably reproduce the issue observed. As we frequently see on both R-Help and R-Devel, in my mind, that is the limiting characteristic. With bug.report(), we still have issues and that is arguably independent of the host bug management system. I would argue that if there was a somewhat bigger hurdle in place to bug reporting that compelled folks to post to R-Help first, before filing a formal bug report, that this would not be a bad outcome. Whatever the host system may be, a member of R Core will still need to manually process the report, adding to their overhead. Reducing the number of false positives would be helpful. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug reporting system inquiry plus a bug report related to sort
Just to calm the discussion a bit - we already have decided to go with Bugzilla, we created tools for the import of old PRs and the new bug system is up and running in a test phase. The current downtime is not directly related to that - the cause is being investigated. Cheers, Simon On Mar 4, 2010, at 11:58 , Marc Schwartz wrote: On Mar 4, 2010, at 10:10 AM, Jens Elkner wrote: On Thu, Mar 04, 2010 at 09:39:41AM -0600, Marc Schwartz wrote: There has been talk over the years of moving to Bugzilla, but I am not clear on present status. IMHO Bugzilla is too challenging for normal users/human beeings (even developers are often not able to extract the info they need). So JIRA (http://www.atlassian.com/software/jira/) might be a much better choice - usually it is not a problem to ask for and get a license for free for OpenSource projects ... Jira was discussed a couple of years ago: http://tolstoy.newcastle.edu.au/R/e5/devel/08/09/0006.html I presume that the disposition towards non-FOSS platforms remains. FWIW, the company that I work for uses Bugzilla (and SVN) on RHEL for our own internal development and bug/issue reporting processes. We have both clients and employees using our Bugzilla platform. The key to having a successful result is not the software, but that the end users and developers can interact with a base of information that enables productive conversation. That places a certain burden on those reporting the bugs/issues to understand both when and how to report bugs, including providing sufficient information on the platform, versions, code and data to reliably reproduce the issue observed. As we frequently see on both R-Help and R-Devel, in my mind, that is the limiting characteristic. With bug.report(), we still have issues and that is arguably independent of the host bug management system. I would argue that if there was a somewhat bigger hurdle in place to bug reporting that compelled folks to post to R-Help first, before filing a formal bug report, that this would not be a bad outcome. Whatever the host system may be, a member of R Core will still need to manually process the report, adding to their overhead. Reducing the number of false positives would be helpful. Marc __ 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] Bug reporting system inquiry plus a bug report related to sort
Thanks for the update and your work on this Simon. Regards, Marc On Mar 4, 2010, at 11:36 AM, Simon Urbanek wrote: Just to calm the discussion a bit - we already have decided to go with Bugzilla, we created tools for the import of old PRs and the new bug system is up and running in a test phase. The current downtime is not directly related to that - the cause is being investigated. Cheers, Simon On Mar 4, 2010, at 11:58 , Marc Schwartz wrote: On Mar 4, 2010, at 10:10 AM, Jens Elkner wrote: On Thu, Mar 04, 2010 at 09:39:41AM -0600, Marc Schwartz wrote: There has been talk over the years of moving to Bugzilla, but I am not clear on present status. IMHO Bugzilla is too challenging for normal users/human beeings (even developers are often not able to extract the info they need). So JIRA (http://www.atlassian.com/software/jira/) might be a much better choice - usually it is not a problem to ask for and get a license for free for OpenSource projects ... Jira was discussed a couple of years ago: http://tolstoy.newcastle.edu.au/R/e5/devel/08/09/0006.html I presume that the disposition towards non-FOSS platforms remains. FWIW, the company that I work for uses Bugzilla (and SVN) on RHEL for our own internal development and bug/issue reporting processes. We have both clients and employees using our Bugzilla platform. The key to having a successful result is not the software, but that the end users and developers can interact with a base of information that enables productive conversation. That places a certain burden on those reporting the bugs/issues to understand both when and how to report bugs, including providing sufficient information on the platform, versions, code and data to reliably reproduce the issue observed. As we frequently see on both R-Help and R-Devel, in my mind, that is the limiting characteristic. With bug.report(), we still have issues and that is arguably independent of the host bug management system. I would argue that if there was a somewhat bigger hurdle in place to bug reporting that compelled folks to post to R-Help first, before filing a formal bug report, that this would not be a bad outcome. Whatever the host system may be, a member of R Core will still need to manually process the report, adding to their overhead. Reducing the number of false positives would be helpful. Marc __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.10.0 or R 2.10.1 installation fails on HP-UX B.11.23 U ia64
Hi Folks, I can find any hits anywhere for the following compilation error:
eigen.f
external subroutine BALANC
external subroutine BALBAK
external subroutine CBABK2
external subroutine CBAL
external subroutine CDIV
external subroutine COMQR
external subroutine COMQR2
external subroutine CORTH
external subroutine CSROOT
external subroutine ELMHES
external subroutine ELTRAN
external function EPSLON
external subroutine HQR
external subroutine HQR2
external subroutine HTRIBK
external subroutine HTRIDI
external function PYTHAG
external subroutine TQL1
external subroutine TQL2
external subroutine TQLRAT
external subroutine TRED1
external subroutine TRED2
external subroutine RG
external subroutine RS
external subroutine CG
external subroutine CH
3502 Lines Compiled
Make: Don't know how to make #. Stop.
*** Error exit code 1
Stop.
*** Error exit code 1
Stop.
*** Error exit code 1
Stop.
Has anyone seen this make error before?
Make: Don't know how to make #. Stop.
Thanks for any thoughts.
//
// Alex Bryant
// Software Developer
// Integrated Clinical Systems, Inc.
// 908-996-7208
Confidentiality Note: This e-mail, and any attachment to...{{dropped:13}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#14226) -- Re: libgfortran misplaced in Mac OS X R install
Another possibility is to link statically to libgfortran. That has pros and cons, but for libgfortran not many cons apart from space for multiple copies in sundry packages (and is what is done on Windows, BTW). There are several ways to arrange that. As far as I recall I temporarily removed /usr/local/lib/libgfortran*.dylib: another way is to edit FLIBS in Makeconf (but then you do need to know which copies of that file you need to edit). As far as I know we don't document in the standard manuals how to build distributable binary Mac packages, and perhaps we should do so in due course (or at least point at where the information can be found). On Thu, 4 Mar 2010, Simon Urbanek wrote: Hi Michael, On Mar 3, 2010, at 12:01 , Michael Spiegel wrote: I am the guy who compiles the OpenMx binaries. We would be delighted to place our package on CRAN, once the project is stable enough so that we are comfortable releasing it to the larger public. Let's try to track down where I made a mistake. Our Makevars.in file contains the line: PKG_LIBS=$(FLIBS) $(BLAS_LIBS) $(LAPACK_LIBS) In addition, on the build machine I noticed that a copy of libgfortran.2.dylib exists at /usr/local/lib. I believe the Xcode install placed a copy of it there. No, it is part of the GNU Fortran installation. Anything you compile with a Fortran requires that you have that Fortran installed at run time, because Fortran uses its own run-time libraries (if the Fortran you compiled with used dynamic libraries). This implies that if you distribute your package you have to tell users to install the same Fortran you used to compile it. However, unlike other unices Mac users don't necessarily have development tools installed, so on CRAN we make an effort to modify the binaries such that they work even without the tools they have been compiled with. There are several possible approaches, but since R itself already uses the same Fortran, we ship a copy of the Fortran libraries inside R and modify packages such that they use it instead of the one from dev tools (see below for details). To create the binary release, I run R CMD INSTALL --build. That is not sufficient to create a binary of your package, because it contains a configure script (this is unrelated to the above - see R-admin 2.6). What you want to use is something like this (assuming R 2.10.1 Leopard build and Fortran from CRAN): R --arch=i386 CMD INSTALL OpenMx_0.2.9-1147.tar.gz R --arch=x86_64 CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz R --arch=ppc CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz cd /Library/Frameworks/R.framework/Versions/2.10/Resources/library # fix the Fortran paths to point to R 2.10 instead for lib in `ls OpenMx/libs/*/*.so`; do install_name_tool -change /usr/local/lib/libgfortran.2.dylib \ /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libgfortran.2.dylib \ $lib done # change permissions for distribution sudo chown -Rh root:admin OpenMx sudo chmod -R g+w OpenMx # pack it up tar fvcz ~/OpenMx_0.2.9-1147.tgz OpenMx You can check that you have the correct paths using otool -L: ginaz:library$ otool -L OpenMx/libs/*/*.so OpenMx/libs/i386/OpenMx.so: OpenMx.so (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libgfortran.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libRblas.dylib (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libRlapack.dylib (compatibility version 2.10.0, current version 2.10.1) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libR.dylib (compatibility version 2.10.0, current version 2.10.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.19.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib (compatibility version 1.0.0, current version 242.0.0) OpenMx/libs/ppc/OpenMx.so: OpenMx.so (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libgfortran.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libRblas.dylib (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libRlapack.dylib (compatibility version 2.10.0, current version 2.10.1) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/libR.dylib (compatibility version 2.10.0, current version 2.10.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version
[Rd] distributable binary Mac packages [Was: libgfortran misplaced in Mac OS X R install]
On Mar 4, 2010, at 14:44 , Prof Brian Ripley wrote: Another possibility is to link statically to libgfortran. That has pros and cons, but for libgfortran not many cons apart from space for multiple copies in sundry packages (and is what is done on Windows, BTW). There are several ways to arrange that. As far as I recall I temporarily removed /usr/local/lib/libgfortran*.dylib: another way is to edit FLIBS in Makeconf (but then you do need to know which copies of that file you need to edit). The Xcode add-on compilers from R.research.att.com use static libgfortran by default, so if you didn't install any other Fortran, that will be the default. However, there are issues when linking multiple modules that also link libgfortran statically - dylibs are not allowed to contain multiple common symbols on OS X (with flat namespaces) which is the case if you get static libgfortran from two sources independently. The most prominent example is libRlapack linked into a package that also uses Fortran (that's why CRAN Rlapack does not use static libgfortran). There are ways around, but it all makes the already complex issue even more complex ;). As far as I know we don't document in the standard manuals how to build distributable binary Mac packages, and perhaps we should do so in due course (or at least point at where the information can be found). Yes, I agree. There are bits and pieces in the R for Mac FAQ, but it may be worth putting what I wrote below into the FAQ. Thanks, Simon On Thu, 4 Mar 2010, Simon Urbanek wrote: Hi Michael, On Mar 3, 2010, at 12:01 , Michael Spiegel wrote: I am the guy who compiles the OpenMx binaries. We would be delighted to place our package on CRAN, once the project is stable enough so that we are comfortable releasing it to the larger public. Let's try to track down where I made a mistake. Our Makevars.in file contains the line: PKG_LIBS=$(FLIBS) $(BLAS_LIBS) $(LAPACK_LIBS) In addition, on the build machine I noticed that a copy of libgfortran.2.dylib exists at /usr/local/lib. I believe the Xcode install placed a copy of it there. No, it is part of the GNU Fortran installation. Anything you compile with a Fortran requires that you have that Fortran installed at run time, because Fortran uses its own run-time libraries (if the Fortran you compiled with used dynamic libraries). This implies that if you distribute your package you have to tell users to install the same Fortran you used to compile it. However, unlike other unices Mac users don't necessarily have development tools installed, so on CRAN we make an effort to modify the binaries such that they work even without the tools they have been compiled with. There are several possible approaches, but since R itself already uses the same Fortran, we ship a copy of the Fortran libraries inside R and modify packages such that they use it instead of the one from dev tools (see below for details). To create the binary release, I run R CMD INSTALL --build. That is not sufficient to create a binary of your package, because it contains a configure script (this is unrelated to the above - see R-admin 2.6). What you want to use is something like this (assuming R 2.10.1 Leopard build and Fortran from CRAN): R --arch=i386 CMD INSTALL OpenMx_0.2.9-1147.tar.gz R --arch=x86_64 CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz R --arch=ppc CMD INSTALL --libs-only OpenMx_0.2.9-1147.tar.gz cd /Library/Frameworks/R.framework/Versions/2.10/Resources/library # fix the Fortran paths to point to R 2.10 instead for lib in `ls OpenMx/libs/*/*.so`; do install_name_tool -change /usr/local/lib/libgfortran.2.dylib \ /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib \ $lib done # change permissions for distribution sudo chown -Rh root:admin OpenMx sudo chmod -R g+w OpenMx # pack it up tar fvcz ~/OpenMx_0.2.9-1147.tgz OpenMx You can check that you have the correct paths using otool -L: ginaz:library$ otool -L OpenMx/libs/*/*.so OpenMx/libs/i386/OpenMx.so: OpenMx.so (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libgfortran.2.dylib (compatibility version 3.0.0, current version 3.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRblas.dylib (compatibility version 0.0.0, current version 0.0.0) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libRlapack.dylib (compatibility version 2.10.0, current version 2.10.1) /Library/Frameworks/R.framework/Versions/2.10/Resources/lib/ libR.dylib (compatibility version 2.10.0, current version 2.10.1) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/ CoreFoundation (compatibility version 150.0.0, current version 476.19.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib
Re: [Rd] Bug reporting system inquiry plus a bug report related to sort
On Thu, Mar 04, 2010 at 10:58:16AM -0600, Marc Schwartz wrote: ... Jira was discussed a couple of years ago: http://tolstoy.newcastle.edu.au/R/e5/devel/08/09/0006.html I presume that the disposition towards non-FOSS platforms remains. Was just an idea. IMHO the hosting team needs to decide, what they can accomplish/how many time they are able to invest to get that thing driven/maintained/adjusted. Everybody else has to live with that decision ;-) ... The key to having a successful result is not the software, but that the end users and developers can interact with a base of information that enables productive conversation. Exactly wrt. the last part. But often even developers just want to get its work done, don't have the time to get trained to a more or less complicated beast, have at least at the beginning no intention to extend it and just want to have their customers report bugs/oddities in a usable style, which is a problem, if one presents an interface, which is hard to use / use as intented because of the none-expert knowledge ... So IMHO success certainly depends on the software, as long as you do not have access limited to a [small] trained group ... ... I would argue that if there was a somewhat bigger hurdle Hurdles wrt. SW dev and help are always bad. Thinking about how to make it easier to find the required information/right direction is a good thing ... Whatever the host system may be, a member of R Core will still need to manually process the report, adding to their overhead. Reducing the number of false positives would be helpful. ... Yes. So good/extensive documentation/examples is the? key for success ? ;-) Regards, jel. -- Otto-von-Guericke University http://www.cs.uni-magdeburg.de/ Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2 39106 Magdeburg, Germany Tel: +49 391 67 12768 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] scale(x, center=FALSE) (PR#14219)
Ben Bolker bolker at ufl.edu writes:
[re: behavior of scale() when center=FALSE and scale=TRUE]
Again, I agree with you that the behavior is not optimal, but it is
very hard to make changes in R when the behavior is sub-optimal rather
than actually wrong (by some definition). R-core is very conservative
about changes that break backward compatibility; I would like it if they
chose to change the function to use standard deviation rather than
root-mean-square, but I doubt it will happen (and it would break things
for any users who are relying on the current definition).
[snip]
I have attached a patch
file (and append the information below as well) that changes standard
deviation back to root mean square and is much more explicit about
this issue ... I hope R-core will jump in, critique it, and possibly use
it in some form to improve (?) the documentation ...
[PS: I have written that the scaling is equivalent to sd() if and
only if centering was done. Technically it would also be equivalent if
the column already had zero mean ...]
===
--- scale.Rd(revision 51180)
+++ scale.Rd(working copy)
@@ -41,13 +41,18 @@
equal to the number of columns of \code{x}, then each column of
\code{x} is divided by the corresponding value from \code{scale}. If
\code{scale} is \code{TRUE} then scaling is done by dividing the
- (centered) columns of \code{x} by their standard deviations, and if
+ (centered) columns of \code{x} by their root-mean-squares, and if
\code{scale} is \code{FALSE}, no scaling is done.
-
- The standard deviation for a column is obtained by computing the
- square-root of the sum-of-squares of the non-missing values in the
- column divided by the number of non-missing values minus one (whether
- or not centering was done).
+
+ The root-mean-square for a (possibly centered)
+ column is defined as
+ \eqn{\sqrt{\sum(x^2)/(n-1)}}{sqrt(sum(x^2)/(n-1))},
+ where \eqn{x} is a vector of the non-missing values
+ and \eqn{n} is the number of non-missing values.
+ If (and only if) centering was done,
+ this is equivalent to \code{sd(x,na.rm=TRUE)}.
+ (To scale by the standard deviations without centering,
+ use \code{scale(x,center=FALSE,scale=apply(x,2,sd,na.rm=TRUE))}.)
}
\references{
Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988)
(Bump re: suggested update to scale.Rd . Is this under
consideration? I'll stop pestering if it's considered
unacceptable, just don't want it to vanish without a trace ...)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
