From: Martin Maechler <maechler_at_stat.math.ethz.ch>

Date: Tue, 26 Jun 2007 22:28:38 +0200

* >>
*

> {on R-help}

* >>
*

MM> They have not yet.

* >>
*

* >>
*

* >>
*

>> 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;
*

R-devel_at_r-project.org mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue 26 Jun 2007 - 20:40:13 GMT

Date: Tue, 26 Jun 2007 22:28:38 +0200

>>>>> "JMC" == John Chambers <jmc_at_r-project.org> >>>>> on Tue, 26 Jun 2007 14:47:25 -0400 writes:

JMC> Martin Maechler wrote: >>>>>>> "MM" == Martin Maechler <maechler_at_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 ...

JMC> Well, it depends what you mean by "bug"; I would call JMC> it a "design infelicity" (a la Bill Venables), and some JMC> might call it a failure to Do What I Mean. Assuming I JMC> understand what you meant (you didn't give an example) JMC> I disagree with the letter but very much agree with the JMC> spirit. JMC> In fact, log10 _is_ in the Math group. But the JMC> programmer is currently responsible for creating a JMC> suitable generic function (that's the designJMC> infelicity). If that is done correctly, dispatch seems JMC> to work fine:

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

JMC> [1] "log10"

yes, indeed. Embarrassingly, actually I did know about this, and indeed, it's not a bug.

>> setClass("onX", representation(x="numeric", stuff =

* >> "character"))
*

JMC> [1] "onX"

>> setMethod("Math", "onX", function(x)callGeneric(x@x))

JMC> [1] "Math"

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

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

>> showMethods("log10")

JMC> Function: log10 (package base) x="ANY" x="integer" JMC> (inherited from: x="ANY") x="onX" (definition from JMC> function "Math") JMC> So unless you mean something different by "does not S4- JMC> dispatch", this is not technically a bug. Your bug JMC> presumably came when you either did not callJMC> setGeneric() on log10() or else called it in the simple JMC> setGeneric("log10") form.

you are right.

JMC> But in principle I very much agree that this is not a JMC> satisfactory situation. It should be implicit in the JMC> definition of log10() that when it is made a generic, JMC> that generic has group "Math". The reason it must now JMC> be done by the programmer is that log10() is not a JMC> primitive, and so not covered by the automatic JMC> definition of a generic that, e.g., applies to sin(). JMC> I have a proposal to fix this, by generalizing the JMC> mechanism used for primitives in base, so that it would JMC> allow any function in any package to have an implicit JMC> generic form. When a method is specified for theJMC> function, the implicit generic becomes the actual JMC> function.

That sounds like a very good idea, allowing the function writer to specify (if and) how the function should behave as generic.

JMC> Sometime after 2.5.1 comes out, this should JMC> with luck find its way to r-devel so we can see if it JMC> helps.

So, I'm hoping for good luck.. ;-) :-)

Thanks a lot, John!

Martin

>> 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
*

R-devel_at_r-project.org mailing list

https://stat.ethz.ch/mailman/listinfo/r-devel Received on Tue 26 Jun 2007 - 20:40:13 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 Wed 27 Jun 2007 - 06:35:52 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.
*