You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2007/05/14 01:33:57 UTC
[math] Release planning, IOC-friendlyness
I think that modulo some cleanup, testing and review and the one
dangling item below, we should be ready for a [math] release. I will
RM if no one else wants to, but would appreciate it (and support by
sharing gruntwork) if someone else volunteers. Here are some
questions to resolve in the release plan:
1. Is this 1.2 or 2.0? There is so much in the added Mantissa
classes that 2.0 makes sense from a functionality standpoint. On the
other hand, we have not broken backward compatibility with anything
(yet) and if we decide to go 2.0, we could consider some API change.
My vote is to keep compatibility in place, but still name it 2.0.
2. What if anything should we add to make "pluggability" as designed
in the library compatible with IOC frameworks? It won't work to add
setters for the main factories, since we use the static getInstance
factory pattern (see e.g. UnivariateRealSoverFactory). What might
make more sense would be to add setters for the individual solvers in
e.g. UnivariateRealSoverFactoryImpl. Any ideas on how best to attack
this? For those not familiar with [math] who may have ideas, the
basic setup is that we use abstract factories with static getInstance
methods that return concrete factories looked up using
commons-discovery. The concrete factories themselves source multiple
different object types .
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Release planning, IOC-friendlyness
Posted by Phil Steitz <ph...@gmail.com>.
> I agree with the DescriptiveStatistics class (except the fact the
> serialVersionUID should be uptdated). I think DescriptiveStatisticsImpl
> should be deprecated (also the import for ResizableDoubleArray that
> remains in this stripped down class is not useful anymore).
>
Thanks, Luc. I fixed these things and noticed a couple more problems.
First, the lazy initialization setup would break thread safety of
SynchronizedDescriptiveStatistics, so I eliminated that. Second, I
had neglected to modify getPercentile() to use the configured
implementation. This creates a challenge, because evaluating a
percentile is really a two argument operation. Percentile has a
setQuantile method that needs to be activated before evaluate (a sort
of smelly setup, but what we implemented in 1.0 and we have to live
with). So implementations have to support this. I am not in love
with the reflection-based approach that I took to get this to work and
am open to suggestions for how to handle this better.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Release planning, IOC-friendlyness
Posted by Luc Maisonobe <Lu...@free.fr>.
Phil Steitz wrote:
> On Sep 3, 2007 8:33 AM, Phil Steitz <ph...@gmail.com> wrote:
>> On 9/2/07, Luc Maisonobe <Lu...@free.fr> wrote:
>>> On 2007-05-15, Phil Steitz wrote:
>>>
>>>> I agree. So, probably best is to deprecate the current abstract
>>>> factories and move to single concrete factories with impl setters for
>>>> IOC support. The concrete factories exist already, so it may just be
>>>> a matter of deprecation and possibly renaming some things. Here
>>>> again, we could deprecate in 1.2, remove in 2.0. Lets step back and
>>>> reexamine the overall setup and introduce a better approach. All ideas
>>>> / suggestions welcome. Consistency is important, though, so whatever
>>>> we decide on, lets be consistent in distributions, solvers, etc.
>>> I am working on a new UnknownDistributionChiSquareTest interface
>>> concerning issue https://issues.apache.org/jira/browse/MATH-160, and I
>>> have to find the proper way to create instances. We talk about factories
>>> and deprecation, and I think there are still issues.
>>>
>>> I think deprecating the abstract factories and using only the concrete
>>> implementations would not be wise, it seems strange to have a
>>> non-deprecated class extend a deprecated one. We should better remove
>>> the "abstract" qualifier and simply push the concrete code up. Then we
>>> can add the setters in these single factories for IOC concerns. The
>>> current XxxFactoryImpl classes would then become empty and would be
>>> deprecated. Does this seem sensible to everybody ?
>>>
>
> Sorry for the delay in getting back to this. I just committed
> (r598133) an attempt at this for DescriptiveStatistics /
> DescriptiveStatisticsImpl. Pls any [math] or other interested parties
> have a look. I can roll it back if there are objections or better
> ideas. Clirr complained about removing fields from the now deprecated
> subclass, but these are protected in the parent, so I don't see this
> as an issue. I took care to keep the argumentless constructor in
> DescriptiveStatistics empty so it would not cause problems for
> subclasses (we have an example in ListUnivariateImpl in /test) and I
> can't think of other compatability issues. It is quite possible that
> clirr and I are both missing something, though, so I would appreciate
> a careful look.
>
> If all are OK with this approach, I will do the same thing for
> SummaryStatistics / impl.
I agree with the DescriptiveStatistics class (except the fact the
serialVersionUID should be uptdated). I think DescriptiveStatisticsImpl
should be deprecated (also the import for ResizableDoubleArray that
remains in this stripped down class is not useful anymore).
Luc
>
> Phil
>
> ---------------------------------------------------------------------
> 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] Release planning, IOC-friendlyness
Posted by Phil Steitz <ph...@gmail.com>.
On Sep 3, 2007 8:33 AM, Phil Steitz <ph...@gmail.com> wrote:
> On 9/2/07, Luc Maisonobe <Lu...@free.fr> wrote:
> > On 2007-05-15, Phil Steitz wrote:
> >
> > > I agree. So, probably best is to deprecate the current abstract
> > > factories and move to single concrete factories with impl setters for
>
> > > IOC support. The concrete factories exist already, so it may just be
> > > a matter of deprecation and possibly renaming some things. Here
> > > again, we could deprecate in 1.2, remove in 2.0. Lets step back and
> > > reexamine the overall setup and introduce a better approach. All ideas
>
> > > / suggestions welcome. Consistency is important, though, so whatever
> > > we decide on, lets be consistent in distributions, solvers, etc.
> >
> > I am working on a new UnknownDistributionChiSquareTest interface
> > concerning issue https://issues.apache.org/jira/browse/MATH-160, and I
> > have to find the proper way to create instances. We talk about factories
> > and deprecation, and I think there are still issues.
> >
> > I think deprecating the abstract factories and using only the concrete
> > implementations would not be wise, it seems strange to have a
> > non-deprecated class extend a deprecated one. We should better remove
> > the "abstract" qualifier and simply push the concrete code up. Then we
> > can add the setters in these single factories for IOC concerns. The
> > current XxxFactoryImpl classes would then become empty and would be
> > deprecated. Does this seem sensible to everybody ?
> >
Sorry for the delay in getting back to this. I just committed
(r598133) an attempt at this for DescriptiveStatistics /
DescriptiveStatisticsImpl. Pls any [math] or other interested parties
have a look. I can roll it back if there are objections or better
ideas. Clirr complained about removing fields from the now deprecated
subclass, but these are protected in the parent, so I don't see this
as an issue. I took care to keep the argumentless constructor in
DescriptiveStatistics empty so it would not cause problems for
subclasses (we have an example in ListUnivariateImpl in /test) and I
can't think of other compatability issues. It is quite possible that
clirr and I are both missing something, though, so I would appreciate
a careful look.
If all are OK with this approach, I will do the same thing for
SummaryStatistics / impl.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Release planning, IOC-friendlyness
Posted by Phil Steitz <ph...@gmail.com>.
On 9/2/07, Luc Maisonobe <Lu...@free.fr> wrote:
> On 2007-05-15, Phil Steitz wrote:
>
> > I agree. So, probably best is to deprecate the current abstract
> > factories and move to single concrete factories with impl setters for
> > IOC support. The concrete factories exist already, so it may just be
> > a matter of deprecation and possibly renaming some things. Here
> > again, we could deprecate in 1.2, remove in 2.0. Lets step back and
> > reexamine the overall setup and introduce a better approach. All ideas
> > / suggestions welcome. Consistency is important, though, so whatever
> > we decide on, lets be consistent in distributions, solvers, etc.
>
> I am working on a new UnknownDistributionChiSquareTest interface
> concerning issue https://issues.apache.org/jira/browse/MATH-160, and I
> have to find the proper way to create instances. We talk about factories
> and deprecation, and I think there are still issues.
>
> I think deprecating the abstract factories and using only the concrete
> implementations would not be wise, it seems strange to have a
> non-deprecated class extend a deprecated one. We should better remove
> the "abstract" qualifier and simply push the concrete code up. Then we
> can add the setters in these single factories for IOC concerns. The
> current XxxFactoryImpl classes would then become empty and would be
> deprecated. Does this seem sensible to everybody ?
>
This is an interesting idea, but I am not sure we need to continue to
support the factories. The approach that we took in the distributions
package was just to deprecate the factories, leaving it to the user
code (or IOC framework) to create instances. If you look at our
internal use of the distributions, this seems to work OK.
ChiSquareTestImpl, for example, now exposes a setter for the
ChiSquareDistribution that it uses.
I guess what it comes down to is how often will users want to
configure or use multiple classes sourced from the same factory, how
many users use the to-be-deprecated factories now, and how bad is it
to force users to directly instantiate the Impl classes. My intuition
is not that none of these are that bad, so I guess I remain in favor
of the current "get out of the factory business" approach. On the
other hand, if a) there are no backward compatibility problems with
the approach that you describe and b) we do it uniformly (so go back
and change distributions), then I am OK with it. Interested in
others' views on this as well.
Phil
> Luc
>
>
> ---------------------------------------------------------------------
> 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] Release planning, IOC-friendlyness
Posted by Luc Maisonobe <Lu...@free.fr>.
On 2007-05-15, Phil Steitz wrote:
> I agree. So, probably best is to deprecate the current abstract
> factories and move to single concrete factories with impl setters for
> IOC support. The concrete factories exist already, so it may just be
> a matter of deprecation and possibly renaming some things. Here
> again, we could deprecate in 1.2, remove in 2.0. Lets step back and
> reexamine the overall setup and introduce a better approach. All ideas
> / suggestions welcome. Consistency is important, though, so whatever
> we decide on, lets be consistent in distributions, solvers, etc.
I am working on a new UnknownDistributionChiSquareTest interface
concerning issue https://issues.apache.org/jira/browse/MATH-160, and I
have to find the proper way to create instances. We talk about factories
and deprecation, and I think there are still issues.
I think deprecating the abstract factories and using only the concrete
implementations would not be wise, it seems strange to have a
non-deprecated class extend a deprecated one. We should better remove
the "abstract" qualifier and simply push the concrete code up. Then we
can add the setters in these single factories for IOC concerns. The
current XxxFactoryImpl classes would then become empty and would be
deprecated. Does this seem sensible to everybody ?
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [math] Release planning, IOC-friendlyness
Posted by Phil Steitz <ph...@gmail.com>.
On 5/14/07, luc.maisonobe@free.fr <lu...@free.fr> wrote:
> Phil Steitz <ph...@gmail.com> wrote:
>
> > I think that modulo some cleanup, testing and review and the one
> > dangling item below, we should be ready for a [math] release.
>
> I first wanted to introduce SVD but now think I need to work more on this. This
> would delay a release for quite long. I therefore agree with you and propose to
> delay SVD to next release.
>
Sorry I forgot about that item. Agree we can hold until next release.
> > I will
> > RM if no one else wants to, but would appreciate it (and support by
> > sharing gruntwork) if someone else volunteers.
>
> I would be happy to help. However I never followed the release process before,
> so it may be to early for this one. Regardless of who manages the release, I
> will add the public subkey I have set up for releases signing in the KEYS file.
>
Sounds like we have a victi...er I mean, "volunteer". If you are
willing to play the RM role, I will help both with execution and also
update the "releasing" docs to m2. The first step, assuming you are up
for it, is to create a release plan on the Wiki. Don't worry about
getting everything right on the first cut, we can discuss and update
before finalizing. You can start by editing the now obsolete plan
here:
http://wiki.apache.org/jakarta-commons/math/1%2e2ReleasePlan
> > Here are some
> > questions to resolve in the release plan:
> >
> > 1. Is this 1.2 or 2.0? There is so much in the added Mantissa
> > classes that 2.0 makes sense from a functionality standpoint. On the
> > other hand, we have not broken backward compatibility with anything
> > (yet) and if we decide to go 2.0, we could consider some API change.
> > My vote is to keep compatibility in place, but still name it 2.0.
>
> I also think we should use 2.0 as the release number. There are some API changes
> as some methods have been deprecated. I also wonder if it would'nt be safer to
> change some unchecked exceptions to checked exceptions. An example for this is
> the solve method for UnivariateRealSover. Solvers may throw an
> IllegalArgumentException when the provided interval doesn't bracket the root for
> example. This is explained in javadoc but I would prefer to enforce it by
> replacing this by something like SearchIntervalException or even a broad
> SolverException. Of course, this would be break compatibility (but user code
> would be easy to fix).
We have had lots of discussion over the years on checked vs unchecked
exceptions (vs returning NaN) in [math]. The original discussion is
in this thread
http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg20502.html
and we have talked about the issue several times since, always trying
to find the right balance between "cluttering user code" with catch
blocks vs throwing unexpected RTEs and also being consistent with
java.Math and as much as possible IEEE 745.
I am fine with revisiting the decisions made and improving the overall
exception hierarchy and management as we have started to do in trunk.
I would prefer to find a way to do this via deprecation / replacement,
though, so as not to immediately break existing client code.
Could be the best strategy is to push out a 1.2 release with
deprecations and remove the deprecated classes / methods in 2.0. See
below for more on this.
>
> > 2. What if anything should we add to make "pluggability" as designed
> > in the library compatible with IOC frameworks? It won't work to add
> > setters for the main factories, since we use the static getInstance
> > factory pattern (see e.g. UnivariateRealSoverFactory). What might
> > make more sense would be to add setters for the individual solvers in
> > e.g. UnivariateRealSoverFactoryImpl. Any ideas on how best to attack
> > this? For those not familiar with [math] who may have ideas, the
> > basic setup is that we use abstract factories with static getInstance
> > methods that return concrete factories looked up using
> > commons-discovery. The concrete factories themselves source multiple
> > different object types .
>
> Adding setters seems a bit strange to me. I thought either we use
> abstract/concrete factories and let the user provide his own factories by
> extending the default one overriding only the factory method he need, or we use
> only one concrete factory and setters in the spirit of IOC. Providing both at
> the same time is confusing. I personally prefer the IOC way but once again this
> would be an incompatible change (this one is more difficult to fix in user code,
> but I'm not sure many people used this feature).
>
I agree. So, probably best is to deprecate the current abstract
factories and move to single concrete factories with impl setters for
IOC support. The concrete factories exist already, so it may just be
a matter of deprecation and possibly renaming some things. Here
again, we could deprecate in 1.2, remove in 2.0. Lets step back and
reexamine the overall setup and introduce a better approach. All ideas
/ suggestions welcome. Consistency is important, though, so whatever
we decide on, lets be consistent in distributions, solvers, etc.
In terms of release number, I guess I am back to seeing 1.2 as
desirable, since it gives us the opportunity to do the deprecations
and provides a bridge for current users who want the new functionality
but depend on old APIs.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [math] Release planning, IOC-friendlyness
Posted by lu...@free.fr.
Phil Steitz <ph...@gmail.com> wrote:
> I think that modulo some cleanup, testing and review and the one
> dangling item below, we should be ready for a [math] release.
I first wanted to introduce SVD but now think I need to work more on this. This
would delay a release for quite long. I therefore agree with you and propose to
delay SVD to next release.
> I will
> RM if no one else wants to, but would appreciate it (and support by
> sharing gruntwork) if someone else volunteers.
I would be happy to help. However I never followed the release process before,
so it may be to early for this one. Regardless of who manages the release, I
will add the public subkey I have set up for releases signing in the KEYS file.
> Here are some
> questions to resolve in the release plan:
>
> 1. Is this 1.2 or 2.0? There is so much in the added Mantissa
> classes that 2.0 makes sense from a functionality standpoint. On the
> other hand, we have not broken backward compatibility with anything
> (yet) and if we decide to go 2.0, we could consider some API change.
> My vote is to keep compatibility in place, but still name it 2.0.
I also think we should use 2.0 as the release number. There are some API changes
as some methods have been deprecated. I also wonder if it would'nt be safer to
change some unchecked exceptions to checked exceptions. An example for this is
the solve method for UnivariateRealSover. Solvers may throw an
IllegalArgumentException when the provided interval doesn't bracket the root for
example. This is explained in javadoc but I would prefer to enforce it by
replacing this by something like SearchIntervalException or even a broad
SolverException. Of course, this would be break compatibility (but user code
would be easy to fix).
> 2. What if anything should we add to make "pluggability" as designed
> in the library compatible with IOC frameworks? It won't work to add
> setters for the main factories, since we use the static getInstance
> factory pattern (see e.g. UnivariateRealSoverFactory). What might
> make more sense would be to add setters for the individual solvers in
> e.g. UnivariateRealSoverFactoryImpl. Any ideas on how best to attack
> this? For those not familiar with [math] who may have ideas, the
> basic setup is that we use abstract factories with static getInstance
> methods that return concrete factories looked up using
> commons-discovery. The concrete factories themselves source multiple
> different object types .
Adding setters seems a bit strange to me. I thought either we use
abstract/concrete factories and let the user provide his own factories by
extending the default one overriding only the factory method he need, or we use
only one concrete factory and setters in the spirit of IOC. Providing both at
the same time is confusing. I personally prefer the IOC way but once again this
would be an incompatible change (this one is more difficult to fix in user code,
but I'm not sure many people used this feature).
Luc
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org