This is a 'White Book' function, not really ours to re-design.
(Although the glm help page in the White Book's description of '...' never
was correct of any S-PLUS that I used, and doesn't make a great deal of
sense.)
I never really saw the point of glm.control(), but it might have allowed
for
> hw> That seems a perfectly good reason not to use ... - but
> hw> if you are going to use ... it seems like you shouldn't
> hw> warn on mismatched argument names.
>
> I disagree.
>
> One "famous" example on this was -- in S-plus, early 1990s --
> known about S users back then, and it
> "hw" == hadley wickham <[EMAIL PROTECTED]>
> on Tue, 29 Jan 2008 09:26:24 -0600 writes:
>> > Or is this a bug in glm? It certainly seems that the
>> documentation > should mention that ... is passed to
>> glm.control, which only takes > three arguments. I
>> realise
> > Or is this a bug in glm? It certainly seems that the documentation
> > should mention that ... is passed to glm.control, which only takes
> > three arguments. I realise that this doesn't come up very often
> > during an interactive model fitting session, and it is easy to remedy
> > when it d
I tried to do this a couple of years ago, cf. doCall() in R.utils.
It's quite a tricky problem and I recall I wasn't perfectly happy with
the solution but it's a start.
/Henrik
On Jan 28, 2008 6:19 PM, hadley wickham <[EMAIL PROTECTED]> wrote:
> Has anyone developed a version of do.call that is s
On Mon, 28 Jan 2008, hadley wickham wrote:
> Maybe this function won't actually be the help I had hoped it would
> be. Unfortunately some functions (e.g. glm via glm.control) throw
> errors when ... contain arguments that don't match some (eventual)
> argument list.
>
> Or is this a bug in glm?
Maybe this function won't actually be the help I had hoped it would
be. Unfortunately some functions (e.g. glm via glm.control) throw
errors when ... contain arguments that don't match some (eventual)
argument list.
Or is this a bug in glm? It certainly seems that the documentation
should mentio
Has anyone developed a version of do.call that is safe in the sense
that it silently drops parameters that do not appear in the formals of
the called function? This is useful when ... ends up being used in
multiple further functions. e.g.
f <- function(a, b) {a + b}
do.call(f, list(a=1, b=2, c=3)
