

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@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]]

