[Rd] "Math" group generics for S4, and a bug

[Martin Maechler]

>>>>> "BDR" == Prof Brian Ripley <ripley at stats.ox.ac.uk>
>>>>>     on Tue, 26 Jun 2007 18:38:27 +0100 (BST) writes:

    BDR> Remember that you only get S4 dispatch on Math for S4
    BDR> generics.  log10 is not an S4 generic until you make it
    BDR> one.  From the help page

    BDR>       Note: currently those members which are not
    BDR> primitive functions must have been converted to S4
    BDR> generic functions (preferably _before_ setting an S4
    BDR> group generic method) as it only sets methods for known
    BDR> S4 generics.  This can be done by a call to
    BDR> 'setGeneric', for example 'setGeneric("round",
    BDR> group="Math2")'.

    BDR> Had you done that (it is not mentioned)?

no. embarrassing, since I "once" new about it
(had to do that in the Matrix package)...

    >> From my notes about S4 issues sent to R core a while
    >> back:

    BDR> 1) Setting methods on a group generic only sets methods
    BDR> for existing generics, and only primitives are ab
    BDR> initio generic.

    BDR>     ?setGeneric and ?Arith differ as to how other
    BDR> members should be converted into generics (one arg or
    BDR> two), and the example (setGeneric("+")) seems pointless
    BDR> as that is already generic.

    BDR>     Whereas all of Ops (and its subgroups) and Complex
    BDR> are ab initio generic, none of Summary is and log,
    BDR> log10, gamma, lgamma, round, signif and trunc are not.

    BDR>     The discrepancies between the S3 and S4 group
    BDR> generics are hard to explain: sign, digamma, trigamma
    BDR> and gammaCody are S3 group generic but not S4 group
    BDR> generic (and sign is S4 generic).  log10 is S4 group
    BDR> generic but log2 is not.  This is probably all history,
    BDR> but not at all obvious to end users.

    BDR> so the issue has been raised before.

Indeed.  Thanks a lot, Brian!
Martin

    BDR> On Tue, 26 Jun 2007, 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 ...
    >> 
    >> 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; 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
    >> 

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
    BDR> Professor of Applied Statistics,
    BDR> http://www.stats.ox.ac.uk/~ripley/ University of
    BDR> Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road,
    BDR> +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865
    BDR> 272595