Hi Seth and John,
Thank you for your helpful responses,
>John Chambers <[EMAIL PROTECTED]> writes:
>>From your description of the application, it sounds like you would be
>>better off just forcing "+" to behave as you want. Using inheritance is
>>a much more powerful mechanism & can introduce results you don't want,
>>as it seems to have in this case.
>>
>>An important point about using inheritance is that the subclass is a
>>asserted to be substitutable for the superclass for ALL purposes. This
>>applies whether using "contains=" or setIs().
I am not sure whether I got the meaning of "substitutable for the
superclass for ALL purposes" :
In the application I sketched, any Exp(rate = lambda) distribution
really /is/ a Gammad(shape = 1, scale = 1/lambda) distribution;
so my understanding is that "Exp" is substitutable for "Gammad"
for ALL purposes.
"Gammad" was not designed to be the motherclass to "Exp" right
from the beginning because the same 'is'-relation also applies to
"Weibull": any Exp(rate = lambda) distribution /is/ a
Weibull(shape = 1, scale = 1/lambda) distribution.
Does "substitutable for the superclass for ALL purposes"
mean 'without ambiguity' (as might enter through Weibull/Gammad)?
>>When the focus is on a particular function, it's usually better to
>>implement methods for that function, maybe along with setAs()
>>methods--not setIs().
You mean I should not leave the coercion decision up to the dispatching
mechanism?
>>It seems likely that such a solution would be cleaner in design, not to
>>mention that it would likely work. (see also suggestion below)
Yes, your indication does work; thank you!
>>Peter Ruckdeschel <[EMAIL PROTECTED]> writes:
>>>Of course, I could also declare explicitly "+" methods for signatures
>>>c("Exp", "Exp"), c("Exp", "Gammad"), and c("Gammad", "Exp") in
>>>which I would then use as(.) to coerce "Exp" to "Gammad"
>>> (and again the same procedure for further Gamma-methods).
>>>
>>>But, this would create an extra (3 or possibly much more) methods
>>>to dispatch, and I doubt whether this really is the preferred
>>>solution.
>>>
>> Why not?
It simply did not seem to me elegant to have three calls to
setMethod() doing more or less the same thing.
I thought that, as elegant as R solutions from the R core are
most times, there should be some mechanism to avoid this
threefold code---and in fact you indicated how to---
thank you!
>> And you can avoid some of the extra methods by defining a
>> virtual class that is the union of the classes for which you
>> want the new methods.
>>
>> Something like (untested code!)
>>
>> setClassUnion("analyticConvolution", c("Exp", "Gammad"))
>> setMethod("+", c("analyticConvolution", "analyticConvolution"),
>> ....)
Seth Falcon <[EMAIL PROTECTED]> writes:
> Why class union here and not an abstract superclass?
Am I right: the class generated by setClassUnion() does not
enter the inheritance tree / mechanism?
setClassUnion()---at least in my case---solves the problem;
thank you again.
[snip]
Peter
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
