Dear Chris, Add both snps_36 and genes_36 to the same rda file. Then you should both load with a single data() command.
However make sure to document all functions well. Then it is up to the user to use the functions correctly. You can implement some controls to give a warning when incorrect data is provided. See fortunes::fortune(15) as well. Best regards, ir. Thierry Onkelinx Instituut voor natuur- en bosonderzoek / Research Institute for Nature and Forest team Biometrie & Kwaliteitszorg / team Biometrics & Quality Assurance Kliniekstraat 25 1070 Anderlecht Belgium + 32 2 525 02 51 + 32 54 43 61 85 thierry.onkel...@inbo.be www.inbo.be To call in the statistician after the experiment is done may be no more than asking him to perform a post-mortem examination: he may be able to say what the experiment died of. ~ Sir Ronald Aylmer Fisher The plural of anecdote is not data. ~ Roger Brinner The combination of some data and an aching desire for an answer does not ensure that a reasonable answer can be extracted from a given body of data. ~ John Tukey -----Oorspronkelijk bericht----- Van: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] Namens Chris Wallace Verzonden: maandag 21 juli 2014 15:58 Aan: r-devel@r-project.org Onderwerp: [Rd] Multiple versions of data in a package Dear R-devel, I am writing for help on how I should include parallel sets of data in my package. Brief summary: I am new to using data within packages. I want a user to be able to specify one of two alternative versions of within-package datasets to use, and I want to load just that one. I have a solution that works, but it doesn't seem as simple as it should be from a user's point of view, nor does it seem robust to errors. What should I do better? More details: My package is a relatively simple set of plotting functions, that plot user supplied data across a number of SNPs from their experiment, and annotates the plot using some external data. For example, the user supplies SNP value A 2 B 1.2 C 7.8 etc The external datasets will allow me to look up the location of SNPs A, B, C, ... on the human genome so the user's data can be plotted in relation to that map, to annotate the position of local genes etc. My problem is that there is no single map of the genome, so I can prepare external data with the positions of SNPs and genes in version 36 or 37. To allow this, my data/ directory contains snps_37.Rdata, snps_36.RData, genes_37.RData, genes_36.RData the objects in these files are called, respectively, snps, snps, genes, genes Therefore, a user types > data(snps_37) > data(genes_37) or > data(snps_36) > data(genes_36) to set up build 36 or build 37 and then my functions need only use the object names snps or genes, and all is fine. But, this doesn't seem like a good solution. What if a user has snps_36 and genes_37 loaded? What if they have an object named snps in their working environment called snps? Alternatively, I could load all datasets and they could pass an argument "build" to my functions, but these are large datasets, and I don't want to use time and memory loading both versions when I expect any individual user to pick a single version and stick with it. Can anyone suggest how else I might proceed? Thank you, Chris -- JDRF/WT Diabetes & Inflammation Laboratory (DIL), NIHR Cambridge Biomedical Research Centre, Cambridge Institute for Medical Research, University of Cambridge Website:http://www-gene.cimr.cam.ac.uk/staff/wallace DIL Website:http://www-gene.cimr.cam.ac.uk ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel * * * * * * * * * * * * * D I S C L A I M E R * * * * * * * * * * * * * Dit bericht en eventuele bijlagen geven enkel de visie van de schrijver weer en binden het INBO onder geen enkel beding, zolang dit bericht niet bevestigd is door een geldig ondertekend document. The views expressed in this message and any annex are purely those of the writer and may not be regarded as stating an official position of INBO, as long as the message is not confirmed by a duly signed document. ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
