Martin Maechler wrote:
>>>>>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>>>>>> 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([EMAIL PROTECTED]))
[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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
