You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sébastien Brisard <se...@m4x.org> on 2012/02/09 08:46:30 UTC
[math] Package transform revisited
Hi,
while working on MATH-732, I've made some amendments to the
FastFourierTransformer API. Basically, I've removed the factory
methods create() and createUnitary() I had previously introduced in
MATH-677. Instead, I introduced an enum {STANDARD, UNITARY}. This
allows the specification of the type of normalization to be applied in
the *static* method transformInPlace. Indeed, I do not like boolean
parameters, plus, they are limited to only two types of
normalizations. If we ever wanted to introduce a third (unlikely)
normalization, that would no longer work. Enums are much easier to
read.
If you like these changes, I propose to do the same for all classes in
package transform. This would mean that I reopen MATH-677 for a brief
period of time. This is probably sub-optimal in a prerelease period,
so it's really your call.
One last change I'm considering would be to introduce an enum
TransformType{FORWARD, INVERSE}, and replace the methods
- transform(double[])
- inverseTransform(double[])
with transform(double[], TransformType).
What do you think?
Sébastien
PS: thinking about it, maybe I should create a new JIRA ticket
altogether, instead of reopening MATH-677.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Package transform revisited
Posted by Sébastien Brisard <se...@m4x.org>.
Dear all,
2012/2/9 Gilles Sadowski <gi...@harfang.homelinux.org>:
> On Thu, Feb 09, 2012 at 11:02:36AM +0100, Luc Maisonobe wrote:
>> Le 09/02/2012 10:50, Sébastien Brisard a écrit :
>> > Hi Luc,
>> >>
>> >> I agree with you, enums are much better. There are other places in
>> >> [math] where we use boolean or even ints for such things. They mainly
>> >> came for pre-java 5 era when enums where not available.
>> >>
>> >> Luc
>> >>
>> > And what do you think of replacing
>> > - transform(double[]) with transform(double[], FORWARD)
>> > - inverseTransform(double[]) with transform(double[], INVERSE)
>> > (also using enums) ?
>>
>> It's good too.
>
> +1
>
> Gilles
>
Please have a look to some comments I've made in MATH-743, if you can
spare some time.
Best regards,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Package transform revisited
Posted by Gilles Sadowski <gi...@harfang.homelinux.org>.
On Thu, Feb 09, 2012 at 11:02:36AM +0100, Luc Maisonobe wrote:
> Le 09/02/2012 10:50, Sébastien Brisard a écrit :
> > Hi Luc,
> >>
> >> I agree with you, enums are much better. There are other places in
> >> [math] where we use boolean or even ints for such things. They mainly
> >> came for pre-java 5 era when enums where not available.
> >>
> >> Luc
> >>
> > And what do you think of replacing
> > - transform(double[]) with transform(double[], FORWARD)
> > - inverseTransform(double[]) with transform(double[], INVERSE)
> > (also using enums) ?
>
> It's good too.
+1
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Package transform revisited
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 09/02/2012 10:50, Sébastien Brisard a écrit :
> Hi Luc,
>>
>> I agree with you, enums are much better. There are other places in
>> [math] where we use boolean or even ints for such things. They mainly
>> came for pre-java 5 era when enums where not available.
>>
>> Luc
>>
> And what do you think of replacing
> - transform(double[]) with transform(double[], FORWARD)
> - inverseTransform(double[]) with transform(double[], INVERSE)
> (also using enums) ?
It's good too.
Luc
> In fact, at the lowest level, all transforms are coded this way (a
> boolean is passed to specifiy whether or not the inverse is to be
> computed). So maybe the higher level methods should also do so.
> Sébastien
>
>
> ---------------------------------------------------------------------
> 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] Package transform revisited
Posted by Sébastien Brisard <se...@m4x.org>.
Hi Luc,
>
> I agree with you, enums are much better. There are other places in
> [math] where we use boolean or even ints for such things. They mainly
> came for pre-java 5 era when enums where not available.
>
> Luc
>
And what do you think of replacing
- transform(double[]) with transform(double[], FORWARD)
- inverseTransform(double[]) with transform(double[], INVERSE)
(also using enums) ?
In fact, at the lowest level, all transforms are coded this way (a
boolean is passed to specifiy whether or not the inverse is to be
computed). So maybe the higher level methods should also do so.
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Package transform revisited
Posted by Luc Maisonobe <Lu...@free.fr>.
Le 09/02/2012 08:46, Sébastien Brisard a écrit :
> Hi,
> while working on MATH-732, I've made some amendments to the
> FastFourierTransformer API. Basically, I've removed the factory
> methods create() and createUnitary() I had previously introduced in
> MATH-677. Instead, I introduced an enum {STANDARD, UNITARY}. This
> allows the specification of the type of normalization to be applied in
> the *static* method transformInPlace. Indeed, I do not like boolean
> parameters, plus, they are limited to only two types of
> normalizations. If we ever wanted to introduce a third (unlikely)
> normalization, that would no longer work. Enums are much easier to
> read.
> If you like these changes, I propose to do the same for all classes in
> package transform. This would mean that I reopen MATH-677 for a brief
> period of time. This is probably sub-optimal in a prerelease period,
> so it's really your call.
> One last change I'm considering would be to introduce an enum
> TransformType{FORWARD, INVERSE}, and replace the methods
> - transform(double[])
> - inverseTransform(double[])
> with transform(double[], TransformType).
> What do you think?
I agree with you, enums are much better. There are other places in
[math] where we use boolean or even ints for such things. They mainly
came for pre-java 5 era when enums where not available.
Luc
>
> Sébastien
>
> PS: thinking about it, maybe I should create a new JIRA ticket
> altogether, instead of reopening MATH-677.
>
>
> ---------------------------------------------------------------------
> 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