Re: [Rd] readRDS and saveRDS
On Oct 18, 2011, at 8:32 PM, Hervé Pagès wrote: On 11-10-18 04:00 PM, Kevin Wright wrote: Hadley, Any chance of changing fun.aggregate to FUN and value_var to value.var? aggregate(.., FUN, ...) acast(..., fun.aggregate, ...) cast(..., value.var) acast(..., value_var) Side note: My fantasy for R 3.0 would be to fix the obvious inconsistencies in function names/arguments, use Roxygen format for the documentation, change the egregious [ , , drop=TRUE] to FALSE and paste(..., sep=), install packages on the fly, and improve consistency for functions dealing with colors (hex, 0-1, 0-255, etc). Sounds like a dream ;-) Please add to that list dropping the stringsAsFactors feature and fixing c(factor(c(a, b)), factor(c(c, a))). Can you, please, post any such ideas for making S/R consistent, especially if it breaks backward compatibility, to the Aleph mailing list? Comments from non-R users that find R inconsistent are also welcome if they substantiate their claims. http://lists.rforge.net/cgi-bin/mailman/listinfo/aleph-devel (If you have a better idea where to collect it in a single place, I'm all ear). I'd like to collect as many such ideas as possible so we don't forget something in unlikely case Aleph gets off the ground. :) Thanks, Simon Thanks! H. Kevin On Tue, Oct 18, 2011 at 8:37 AM, Hadley Wickhamhad...@rice.edu wrote: Hi all, Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. 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 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ 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] readRDS and saveRDS
2011/10/19 Simon Urbanek simon.urba...@r-project.org: I'd like to collect as many such ideas as possible so we don't forget something in unlikely case Aleph gets off the ground. :) Thanks, Simon Simon, From our department : Yes, You Can! Give us an A Give us an L Give us an E Give us a P Give us an H Give us Aleph! (please please pretty please...) Cheers (and tons of them) Joris -- Joris Meys Statistical consultant Ghent University Faculty of Bioscience Engineering Department of Applied mathematics, biometrics and process control 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] readRDS and saveRDS
I have no idea what aleph is now or is likely to become. If I follow your URL for the mailing list and click on the archives link, it tells me that there are no posts and the archive is empty, which makes it rather difficult to find out what aleph is (or why I should care). Perhaps there is a web site somewhere that describes (plans for) aleph so someone who wants to find out what you are talking about can get a little information? Best, Kevin On 10/19/2011 8:20 AM, Simon Urbanek wrote: Can you, please, post any such ideas for making S/R consistent, especially if it breaks backward compatibility, to the Aleph mailing list? Comments from non-R users that find R inconsistent are also welcome if they substantiate their claims. http://lists.rforge.net/cgi-bin/mailman/listinfo/aleph-devel (If you have a better idea where to collect it in a single place, I'm all ear). I'd like to collect as many such ideas as possible so we don't forget something in unlikely case Aleph gets off the ground. :) Thanks, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
You find some (very brief) information here : http://www.rforge.net/mediawiki/index.php/Aleph Cheers Joris On Wed, Oct 19, 2011 at 4:08 PM, Kevin R. Coombes kevin.r.coom...@gmail.com wrote: I have no idea what aleph is now or is likely to become. If I follow your URL for the mailing list and click on the archives link, it tells me that there are no posts and the archive is empty, which makes it rather difficult to find out what aleph is (or why I should care). Perhaps there is a web site somewhere that describes (plans for) aleph so someone who wants to find out what you are talking about can get a little information? Best, Kevin On 10/19/2011 8:20 AM, Simon Urbanek wrote: Can you, please, post any such ideas for making S/R consistent, especially if it breaks backward compatibility, to the Aleph mailing list? Comments from non-R users that find R inconsistent are also welcome if they substantiate their claims. http://lists.rforge.net/cgi-bin/mailman/listinfo/aleph-devel (If you have a better idea where to collect it in a single place, I'm all ear). I'd like to collect as many such ideas as possible so we don't forget something in unlikely case Aleph gets off the ground. :) Thanks, Simon __ 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 Applied mathematics, biometrics and process control 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] readRDS and saveRDS
I'd second this. Though my thinking was to add writeRDS instead of saveRDS. Jeff On Tue, Oct 18, 2011 at 8:37 AM, Hadley Wickham had...@rice.edu wrote: Hi all, Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. 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 -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
On 18/10/2011 9:37 AM, Hadley Wickham wrote: Hi all, Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. Ending names in .foo is a bad idea because of the S3 naming conventions, so I think this is unlikely. But you can always create an alias yourself... Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. Ending names in .foo is a bad idea because of the S3 naming conventions, so I think this is unlikely. But you can always create an alias yourself... It just makes teaching that much harder. We have the pairs: * read.csv and write.csv * load and save * readRDS and saveRDS Even loadRDS/saveRDS or readRDS/writeRDS would be better than the current combo. 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] readRDS and saveRDS
As load involves a side-effect, I would think that loadRDS is a bad idea. That said, read/write is far more consistent across all languages and internally with R than read/save is. My (worthless) vote is for writeRDS. Jeff On Tue, Oct 18, 2011 at 11:37 AM, Hadley Wickham had...@rice.edu wrote: Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. Ending names in .foo is a bad idea because of the S3 naming conventions, so I think this is unlikely. But you can always create an alias yourself... It just makes teaching that much harder. We have the pairs: * read.csv and write.csv * load and save * readRDS and saveRDS Even loadRDS/saveRDS or readRDS/writeRDS would be better than the current combo. 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 -- Jeffrey Ryan jeffrey.r...@lemnica.com www.lemnica.com www.esotericR.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
On Tue, 2011-10-18 at 08:37 -0500, Hadley Wickham wrote: Hi all, Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. Hadley I would hope not. Those would then look like S3 methods for class rds and cause confusion of a different sort. It would be better to make the existing read.foo and write.foo functions drop their . but that is unlikely to happen given all the code that would inevitably break. G -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% 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] readRDS and saveRDS
On 18/10/2011 12:37 PM, Hadley Wickham wrote: Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. Ending names in .foo is a bad idea because of the S3 naming conventions, so I think this is unlikely. But you can always create an alias yourself... It just makes teaching that much harder. We have the pairs: * read.csv and write.csv * load and save * readRDS and saveRDS Even loadRDS/saveRDS or readRDS/writeRDS would be better than the current combo. Every problem is an opportunity. Think of this as an example of why it's important to think about the names you give to functions. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
On Tue, 18 Oct 2011, Hadley Wickham wrote: * read.csv and write.csv * load and save * readRDS and saveRDS Even loadRDS/saveRDS or readRDS/writeRDS would be better than the current combo. You could change the CSV functions to readCSV and writeCSV :) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
On Tue, Oct 18, 2011 at 9:34 AM, Duncan Murdoch murdoch.dun...@gmail.com wrote: On 18/10/2011 9:37 AM, Hadley Wickham wrote: Hi all, Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. Ending names in .foo is a bad idea because of the S3 naming conventions, so I think this is unlikely. But you can always create an alias yourself... I always thought that S3 was part of the reason for read.ext write.ext. In: /path/file.ext the class of the file is ext. I kind of like the idea of taking this farther, generic functions read/write dispatch to the appropriate method depending on the class of the file. Generally, only read/write would be used, specifying the specific method as needed. read.rda and write.rda could replace load/save where: dat - read.rda() would create an environment, dat rather than simply loading them into the global environment. Though this is more of a hypothetical situation than a suggestion for change. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Joshua Wiley Ph.D. Student, Health Psychology Programmer Analyst II, ATS Statistical Consulting Group University of California, Los Angeles https://joshuawiley.com/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
Ending names in .foo is a bad idea because of the S3 naming conventions, so I think this is unlikely. But you can always create an alias yourself... I always thought that S3 was part of the reason for read.ext write.ext. In: /path/file.ext the class of the file is ext. I kind of like the idea of taking this farther, generic functions read/write dispatch to the appropriate method depending on the class of the file. Generally, only read/write would be used, specifying the specific method as needed. read.rda and write.rda could replace load/save where: dat - read.rda() would create an environment, dat rather than simply loading them into the global environment. Though this is more of a hypothetical situation than a suggestion for change. That makes me think of a generic read that would dispatch not on the class of the first argument (which would always be a string), but would instead dispatch on the file extension. So read(x.csv) would call read.csv, read(cache.rds) would use readRDS etc. Of course it doesn't work in complete generality, but it's a fun idea to think about. 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] readRDS and saveRDS
Hadley, Any chance of changing fun.aggregate to FUN and value_var to value.var? aggregate(.., FUN, ...) acast(..., fun.aggregate, ...) cast(..., value.var) acast(..., value_var) Side note: My fantasy for R 3.0 would be to fix the obvious inconsistencies in function names/arguments, use Roxygen format for the documentation, change the egregious [ , , drop=TRUE] to FALSE and paste(..., sep=), install packages on the fly, and improve consistency for functions dealing with colors (hex, 0-1, 0-255, etc). Kevin On Tue, Oct 18, 2011 at 8:37 AM, Hadley Wickham had...@rice.edu wrote: Hi all, Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. 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 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] readRDS and saveRDS
On 11-10-18 04:00 PM, Kevin Wright wrote: Hadley, Any chance of changing fun.aggregate to FUN and value_var to value.var? aggregate(.., FUN, ...) acast(..., fun.aggregate, ...) cast(..., value.var) acast(..., value_var) Side note: My fantasy for R 3.0 would be to fix the obvious inconsistencies in function names/arguments, use Roxygen format for the documentation, change the egregious [ , , drop=TRUE] to FALSE and paste(..., sep=), install packages on the fly, and improve consistency for functions dealing with colors (hex, 0-1, 0-255, etc). Sounds like a dream ;-) Please add to that list dropping the stringsAsFactors feature and fixing c(factor(c(a, b)), factor(c(c, a))). Thanks! H. Kevin On Tue, Oct 18, 2011 at 8:37 AM, Hadley Wickhamhad...@rice.edu wrote: Hi all, Is there any chance that readRDS and saveRDS might one day become read.rds and write.rds? That would make them more consistent with the other reading and writing functions. 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 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Hervé Pagès Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpa...@fhcrc.org Phone: (206) 667-5791 Fax:(206) 667-1319 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
