From: John Chambers <jmc_at_r-project.org>

Date: Tue, 26 Jun 2007 14:47:25 -0400

R-devel_at_r-project.org mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue 26 Jun 2007 - 18:55:07 GMT

Date: Tue, 26 Jun 2007 14:47:25 -0400

Martin Maechler wrote:

>>>>>> "MM" == Martin Maechler <maechler@stat.math.ethz.ch>

*>>>>>> on Sat, 23 Jun 2007 00:36:43 +0200 writes:
**>>>>>>
**>
**> {on R-help}
**>
**> [.....................]
**> [.....................]
**>
**> >> Duncan Murdoch
**>
**> DM> You might have better luck with
**>
**> DM> log1p(tasa)
**>
**> MM> {very good point, thank you, Duncan!}
**>
**> DM> if the authors of the Matrix package have written a
**> DM> method for log1p(); if not, you'll probably have to do
**> DM> it yourself.
**>
**> MM> They have not yet.
**>
**> MM> Note however that this - and expm1() - would
**> MM> automagically work for sparse matrices if these two
**> MM> functions were part of the "Math" S4 group generic.
**>
**> MM> I'd say that there's only historical reason for them
**> MM> *not* to be part of "Math", and I am likely going to
**> MM> propose to change this ....
**>
**> I'm now going to propose ...
**>
**> As I found, expm1() and log1p() already *HAVE BEEN*
**> in the S3 "Math" group generic
**> ``automagically by implementation''.
**> Just the documentation for this fact has been missing.
**>
**> Hence, I've added that doc (uncommitted) and I'm about to add
**> them to the S4 Math group as well. When doing so, I'd like to
**> add few more functions to make S3 and S4 "Math" a bit more compatible :
**> Consequently, I'm proposing to add the following functions to the S4 Math
**> group generic :
**>
**> - log1p, expm1
**>
**> - cummax, cummin {S3 has them; cumprod(), cumsum() are already}
**>
**> - digamma, trigamma {S3 has them; gamma(), lgamma() are already}
**>
**> ----
**>
**> When trying to do the above,
**> I'm pretty quickly successful for cummax & cummin,
**> most probably because they are primitive functions.
**> But I currently have problems for the other four,
**> and in exploring these problems,
**> I've found that
**>
**> log10()
**>
**> does not S4- dispatch on "Math" neither,
**> which I think is a pretty peculiar bug;
**>
*

Well, it depends what you mean by "bug"; I would call it a "design
infelicity" (a la Bill Venables), and some might call it a failure to Do
What I Mean. Assuming I understand what you meant (you didn't give an
example) I disagree with the letter but very much agree with the spirit.

In fact, log10 _is_ in the Math group. But the programmer is currently responsible for creating a suitable generic function (that's the design infelicity). If that is done correctly, dispatch seems to work fine:

> setGeneric("log10", group = "Math")

[1] "log10"

> setClass("onX", representation(x="numeric", stuff = "character"))
[1] "onX"

> setMethod("Math", "onX", function(x)callGeneric(x_at_x))
[1] "Math"

> xx = new("onX", x=1:10, stuff = "test")
> log10(xx)

[1] 0.0000000 0.3010300 0.4771213 0.6020600 0.6989700 0.7781513 0.8450980
[8] 0.9030900 0.9542425 1.0000000

> showMethods("log10")

Function: log10 (package base)

x="ANY"

x="integer"

(inherited from: x="ANY")

x="onX"

(definition from function "Math")

So unless you mean something different by "does not S4- dispatch", this is not technically a bug. Your bug presumably came when you either did not call setGeneric() on log10() or else called it in the simple setGeneric("log10") form.

But in principle I very much agree that this is not a satisfactory situation. It should be implicit in the definition of log10() that when it is made a generic, that generic has group "Math". The reason it must now be done by the programmer is that log10() is not a primitive, and so not covered by the automatic definition of a generic that, e.g., applies to sin().

I have a proposal to fix this, by generalizing the mechanism used for primitives in base, so that it would allow any function in any package to have an implicit generic form. When a method is specified for the function, the implicit generic becomes the actual function. Sometime after 2.5.1 comes out, this should with luck find its way to r-devel so we can see if it helps.

> I think if that was fixed, then my code changes would also work

*> to make log1p(), expm1(), digamma() and trigamma() correctly
**> part of "S4 - Math Group".
**>
**>
**> Martin
**>
**>
*

[[alternative HTML version deleted]]

R-devel_at_r-project.org mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue 26 Jun 2007 - 18:55:07 GMT

Archive maintained by Robert King, hosted by
the discipline of
statistics at the
University of Newcastle,
Australia.

Archive generated by hypermail 2.2.0, at Tue 26 Jun 2007 - 21:35:54 GMT.

*
Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel.
Please read the posting
guide before posting to the list.
*