I intend to add a mode function for the Cauchy Distribution. It is a small
addition which i thought might be helpful. Thanks |
Hi Udit.
Le jeu. 9 mai 2019 à 12:52, Udit Arora <[hidden email]> 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: [hidden email] For additional commands, e-mail: [hidden email] |
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. 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 <[hidden email]> wrote: > Hi Udit. > > Le jeu. 9 mai 2019 à 12:52, Udit Arora <[hidden email]> 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: [hidden email] > For additional commands, e-mail: [hidden email] > > |
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, <[hidden email]> 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. > > 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 <[hidden email]> > wrote: > > > Hi Udit. > > > > Le jeu. 9 mai 2019 à 12:52, Udit Arora <[hidden email]> 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: [hidden email] > > For additional commands, e-mail: [hidden email] > > > > > |
Awesome!
On Thu, May 9, 2019 at 10:44 AM Udit Arora <[hidden email]> 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, <[hidden email]> > 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. > > > > 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 <[hidden email]> > > wrote: > > > > > Hi Udit. > > > > > > Le jeu. 9 mai 2019 à 12:52, Udit Arora <[hidden email]> 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: [hidden email] > > > For additional commands, e-mail: [hidden email] > > > > > > > > > |
> On 9 May 2019, at 21:17, Eric Barnhill <[hidden email]> wrote: > > Awesome! > > On Thu, May 9, 2019 at 10:44 AM Udit Arora <[hidden email]> 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, <[hidden email]> >> 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 <[hidden email]> >>> wrote: >>> >>>> Hi Udit. >>>> >>>> Le jeu. 9 mai 2019 à 12:52, Udit Arora <[hidden email]> 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: [hidden email] >>>> For additional commands, e-mail: [hidden email] >>>> >>>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
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, <[hidden email]> wrote: > > > > On 9 May 2019, at 21:17, Eric Barnhill <[hidden email]> wrote: > > > > Awesome! > > > > On Thu, May 9, 2019 at 10:44 AM Udit Arora <[hidden email]> > 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, <[hidden email]> > >> 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 <[hidden email]> > >>> wrote: > >>> > >>>> Hi Udit. > >>>> > >>>> Le jeu. 9 mai 2019 à 12:52, Udit Arora <[hidden email]> 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: [hidden email] > >>>> For additional commands, e-mail: [hidden email] > >>>> > >>>> > >>> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
Hi.
Le ven. 10 mai 2019 à 14:45, Udit Arora <[hidden email]> a écrit : > > 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.. If you don't see a reason, it's reason enough for not doing it. ;-) Perhaps a more straightforward way to start contributing is to browse the list of open issue issues; see e.g. the "Numbers" project[1]. Help is most needed to progress towards a release, because "Statistics", and others, depend on it. Regards, Gilles [1] https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20status%20%3D%20Open > > On Fri, 10 May 2019, 2:15 am Alex Herbert, <[hidden email]> wrote: > > > > > > > > On 9 May 2019, at 21:17, Eric Barnhill <[hidden email]> wrote: > > > > > > Awesome! > > > > > > On Thu, May 9, 2019 at 10:44 AM Udit Arora <[hidden email]> > > 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, <[hidden email]> > > >> 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 <[hidden email]> > > >>> wrote: > > >>> > > >>>> Hi Udit. > > >>>> > > >>>> Le jeu. 9 mai 2019 à 12:52, Udit Arora <[hidden email]> 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: [hidden email] > > >>>> For additional commands, e-mail: [hidden email] > > >>>> > > >>>> > > >>> > > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Ok sir.
Thanks On Sun, 12 May 2019, 2:39 am Gilles Sadowski, <[hidden email]> wrote: > Hi. > > Le ven. 10 mai 2019 à 14:45, Udit Arora <[hidden email]> a écrit : > > > > 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.. > > If you don't see a reason, it's reason enough for not doing it. ;-) > > Perhaps a more straightforward way to start contributing is to > browse the list of open issue issues; see e.g. the "Numbers" > project[1]. Help is most needed to progress towards a release, > because "Statistics", and others, depend on it. > > Regards, > Gilles > > [1] > https://issues.apache.org/jira/issues/?jql=project%20%3D%20NUMBERS%20AND%20status%20%3D%20Open > > > > > On Fri, 10 May 2019, 2:15 am Alex Herbert, <[hidden email]> > wrote: > > > > > > > > > > > > On 9 May 2019, at 21:17, Eric Barnhill <[hidden email]> > wrote: > > > > > > > > Awesome! > > > > > > > > On Thu, May 9, 2019 at 10:44 AM Udit Arora <[hidden email]> > > > 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, <[hidden email] > > > > > >> 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 < > [hidden email]> > > > >>> wrote: > > > >>> > > > >>>> Hi Udit. > > > >>>> > > > >>>> Le jeu. 9 mai 2019 à 12:52, Udit Arora <[hidden email]> 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: [hidden email] > > > >>>> For additional commands, e-mail: [hidden email] > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [hidden email] > > > For additional commands, e-mail: [hidden email] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > |
Free forum by Nabble | Edit this page |