I recall proposing something like this (that is, a classification of available functions) some time ago, but it never got off the ground. The advantage of using keywords is that package authors would classify their own functions, but I don't think that the current set of keywords is adequate. It would be particularly useful to work out a hierarchical or perhaps hyper-linked classification (without restricting particular functions to just one terminal node).
Regards, John
At 09:29 PM 11/24/2003 -0500, Warnes, Gregory R wrote:
How about we use the information already stored in \keyword{}?
It should be straighforward to allow navigating among the \keyword hirearchy.
-G
-----Original Message----- From: Paul Murrell To: Jan de Leeuw Cc: Warnes, Gregory R; '[EMAIL PROTECTED]' Sent: 11/24/03 6:12 PM Subject: Re: [Rd] Proposal: 'global' package refactoring
Hi
I have wanted to figure out a way to do something along these lines for the many, widely-scattered plotting functions. Something that would be less invasive (and less useful, but a valid step in the right direction), is simply a "directory" for different functional groups. A list of function names, plus descriptions of what they do, plus a pointer to the package they are in would I think be really useful. A lot of work to create and maintain, but really useful. For example, the
web pages focused on "spatial projects" (http://sal.agecon.uiuc.edu/csiss/Rgeo/index.html) has summaries of all spatially related packages. The coordination of the DBMS stuff (http://developer.r-project.org/db/index.html) is another example of something similar. Then of course there is the R GUIs pages (http://www.sciviews.org/_rgui/)
Paul
Jan de Leeuw wrote: > This is a good idea, and it would be great to have these > refactored meta packages. But it actually implies having > a group similar to R core that does code review of > existing packages. For example, what happens if > a function seems to work but is programmed horribly > inefficiently ? What happens if something exists on both > the R and C levels ? What happens with packages that > rely on private versions of BLAS ? Suppose two packages > provide the same functionality, how does one choose ? > And can this be done without coding conventions ? Who is > in charge ? > > On Nov 24, 2003, at 14:12, Warnes, Gregory R wrote: > >> >> Looking over the contents of various packages, including my own, it >> is clear >> that lots of things end up 'hidden away' in packages where they don't >> belong. My gregmisc package is a particularly egregious example, >> containing >> something from almost every functional category. >> >> I propose that from time to time the R community go through the >> complete set >> of packages and 'refactor' the functions and data sets into packages
>> that >> have clearly defined goals. This should make it easier to ensure >> that new >> functions get placed into a location where users can easily find them, >> reduce the amount of re-implementation/duplication existing >> functionality, >> and assist in ensuring interoperability. >> >> It would be worthwhile, for instance, to pull all of the functions >> related >> to contrasts for generalized linear models into a common location, >> instead >> of having them spread between base, Hmisc, MASS, gregmisc, etc. >> Similarly, >> it would be helpful to pull together all of the genetics-computations
>> into a >> single location. >> >> I recognize that not all package maintainers would be willing to >> participate >> and that not all functions could be easily categorized, but I believe
>> that >> this effort would yield significant benefit and is compatible with >> the goal >> of R-core to streamline the base packages. >> >> To put my money where my mouth is, I'll volunteer to organize a group
>> effort >> to do such a refactoring in conjunction with the userR! 2004 or the next >> DSC, whichever folks agree is better for this purpose. >> >> >> Gregory R. Warnes, Ph.D. >> Senior Coordinator >> Groton Non-Clinical Statistics >> Pfizer Global Research and Development >> <<Warnes, Gregory R.vcf>> >> >> >> LEGAL NOTICE\ Unless expressly stated otherwise, this >> messag...{{dropped}} >> >> ______________________________________________ >> [EMAIL PROTECTED] mailing list >> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel >> > === > Jan de Leeuw; Professor and Chair, UCLA Department of Statistics; > Editor: Journal of Multivariate Analysis, Journal of Statistical Software > US mail: 8130 Math Sciences Bldg, Box 951554, Los Angeles, CA 90095-1554 > phone (310)-825-9550; fax (310)-206-5658; email: [EMAIL PROTECTED] > homepage: http://gifi.stat.ucla.edu > > ------------------------------------------------------------------------
> ------------------------- > No matter where you go, there you are. --- Buckaroo Banzai > http://gifi.stat.ucla.edu/sounds/nomatter.au > > ______________________________________________ > [EMAIL PROTECTED] mailing list > https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
-- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/
LEGAL NOTICE\ Unless expressly stated otherwise, this messag...{{dropped}}
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
----------------------------------------------------- John Fox Department of Sociology McMaster University Hamilton, Ontario, Canada L8S 4M4 email: [EMAIL PROTECTED] phone: 905-525-9140x23604 web: www.socsci.mcmaster.ca/jfox
______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
