You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gilles Sadowski <gi...@harfang.homelinux.org> on 2012/06/09 02:00:42 UTC
[Math] HarmonicFitter and GaussianFitter
Hi.
I'm a bit annoyed that "HarmonicFitter" and "GaussianFitter" suffer from the
same design flaw as "PolynomialFitter", namely that it is possible to call
the non-overridden "fit" with an argument that is not of the right type
(i.e. "HarmonicOscillator.Parametric" and "Gaussian.Parametric",
respectively).
However we cannot simply remove them as in MATH-800, since those classes
perform non-trivial computations.
One possibility is to override the "fit" methods that should not be used,
and have them throw an exception.
What do you think?
Which exception would be most appropriate?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] HarmonicFitter and GaussianFitter
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
Hello.
> > [...]
> >>
> >> Then, we could keep "PolynomialFitter".
> >>
> >>
> >> OK for this change?
> >
> > OK.
> >
> > Luc
> >
> Sounds good to me!
Could you please have a look at "PolynomialFitter"? I'm not sure that it is
useful to select the degree of the polynomial at construction, as it is
currently done. Is there a reason?
I'd rather create a new "fit" method:
public double fit(double[] guess) {
return fit(new PolynomialFunction.Parametric(), guess);
}
and deduce the degree from the length of the "guess" array:
degree == guess.length - 1
If so, I'd then deprecate the constructor and the current "fit()" method.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] HarmonicFitter and GaussianFitter
Posted by Sébastien Brisard <se...@m4x.org>.
2012/6/9 Luc Maisonobe <Lu...@free.fr>:
> Le 09/06/2012 02:48, Gilles Sadowski a écrit :
>> On Sat, Jun 09, 2012 at 02:00:42AM +0200, Gilles Sadowski wrote:
>>> Hi.
>>>
>>> I'm a bit annoyed that "HarmonicFitter" and "GaussianFitter" suffer from the
>>> same design flaw as "PolynomialFitter", namely that it is possible to call
>>> the non-overridden "fit" with an argument that is not of the right type
>>> (i.e. "HarmonicOscillator.Parametric" and "Gaussian.Parametric",
>>> respectively).
>>> However we cannot simply remove them as in MATH-800, since those classes
>>> perform non-trivial computations.
>>> One possibility is to override the "fit" methods that should not be used,
>>> and have them throw an exception.
>>>
>>> What do you think?
>>> Which exception would be most appropriate?
>>
>> This doesn't work (I should have tested it before sending the message...).
>>
>> However, I think that using generics might solve the problem:
>> ---
>> public class CurveFitter<T extends ParametricUnivariateFunction>
>> ---
>>
>> And thus
>> ---
>> public class GaussianFitter extends CurveFitter<Gaussian.Parametric>
>> ---
>>
>> Then, we could keep "PolynomialFitter".
>>
>>
>> OK for this change?
>
> OK.
>
> Luc
>
Sounds good to me!
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] HarmonicFitter and GaussianFitter
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 09/06/2012 02:48, Gilles Sadowski a écrit :
> On Sat, Jun 09, 2012 at 02:00:42AM +0200, Gilles Sadowski wrote:
>> Hi.
>>
>> I'm a bit annoyed that "HarmonicFitter" and "GaussianFitter" suffer from the
>> same design flaw as "PolynomialFitter", namely that it is possible to call
>> the non-overridden "fit" with an argument that is not of the right type
>> (i.e. "HarmonicOscillator.Parametric" and "Gaussian.Parametric",
>> respectively).
>> However we cannot simply remove them as in MATH-800, since those classes
>> perform non-trivial computations.
>> One possibility is to override the "fit" methods that should not be used,
>> and have them throw an exception.
>>
>> What do you think?
>> Which exception would be most appropriate?
>
> This doesn't work (I should have tested it before sending the message...).
>
> However, I think that using generics might solve the problem:
> ---
> public class CurveFitter<T extends ParametricUnivariateFunction>
> ---
>
> And thus
> ---
> public class GaussianFitter extends CurveFitter<Gaussian.Parametric>
> ---
>
> Then, we could keep "PolynomialFitter".
>
>
> OK for this change?
OK.
Luc
>
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [Math] HarmonicFitter and GaussianFitter
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Sat, Jun 09, 2012 at 02:00:42AM +0200, Gilles Sadowski wrote:
> Hi.
>
> I'm a bit annoyed that "HarmonicFitter" and "GaussianFitter" suffer from the
> same design flaw as "PolynomialFitter", namely that it is possible to call
> the non-overridden "fit" with an argument that is not of the right type
> (i.e. "HarmonicOscillator.Parametric" and "Gaussian.Parametric",
> respectively).
> However we cannot simply remove them as in MATH-800, since those classes
> perform non-trivial computations.
> One possibility is to override the "fit" methods that should not be used,
> and have them throw an exception.
>
> What do you think?
> Which exception would be most appropriate?
This doesn't work (I should have tested it before sending the message...).
However, I think that using generics might solve the problem:
---
public class CurveFitter<T extends ParametricUnivariateFunction>
---
And thus
---
public class GaussianFitter extends CurveFitter<Gaussian.Parametric>
---
Then, we could keep "PolynomialFitter".
OK for this change?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org