Re: [Rd] UTF-8 and .Rd files
On Wed, 28 Jun 2006, Peter Dalgaard wrote: Paul Gilbert <[EMAIL PROTECTED]> writes: I've been following this thread hoping for the definitive answer... Peter Dalgaard wrote: Well, I do tend to think that we should just use utf, assuming that people have the relevant glyphs. If they don't, then they might get little hollow rectangles but so what? Unfortunately, they might get nothing visible at all, and they might also get something completely wrong (happens on my Windows' X11 server on my laptop). This is not an R problem but a question of the quality of implementation of UTF-8. (Given the lack of UTF-8 fonts, I don't see the latter changing any time soon.) My comments (at UseR and to Göran) are intended to make people aware just how badly things can go wrong: it is up to the users to decide if transliteration is worse than the chance of mangling. My problem is that I put an ö in a reference in an Rd file, and now my builds fail on some of my systems. I can switch which systems work and which are broken, but I can not get it to work on all systems. I have spent way too much time trying to figure out what is wrong. So, wrt "so what", I need to choose between checking my packages on all the different systems I use, or having an ö in the Rd file. I think my problem is more complicated than having the relevant glyphs. I suspect it has to do with having the same locale on all systems doing NFS mounts, or on my cvs server, or something strange like that. Just to clarify, one thing is what I feel should be the longer term strategy, another is what the R build tools can currently do... Did you follow the advice to declare your input encoding with \encoding and use \enc to provide a transliteration? It is necessary to do so. I use a mixture of UTF-8 and latin1 locales on systems sharing a file system, and it all works for me: iconv does the charset translations transparently provided it knows what to do. -- Brian D. Ripley, [EMAIL PROTECTED] 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
[Rd] Storage of character vectors in R
There have been comments from time to time (over many years) on the inefficiency of the storage of character vectors in R, and R-core has been looking into the issues. We have some ideas but they would be a considerable amount of work to implement and it is unclear if they would actually help with current real-world problems. One example was the storage of integer row names for data frames, but such row names are stored much more efficiently in R-devel (2.4.0-to-be). We do have some other examples but these are highly artificial. What we would like is some real-world examples of problems in which users have found the storage of character vectors to be an appreciable problem. Ideally we want concrete reproducible examples that show the problem in R-devel, but abstractions of such examples (for example using synthetic rather than real data) would also be very helpful. If you can help, please do so by replying to this thread (and making examples available via URLs would probably be the most efficient route). -- Brian D. Ripley, [EMAIL PROTECTED] 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] NAMESPACE and bundle
El jue, 22-06-2006 a las 10:37 -0400, Paul Gilbert escribió:
> Iago
>
> I think your R code file needs an .onLoad function. Here is the
> ..onLoad from my dse1 package which is in the dse bundle, as is tframe,
> along with comments which I had forgotten.
>
> ..onLoad <- function(library, section) {
>.DSEflags(list(COMPILED=TRUE, DUP=TRUE))
># next require is necessary for bundle check to run examples,
># but does not seem to be necessary when packages are not bundled
>require("tframe")
>invisible(TRUE)
>}
>
>
> Hope this works,
> Paul
Hi,
Thanks for the tip. I already had an .onLoad() function, with
.onLoad <- function(lib,pkg) {
require(methods)
require(FLCore)
}
the first to comply with the needs of an S4 package, the second to solve
the internal dependency that outside of the bundle is solved with
Depends: in DESCRIPTION.
Is there anything else I could look at?
Thanks,
Iago
Iago Mosqueira wrote:
> > -Mensaje original-
> > De: Paul Gilbert [mailto:[EMAIL PROTECTED]
> > Enviado el: jue 22/06/2006 15:47
> > Para: Iago Mosqueira
> > CC: r-devel@r-project.org
> > Asunto: Re: [Rd] NAMESPACE and bundle
>
> > Iago
>
> > There is a problem that bundle checking works slightly differently
than
> > individual package checking in this regard. I think it has to do
with
> > when the namespace gets registered, or something like that. As I
recall,
> > the work around is to explicitely require the package in the test
files
> > for it. I.e. put
> > require("pac")
> > in all the files in pac/tests. If that does not work, let me know
and
> > I will look more carefully to find what I had to do.
>
> > Paul
>
>
> Paul,
>
> Many thanks. The problem is in the examples contained in the Rd
files,
> where we do not explictely load the package, as we do in test files.
> But it is only a problem for the examples in this package, not in the
> others that share the same package dependencies. Can you see any
> solution or something I else I should check for?
>
> Thanks
>
>
> Iago
>
>
> Iago Mosqueira wrote:
>
> >Dear all,
> >
> >I have a package that passes R CMD check, and shows no problems when
> using all its methods as declared in NAMESPACE. When this package is
> added to a bundle, which already consists of 5 packages, the examples
> in the Rd pages thta call a number of methods fail during the bundle
> check. These all passed when check is run on this package alone.
Other
> packages in the bundle are very similar, in that all import all S4
> classes and methods from the first package (using import("FLCore") in
> NAMESPACE) in the bundle, and export their own overloaded methods.
> >
> >If I run check on a mini-bundle consisting only of the main package
> (FLCore) and this problematic package, it shows no problem. So I
> assume a problem of NAMESPACE conflict is the culprit, but
> experimnting with various package combinations, to try and isolate
the
> conflict, has not worked. This package seems to conflict with every
> other secondary package.
> >
> >I am dealing with internal dependencies by adding a require(FLCore)
> line to the .onLoad() call in zzz.R
> >
> >Can anybody point me at what to look for? What could be the reason
> for this problem?
> >
> >I hope the explanation was clear enough. Many thanks,
> >
> >
> >Iago
> >
> >
> >Dr. Iago Mosqueira
> >
> >Marine Research Division
> >AZTI Tecnalia
> >Txatxarramendi Ugartea, z/g
> >48395 Sukarrieta - Bizkaia
> >Spain
> >
> >+34 946 029 448
> >+34 946 029 400
> >+34 946 029 401 (Fax)
> >
> >[EMAIL PROTECTED]
> >http://www.azti.es/
> >
> >
> >
>
>
> >
> >__
> >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] NAMESPACE and bundle
Iago Mosqueira wrote:
> El jue, 22-06-2006 a las 10:37 -0400, Paul Gilbert escribió:
>
>>Iago
>>
>>I think your R code file needs an .onLoad function. Here is the
>>..onLoad from my dse1 package which is in the dse bundle, as is tframe,
>>along with comments which I had forgotten.
>>
>>..onLoad <- function(library, section) {
>> .DSEflags(list(COMPILED=TRUE, DUP=TRUE))
>> # next require is necessary for bundle check to run examples,
>> # but does not seem to be necessary when packages are not bundled
>> require("tframe")
>> invisible(TRUE)
>> }
>>
>>
>>Hope this works,
>>Paul
>
>
> Hi,
>
> Thanks for the tip. I already had an .onLoad() function, with
>
> .onLoad <- function(lib,pkg) {
> require(methods)
> require(FLCore)
> }
>
> the first to comply with the needs of an S4 package, the second to solve
> the internal dependency that outside of the bundle is solved with
> Depends: in DESCRIPTION.
Hello Iago,
In principle, you should not use require() statements any more.
Dependences should be resolved in the NAMESPACE and in Depends: field of
description. It works for me for the SciViews bundle. I think that the
situation is the same as for FLR: I have a svMisc package with basic
functions, and all other packages depend on it, plus other complex
interdependences between the other packages in the bundle.
You should really think twice before distributing a bundle: it is more
of a problem. First, you force users to download and install the whole
bundle (by definition!), even if they are interested by ony a part of
it. Second, it is the same for updates: if you change something in one
package, you must upload the whole bundle.
Now that dependencies are nicely resolved during R package installation,
bundles are not so attracting, and I would advise to continue
distributing your packages separately.
Best,
Philippe Grosjean
> Is there anything else I could look at?
>
> Thanks,
>
>
> Iago
>
>
>
> Iago Mosqueira wrote:
>
>
>>>-Mensaje original-
>>>De: Paul Gilbert [mailto:[EMAIL PROTECTED]
>>>Enviado el: jue 22/06/2006 15:47
>>>Para: Iago Mosqueira
>>>CC: r-devel@r-project.org
>>>Asunto: Re: [Rd] NAMESPACE and bundle
>>
>>>Iago
>>
>>>There is a problem that bundle checking works slightly differently
>
> than
>
>>>individual package checking in this regard. I think it has to do
>
> with
>
>>>when the namespace gets registered, or something like that. As I
>
> recall,
>
>>>the work around is to explicitely require the package in the test
>
> files
>
>>>for it. I.e. put
>>> require("pac")
>>>in all the files in pac/tests. If that does not work, let me know
>
> and
>
>>>I will look more carefully to find what I had to do.
>>
>>>Paul
>>
>>
>>Paul,
>>
>>Many thanks. The problem is in the examples contained in the Rd
>
> files,
>
>>where we do not explictely load the package, as we do in test files.
>>But it is only a problem for the examples in this package, not in the
>>others that share the same package dependencies. Can you see any
>>solution or something I else I should check for?
>>
>>Thanks
>>
>>
>>Iago
>>
>>
>>Iago Mosqueira wrote:
>>
>>
>>>Dear all,
>>>
>>>I have a package that passes R CMD check, and shows no problems when
>>
>>using all its methods as declared in NAMESPACE. When this package is
>>added to a bundle, which already consists of 5 packages, the examples
>>in the Rd pages thta call a number of methods fail during the bundle
>>check. These all passed when check is run on this package alone.
>
> Other
>
>>packages in the bundle are very similar, in that all import all S4
>>classes and methods from the first package (using import("FLCore") in
>>NAMESPACE) in the bundle, and export their own overloaded methods.
>>
>>>If I run check on a mini-bundle consisting only of the main package
>>
>>(FLCore) and this problematic package, it shows no problem. So I
>>assume a problem of NAMESPACE conflict is the culprit, but
>>experimnting with various package combinations, to try and isolate
>
> the
>
>>conflict, has not worked. This package seems to conflict with every
>>other secondary package.
>>
>>>I am dealing with internal dependencies by adding a require(FLCore)
>>
>>line to the .onLoad() call in zzz.R
>>
>>>Can anybody point me at what to look for? What could be the reason
>>
>>for this problem?
>>
>>>I hope the explanation was clear enough. Many thanks,
>>>
>>>
>>>Iago
>>>
>>>
>>>Dr. Iago Mosqueira
>>>
>>>Marine Research Division
>>>AZTI Tecnalia
>>>Txatxarramendi Ugartea, z/g
>>>48395 Sukarrieta - Bizkaia
>>>Spain
>>>
>>>+34 946 029 448
>>>+34 946 029 400
>>>+34 946 029 401 (Fax)
>>>
>>>[EMAIL PROTECTED]
>>>http://www.azti.es/
>>>
>>>
>>>
>>
>>
>>
>>>__
>>>R-devel@r-project.org mailing list
>>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>
>
> ___
[Rd] inconsistent matplot behaviour?
I raised this question quite some time ago but it quitly went down the
river. I'll give it a second try (before keeping my modified version of
matplot for ever...):
matplot supports vectors (and/or character strings) for a number of
arguments namely `type', `lty', `lwd', `pch', `col', `cex'. all of them
act consistently in such a way that the first entries are used for plot
of x-column 1 vs. y-column 1 and so forth.
for some reason `bg' is missing from this list (maybe simplyh
forgotten?). this causes an, according to my mind, at least, undesirable
(inconsistent) behaviour in calls like
matplot(x, y, type = 'b', pch = 21:23, col = 2:4, bg = 2:4)
(assuming x, y are 3-column matrices)
`col', `pch' and the other explicit arguments are interpreted on a 'per
plot' basis whereas `bg' is transferred to plot.default and is therefore
interpreted on a 'per point' basis. thus, `col' above sets the colors of
the plotting symbols in the different line plots (say, column 1 to 3)
whereas `bg' sets the colors alternating down each column of the data,
i.e. within each line plot.
question: would'nt it be desirable and more consistent/intuitive if `bg'
where treated on the same footing as the other explicit parameters,
especially if combinations of `pch>=21' and `bg' are envisaged?
necessary changes to matplot are trivial:
3c3
< ..., add = FALSE, verbose = getOption("verbose"))
---
> bg = NULL, ..., add = FALSE, verbose = getOption("verbose"))
75a76,77
> if (length(bg) < k)
> bg <- rep(bg, length.out = k)
81c83,84
< pch = pch[1], col = col[1], cex = cex[1], ...)
---
> pch = pch[1], col = col[1], cex = cex[1], bg = bg[1],
> ...)
85c88
< pch = pch[i], col = col[i], cex = cex[i])
---
> pch = pch[i], col = col[i], cex = cex[i], bg = bg[i])
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] An offer: R packages in Gentoo Land?
On 28 June 2006 at 16:44, Allen S. Rout wrote: | | Greetings. I love R, we run Gentoo. I want to maintain R packages in | the same methods I use for the rest of them; in Gentoo this is in "the | portage tree", or in "a portage overlay". | | I am working towards something I consider suitable for production | release, and wanted to ask if there are conventional blessings which I | ought to ask of the R-devel folks; How does this usually go, in | R-land? With my Debian maintainer hat on, and noting that I in no way speak for R Core: it's really up to you. Here are a few things I do for Debian: -- supporting all configure options so that R reports all capabilities() -- passing 'make check' obviously helps -- having documentation in different format out of the box is nice -- supporting Atlas out of the box is nice (Debian has had that for years), -- having Sweave work out of the box is nice too, -- an additional r-mathlib packages was once requested, -- a few other goodies (bash completion, paperconf, conf files in /etc/R, R LIBS supporting different directories) More suggestions are of course welcome. | Separately, what is the maturity model you apply to CRAN submissions? | Is there any sort of new/unstable/stable/deprecated sort of cycle | already conventional? This might be a Fine Manual question, but the | Writing R Extensions doc doesn't mention it. Your package ought to survive 'R CMD check'. Hth, Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] UTF-8 and .Rd files
Prof Brian Ripley wrote:
> On Wed, 28 Jun 2006, Peter Dalgaard wrote:
>
>> Paul Gilbert <[EMAIL PROTECTED]> writes:
>>
>>> I've been following this thread hoping for the definitive answer...
>>>
>>> Peter Dalgaard wrote:
>>>
>>>
Well, I do tend to think that we should just use utf, assuming that
people have the relevant glyphs. If they don't, then they might get
little hollow rectangles but so what?
>>>
>
> Unfortunately, they might get nothing visible at all, and they might
> also get something completely wrong (happens on my Windows' X11 server
> on my laptop). This is not an R problem but a question of the quality
> of implementation of UTF-8. (Given the lack of UTF-8 fonts, I don't
> see the latter changing any time soon.)
>
> My comments (at UseR and to Göran) are intended to make people aware
> just how badly things can go wrong: it is up to the users to decide if
> transliteration is worse than the chance of mangling.
>
>>> My problem is that I put an ö in a reference in an Rd file, and now my
>>> builds fail on some of my systems. I can switch which systems work and
>>> which are broken, but I can not get it to work on all systems. I have
>>> spent way too much time trying to figure out what is wrong. So, wrt "so
>>> what", I need to choose between checking my packages on all the
>>> different systems I use, or having an ö in the Rd file. I think my
>>> problem is more complicated than having the relevant glyphs. I suspect
>>> it has to do with having the same locale on all systems doing NFS
>>> mounts, or on my cvs server, or something strange like that.
>>
>>
>> Just to clarify, one thing is what I feel should be the longer term
>> strategy, another is what the R build tools can currently do...
>>
>> Did you follow the advice to declare your input encoding with
>> \encoding and use \enc to provide a transliteration?
>
It has been several months since I did this, but I thought I had
followed all the instructions.
>
> It is necessary to do so. I use a mixture of UTF-8 and latin1 locales
> on systems sharing a file system, and it all works for me: iconv does
> the charset translations transparently provided it knows what to do.
Ok, I will try again sometime when I have a bit more time.
Thanks,
Paul
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] write.table does not quote col.names properly (PR#9044)
Full_Name: Michael Toews
Version: 2.3.1
OS: Mac OS 10.4.6 and WinXP/SP2
Submission from: (NULL) (24.80.163.133)
This bug also affects related functions (write.csv, etc.), and can be
demonstrated using either a matrix or data frame:
m <- matrix(1:9,nrow=3,
dimnames=list(c("A","B","C"),
c("I","II","III")))
write.table(m)
write.table(m,col.names=FALSE)
write.table(m,row.names=FALSE)
Note that the last 'write.table' call has unquoted column headers. A suggested
fix for this problem is:
Index: write.table.R
===
--- write.table.R (revision 38447)
+++ write.table.R (working copy)
@@ -86,9 +86,8 @@
if(!is.null(col.names)) {
if(append)
warning("appending column names to file")
- if(length(quote))
- col.names <- paste("\"", gsub('"', qstring, col.names),
- "\"", sep = "")
+ col.names <- paste("\"", gsub('"', qstring, col.names),
+ "\"", sep = "")
writeLines(paste(col.names, collapse = sep), file, sep = eol)
}
However, it is unknown why the "if(length(quote))" is used in the original code
(please check before a commit). The length of quote will be 0 here, since the
matrix has all numbers.
This bug does not occur with a data frame with mixed number and factor/character
columns.
+mt
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] advice on arguments
I have a general style question about R coding. Suppose I'm writing a function (foo1) that calls other functions (foo2, foo3, ...) which have complicated argument lists (e.g. optim(), plot()), _and_ I may be calling several different functions in the body of foo1. Since foo2 and foo3 have different sets of arguments, I can't just use "..." ; I did write some code a while ago that would look at formals() to dissect out arguments that should be passed to the different functions, but it seemed overly complex. The particular case I have now is a little simpler. foo2 (points3d) and foo3 (spheres3d) are both functions from the rgl package that pass arguments such as color, alpha, etc. along to an rgl.material() command with lots of possible arguments. (The function may also call segments3d or lines3d, but these all have the same arguments as points3d.) However, to change the size of points you use "size"; to change the size of spheres you use "radius". Do I (1) add "radius" to the argument list, cluttering up the argument list for one particular special case? (2) add "size" to the argument list, so that it doesn't become part of "..." and I can say spheres3d(radius=size,...) ? (3) do something like dotlist = list(...) if (type=="s" && !is.null(dotlist$size)) radius <- dotlist$size and pull "size" out of ... myself (and make a note to that effect in the documentation)? (I guess another general solution to this is to ask for lists of arguments, like MoreArgs in mapply(). Another would be to go back and change spheres3d to make size a synonym for radius ... ) any thoughts? Ben Bolker -- 620B Bartram Hall[EMAIL PROTECTED] Zoology Department, University of Floridahttp://www.zoo.ufl.edu/bolker Box 118525 (ph) 352-392-5697 Gainesville, FL 32611-8525 (fax) 352-392-3704 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] advice on arguments
On 6/29/2006 12:53 PM, Ben Bolker wrote: > I have a general style question about R coding. > >Suppose I'm writing a function (foo1) that calls other functions > (foo2, foo3, ...) which have complicated argument > lists (e.g. optim(), plot()), _and_ > I may be calling several different functions in the body of > foo1. Since foo2 and foo3 have different sets of arguments, I > can't just use "..." ; I did write some code a while ago that > would look at formals() to dissect out arguments that should > be passed to the different functions, but it seemed overly > complex. > > The particular case I have now is a little simpler. > > foo2 (points3d) and foo3 (spheres3d) > are both functions from the rgl package > that pass arguments such as color, alpha, etc. along to > an rgl.material() command with lots of possible arguments. > (The function may also call segments3d or lines3d, but > these all have the same arguments as points3d.) > However, to change the size of points you use "size"; to > change the size of spheres you use "radius". Do I > (1) add "radius" to the argument list, cluttering up > the argument list for one particular special case? > (2) add "size" to the argument list, so that it doesn't > become part of "..." and I can say spheres3d(radius=size,...) ? > (3) do something like > dotlist = list(...) > if (type=="s" && !is.null(dotlist$size)) radius <- dotlist$size > and pull "size" out of ... myself (and make a note to that > effect in the documentation)? > (I guess another general solution to this is to ask for > lists of arguments, like MoreArgs in mapply(). Another > would be to go back and change spheres3d to make size > a synonym for radius ... ) I would do (2) in general, but in this particular case it might not be right. "size" is measured in pixels, and "radius" is measured in data units, so they really are different things. You could try to fiddle it so the radius is set to the right number of units to match the number of pixels that were requested, but users can change the scale pretty easily. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] UTF-8 and .Rd files
Hi, Paul:
Earlier in this thread, Göran Broström wrote, "I really only need
non-ascii to write the name of the author (me) correctly."
The standard advice I got from a similar thread some time ago is to
use the 'vanilla' Latin alphabet for key words, file and function names,
etc., and restrict the use of other characters to documentation where
the consequences of problems are not so severe. I, too, would like to
see all the accents, Arabic script, Chinese characters, etc., that other
people want to use. However, we must work with the world as it is, not
as we would like it to be (while devoting some time where appropriate to
making the world better, as everyone who contributes to the R Project
does).
Best Wishes,
Spencer Graves
Paul Gilbert wrote:
> I've been following this thread hoping for the definitive answer...
>
> Peter Dalgaard wrote:
>
>> Well, I do tend to think that we should just use utf, assuming that
>> people have the relevant glyphs. If they don't, then they might get
>> little hollow rectangles but so what?
>
> My problem is that I put an ö in a reference in an Rd file, and now my
> builds fail on some of my systems. I can switch which systems work and
> which are broken, but I can not get it to work on all systems. I have
> spent way too much time trying to figure out what is wrong. So, wrt "so
> what", I need to choose between checking my packages on all the
> different systems I use, or having an ö in the Rd file. I think my
> problem is more complicated than having the relevant glyphs. I suspect
> it has to do with having the same locale on all systems doing NFS
> mounts, or on my cvs server, or something strange like that.
>
> Paul
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential inform...{{dropped}}
>
> __
> 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] UTF-8 and .Rd files
[Spencer Graves] > [...] I, too, would like to see all the accents, Arabic script, > Chinese characters, etc., that other people want to use. However, we > must work with the world as it is, not as we would like it to be > (while devoting some time where appropriate to making the world > better, as everyone who contributes to the R Project does). Granted and agreed. Yet, R already does already a little more than a few other programming languages in this area, and this is particularly sympathetic! :-) One could hope and wish that R developers, within reasonable efforts, continue making R better and even make it take some lead in this area. Not going fanatic about it of course, but at least, carefully avoiding any backward move in development, or changes that would be unfriendly to internationalisation of R. -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] advice on arguments
Hi Ben,
I have often asked myself such question and often
come back to the following additional options:
(4) Use '...' and ensure encapsulated functions/calls (foo2 and foo3) also
have '...' within their arguments. There is no problem to call 3dspehre with
a list of arguments that include both 'radius' and 'size' if (and only if)
3dsphere
function argumnts are (radius=,...) so that size will just be ignored.
foo1 <- function(...){
foo2(...)
foo3(...)
}
Document that all arguments foo2 can handle could be
introduced within a cool to foo1, as well as those foo3 arguments.
Only problem/point of detail is case where foo2 and foo3 do share
arguments and you would like to distinguish.
Then use (5)
foo1 <- function(x,foo2Args=list(radius=2), foo3Args=list(size), ...){
do.call("foo2",foo2Args)
# or do.call("foo2",c(foo2Args,list(...)) depending on what you prefer
}
Eric
2006/6/29, Ben Bolker <[EMAIL PROTECTED]>:
>
>
>I have a general style question about R coding.
>
> Suppose I'm writing a function (foo1) that calls other functions
> (foo2, foo3, ...) which have complicated argument
> lists (e.g. optim(), plot()), _and_
> I may be calling several different functions in the body of
> foo1. Since foo2 and foo3 have different sets of arguments, I
> can't just use "..." ; I did write some code a while ago that
> would look at formals() to dissect out arguments that should
> be passed to the different functions, but it seemed overly
> complex.
>
> The particular case I have now is a little simpler.
>
> foo2 (points3d) and foo3 (spheres3d)
> are both functions from the rgl package
> that pass arguments such as color, alpha, etc. along to
> an rgl.material() command with lots of possible arguments.
> (The function may also call segments3d or lines3d, but
> these all have the same arguments as points3d.)
> However, to change the size of points you use "size"; to
> change the size of spheres you use "radius". Do I
> (1) add "radius" to the argument list, cluttering up
> the argument list for one particular special case?
> (2) add "size" to the argument list, so that it doesn't
> become part of "..." and I can say spheres3d(radius=size,...) ?
> (3) do something like
>dotlist = list(...)
>if (type=="s" && !is.null(dotlist$size)) radius <- dotlist$size
> and pull "size" out of ... myself (and make a note to that
> effect in the documentation)?
> (I guess another general solution to this is to ask for
> lists of arguments, like MoreArgs in mapply(). Another
> would be to go back and change spheres3d to make size
> a synonym for radius ... )
>
> any thoughts?
>Ben Bolker
>
>
> --
> 620B Bartram Hall[EMAIL PROTECTED]
> Zoology Department, University of Floridahttp://www.zoo.ufl.edu/bolker
> Box 118525 (ph) 352-392-5697
> Gainesville, FL 32611-8525 (fax) 352-392-3704
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Eric Lecoutre
Consultant - Business & Decision
Business Intelligence & Customer Intelligence
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
