> On 9 May 2019, at 21:17, Eric Barnhill <ericbarnh...@gmail.com> wrote:
>
> Awesome!
>
> On Thu, May 9, 2019 at 10:44 AM Udit Arora <udit18...@iiitd.ac.in> wrote:
>
>> I will see what I can do. It will take some time, but I will get to know
>> more about the other distributions.
>>
>>
>> On Thu, 9 May 2019, 10:58 pm Eric Barnhill, <ericbarnh...@gmail.com>
>> wrote:
>>
>>> Udit, is it clear what to do here? Gilles recommends you propose some
>> edits
>>> to ContinuousDistribution instead, to return Mode and Median.
>>>
>>> But then, if an interface is altered, all the classes that implement that
>>> interface need to have these functions added, so we hope you are up for
>> all
>>> that additional work. We can help you.
I think it would be prudent to go through all the distributions and see what is
defined for each. Wikipedia has a helper table for all its distributions
containing:
Mean
Median
Mode
Variance
Skewness
Ex. kurtosis
Entropy
Fisher Information
If many are undefined then you are adding to an interface something not
generally supported.
Currently the ContinuousDistribution interface only has the mean and the
variance. But note that these are used by the inverse cumulative probability
method in the base abstract class. Same goes for the DiscreteDistribution.
I am +0 for adding more methods. I don’t see a reason not to. But nor do I see
a need (within the library) to have them at the interface level if the mode or
median for example are not required in a generic way.
>>>
>>> Last is the idea of accessor methods. if the method starts with get_()
>> then
>>> in principle this is just returning a field already present. But with
>> that
>>> in mind, I don't know why we already have a method name like getMean() in
>>> this interface. We don't really know whether for a given distribution,
>> that
>>> would be a true accessor or need to be calculated. So I think all these
>>> method names should just be mean(), mode(), median(), etc.
>>>
>>> So sorry if this is blowing up into more work than you expected. It often
>>> works that way! I certainly think these changes are worthwhile however.
>>>
>>>
>>>
>>> On Thu, May 9, 2019 at 7:17 AM Gilles Sadowski <gillese...@gmail.com>
>>> wrote:
>>>
>>>> Hi Udit.
>>>>
>>>> Le jeu. 9 mai 2019 à 12:52, Udit Arora <udit18...@iiitd.ac.in> a
>> écrit :
>>>>>
>>>>> I intend to add a mode function for the Cauchy Distribution. It is a
>>>> small
>>>>> addition which i thought might be helpful.
>>>>
>>>> How will it be helpful? I.e. what would an application developer
>>>> be able to do, that he can't with the current code?
>>>>
>>>> You've surely noted that that the class you want to modify is but
>>>> one of the implementations of the interface "ContinuousDistribution".
>>>> So if you propose to change the API, the change should be done
>>>> at the interface level, and the appropriate computation performed, or
>>>> method overloads defined, for all implementations.
>>>>
>>>> The "accessor" methods refer to fields that were set by the contructor;
>>>> e.g. for "CauchyDistribution", "median" and "scale".
>>>> In this case, it happens that "mode" has the same value as "median",
>>>> but does this warrant an additional method?
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>>> Thanks
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
