I am not sure what to say.. I completely agree that most distributions have undefined statistical values. I dont really have any particular reason for adding mode in the interface like one mentioned by Sir Alex for mean and variance. Please let me know if I should go ahead..
On Fri, 10 May 2019, 2:15 am Alex Herbert, <alex.d.herb...@gmail.com> wrote: > > > > 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 > >
