[continuum] BUILD FAILURE: Apache Commons - Commons Math -
Group (shared) Maven 3 Build Definition (Java 1.6) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 97 X-Continuum-Project-Name: Commons Math Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=27282projectId=97 Build statistics: State: Failed Previous State: Failed Started at: Fri 9 Aug 2013 14:20:14 + Finished at: Fri 9 Aug 2013 14:27:57 + Total time: 7m 42s Build Trigger: Schedule Build Number: 1298 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 3.0.2 (r1056850; 2011-01-09 00:58:10+) Java version: 1.6.0_30, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux, version: 2.6.32-41-server, arch: amd64, family: unix SCM Changes: Changed: erans @ Fri 9 Aug 2013 13:55:49 + Comment: MATH-1020. Fixed nextPermutation in RandomDataGenerator. Bug showed up when using a fixed version of shuffle (MATH-1019) added in MathArrays (MATH-1010). Added overloaded shuffle method (used in the above fix). Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/random/RandomDataGenerator.java ( 1512306 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/MathArrays.java ( 1512306 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 3.0.2 Description: Group (shared) Maven 3 Build Definition (Java 1.6) Test Summary: Tests: 5218 Failures: 0 Errors: 0 Success Rate: 100 Total time: 307.17798 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Fluent API, inheritance and immutability
[...]
This does make it important to decide on a well written and
complete API before releasing it.
When the scope of the software is well circumscribed, that would be
possible. With the whole of [Math]ematics, much less so. :-}
And state-of-the-art in Java is a moving target, aimed at by
changing
CM contributors with differing needs and tastes; this adds to the
unstable mix.
That's a good point. I still prefer the interface design (though I
may
be in the minority) for two reasons. First, if a concrete class only
publicly exposes the methods defined in an interface it encourages
polymorphism. User code that uses one implementation can be easily
switched to another and new implementations are less constrained.
Second, it encourages composition over inheritance. I agree with Josh
Bloch that composition produces more maintainable code. Adding new
methods to an existing interface/class breaks composition.
The problem is to get the interface right. As it happens, at some
point
we discover something that was not foreseen; and to correct/improve the
design, compatibility must be broken.
[But refactoring is not a failure of development; it's part of it.]
I think the interface/abstract class discussion is partially
separable
from the immutable/mutable discussion. I see the algorithm as the
part
that could really benefit from the polymorphism. Perhaps separating
the
problem definition (data) from the algorithm will improve the
flexibility of the API. For example,
PointVectorValuePair solveMyNLLSProblem(NLLSOptimizer opt){
//define problem to solve in an independent object
NLLSProblem p = new NLLSProblem(/*model functions, weights,
convergence checker, ...*/);
//provide algorithm with the data it needs
//algorithm has no problem specific state
return opt.optimize(p);
}
I may be missing something, but how much better is it to store
everything the optimizer needs in yet another class?
[Then, that's a possible approach, but it's not what we started
from in Commons Math, and when trying to fix some inconsistency
or removing duplicate code, I tried to retain what could be from
the existing design.]
[...] Thread safety is a tricky beast. I think we agree that the
only
way to guarantee thread safety is to only depend on final concrete
classes that are thread safe themselves.
I don't think so. When objects are immutable, thread-safety follows
It is somewhat off topic, but a counter example would be Vector3D.
Since
the class is not final, a user could extend it and override all the
methods and add some set{X,Y,Z} methods to make it mutable. Even
though
Vector3D is immutable, there is no _guarantee_ that every instanceof
Vector3D is immutable unless it is final. This is why String is
final.
I think I don't get your point: If someone extends a class that is safe
in a way that the extension is unsafe, that's his problem. ;-)
[...] copying any large matrices or arrays is prohibitively
expensive. For the NLLS package we would be copying a pointer to a
function that can generate a large matrix. I think adding some
documentation that functions should be thread safe if you want to
use
them from multiple threads would be sufficient.
I you pass a pointer (i.e. a reference in Java), all bets are
off:
the
class is not inherently thread-safe. That's why I suggested to
mandate a
_deep_ copy method (with a stringent contract that should allow a
caller
to be sure that all objects owned by an instance are disconnected
from
any
other objects).
As someone who has designed a thread safe application based on deep
copying I don't think this is route to follow. A deep copy means you
have to be able to copy an arbitrary (possibly cyclical) reference
graph. Without the graph copy there are many subtle bugs. (References
to
the same object are now references to different objects.) With the
graph
copy the implementation is very complex. This is the reason
Serialization has a separate patch up step after object creation,
which leads to some nasty tricks/bugs. Similarly, Cloneable only
produces a shallow copy. Opinions may vary, but in my experience
immutability is an easier approach to thread safety, especially when
you
have to depend on user code.
I agree that using immutability is easier, but my point all along is
that
it is at odds with simplicity (which is aimed at with fluent API).
And since
1. the internals of the optimizers are not thread-safe yet (see e.g.
LevenbergMarquardtOptimizer), and
2. it unclear why an optimizer object should be shared by several
threads,
I think that it not worth the additional code just to add the final
keyword.
Another, more directly useful (but also, unrelated), feature, would be
to allow concurrent evaluations of the objective function.
But this would impose that users ensure that the _input_ to the
optimizer
is thread-safe.
Either way there can be some tricky bugs for the user. In the
immutable
approach the bugs are solved by
Re: [Math] Remove optimizer from constructor of CurveFitter subclasses (MATH-1014)
On Mon, 05 Aug 2013 04:27:11 +0200, Gilles wrote: Hi. Please have a look at https://issues.apache.org/jira/browse/MATH-1014 [...] In addition to the changes contained in the patch attached to that issue, I would consider removing the data point book-keeping from the fitter classes, i.e. the addObservedPoint(...) methods family. Indeed, it seems that this functionality is not the role of the fitter classes: The fit methods should instead be passed a CollectionWeightedObservedPoint as input. Functionality for building such a container from individual data points could be provided as a separate utility. What do you think? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[continuum] BUILD FAILURE: Apache Commons - Commons Math -
Group (shared) Maven 3 Build Definition (Java 1.6) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 97 X-Continuum-Project-Name: Commons Math Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=27288projectId=97 Build statistics: State: Failed Previous State: Failed Started at: Sat 10 Aug 2013 00:20:14 + Finished at: Sat 10 Aug 2013 00:27:39 + Total time: 7m 25s Build Trigger: Schedule Build Number: 1298 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 3.0.2 (r1056850; 2011-01-09 00:58:10+) Java version: 1.6.0_30, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux, version: 2.6.32-41-server, arch: amd64, family: unix SCM Changes: Changed: erans @ Fri 9 Aug 2013 23:21:14 + Comment: MATH-1008 Simplification of the code introduced in revision 1508481. The changes only focus on the fluent API aspect (rather than also try to achieve thread-safety through immutability). Class AbstractOptimizer introduced to serve as the base class for all optimizers (i.e. replace the current BaseOptimizer). Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/leastsquares/AbstractLeastSquaresOptimizer.java ( 1512530 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/leastsquares/GaussNewtonOptimizer.java ( 1512530 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/leastsquares/LevenbergMarquardtOptimizer.java ( 1512530 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/fitting/leastsquares/WithConvergenceChecker.java ( 1512530 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/optim/AbstractOptimizer.java ( 1512530 ) /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/fitting/leastsquares/AbstractLeastSquaresOptimizerAbstractTest.java ( 1512530 ) /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/fitting/leastsquares/LevenbergMarquardtOptimizerTest.java ( 1512530 ) /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/fitting/leastsquares/MinpackTest.java ( 1512530 ) Changed: erans @ Fri 9 Aug 2013 23:39:24 + Comment: MATH-1010 Make use of the RNG supplied as argument. Files changed: /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/util/MathArrays.java ( 1512535 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 3.0.2 Description: Group (shared) Maven 3 Build Definition (Java 1.6) Test Summary: Tests: 5218 Failures: 0 Errors: 0 Success Rate: 100 Total time: 307.94598 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Fluent API, inheritance and immutability
On 8/8/13 10:56 AM, Evan Ward wrote:
Gilles wrote:
To address a few concerns I saw,
Gilles wrote:
In this way, it does not; what I inferred from the partial code
above was
that there would only be _one_ create method. But:
1. All create methods must be overridden at the next level of the
class
hierarchy (this is the duplication I was referring to in the first
post).
True, but concrete classes should not be extended.
Why not?
[Anyways, the duplication also occurs in the intermediate (abstract)
levels.]
Adding another
abstract class to the hierarchy would mean implementing the create
method form the superclass and delegating to a new abstract create
method that includes the new parameters. The abstract class hierarchy
would have to parallel the interface hierarchy.
With a mutable instance, you avoid this; that's the point.
2. When a parameter is added somewhere in the hierarchy, all the
classes
below must be touched too.
True, but since abstract classes are just skeletal implementations of
interfaces you can't add any methods without breaking compatibility
anyway.
Adding a (concrete) method in an abstract class will not break
compatibility.
(You would have to add the same method to the public interface
too.)
There you break compatibility; that's why we removed a lot of the
interfaces in CM, because the API is not stable, and abstract classes
allow non-breaking changes.
This does make it important to decide on a well written and
complete API before releasing it.
When the scope of the software is well circumscribed, that would be
possible. With the whole of [Math]ematics, much less so. :-}
And state-of-the-art in Java is a moving target, aimed at by changing
CM contributors with differing needs and tastes; this adds to the
unstable mix.
That's a good point. I still prefer the interface design (though I may
be in the minority) for two reasons. First, if a concrete class only
publicly exposes the methods defined in an interface it encourages
polymorphism. User code that uses one implementation can be easily
switched to another and new implementations are less constrained.
Second, it encourages composition over inheritance. I agree with Josh
Bloch that composition produces more maintainable code. Adding new
methods to an existing interface/class breaks composition.
I think the interface/abstract class discussion is partially separable
from the immutable/mutable discussion. I see the algorithm as the part
that could really benefit from the polymorphism. Perhaps separating the
problem definition (data) from the algorithm will improve the
flexibility of the API. For example,
PointVectorValuePair solveMyNLLSProblem(NLLSOptimizer opt){
//define problem to solve in an independent object
NLLSProblem p = new NLLSProblem(/*model functions, weights,
convergence checker, ...*/);
//provide algorithm with the data it needs
//algorithm has no problem specific state
return opt.optimize(p);
}
And, we must note, that the duplication still does not ensure real
immutability unless all the passed arguments are themselves immutable.
But:
1. We do not have control over them; e.g. in the case of the optimizers
the ConvergenceChecker interface could possibly be implemented by a
non-thread-safe class (I gave one example of such a thing a few weeks
ago when a user wanted to track the optimizer's search path)
True. Thread safety is a tricky beast. I think we agree that the only
way to guarantee thread safety is to only depend on final concrete
classes that are thread safe themselves.
I don't think so. When objects are immutable, thread-safety follows
It is somewhat off topic, but a counter example would be Vector3D. Since
the class is not final, a user could extend it and override all the
methods and add some set{X,Y,Z} methods to make it mutable. Even though
Vector3D is immutable, there is no _guarantee_ that every instanceof
Vector3D is immutable unless it is final. This is why String is final.
(but
note that the current optimizers in CM were never thread-safe).
But thread-safety can exist even with mutable objects; it's just that
more
care must be taken to ensure it.
This is directly at odds with
the inversion of control/dependency injection paradigm. I think a
reasonable compromise is to depend on interfaces and make sure all the
provided implementations are thread safe.
Yes, that a way, but again easier said that done.
A simple sequential user won't
need to care about thread safety. A concurrent user will need to
understand the implications of Java threading to begin with. Accurate
documentation of which interfaces and methods are assumed to be thread
safe goes a long way here.
I don't think I'm wrong if I say that most concurrent bugs are found in
production rather than in contrived test cases.
[That's why I advocated for introducing real applications as use-cases
for CM.]
2. Some users _complained_
[continuum] BUILD FAILURE: Apache Commons - Commons Math -
Group (shared) Maven 3 Build Definition (Java 1.6) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Continuum-Build-Host: vmbuild X-Continuum-Project-Id: 97 X-Continuum-Project-Name: Commons Math Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=27290projectId=97 Build statistics: State: Failed Previous State: Failed Started at: Sat 10 Aug 2013 01:20:14 + Finished at: Sat 10 Aug 2013 01:27:48 + Total time: 7m 33s Build Trigger: Schedule Build Number: 1298 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version 1.6.0_30 Java(TM) SE Runtime Environment (build 1.6.0_30-b12) Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode) Builder version : Apache Maven 3.0.2 (r1056850; 2011-01-09 00:58:10+) Java version: 1.6.0_30, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/jdk1.6.0_30/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: linux, version: 2.6.32-41-server, arch: amd64, family: unix SCM Changes: Changed: erans @ Sat 10 Aug 2013 00:29:31 + Comment: Update changes.xml. Files changed: /commons/proper/math/trunk/src/changes/changes.xml ( 1512541 ) Changed: erans @ Sat 10 Aug 2013 00:57:48 + Comment: MATH-1021 Reordering can prevent some overflow occurrences (fix suggested by Brian Bloniarz). Added unit test. Files changed: /commons/proper/math/trunk/pom.xml ( 1512546 ) /commons/proper/math/trunk/src/changes/changes.xml ( 1512546 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/distribution/HypergeometricDistribution.java ( 1512546 ) /commons/proper/math/trunk/src/test/java/org/apache/commons/math3/distribution/HypergeometricDistributionTest.java ( 1512546 ) Changed: erans @ Sat 10 Aug 2013 01:13:38 + Comment: MATH-989 Update changes.xml. Javadoc. Files changed: /commons/proper/math/trunk/src/changes/changes.xml ( 1512547 ) /commons/proper/math/trunk/src/main/java/org/apache/commons/math3/analysis/interpolation/BicubicSplineInterpolatingFunction.java ( 1512547 ) Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean deploy Arguments: --batch-mode -Pjava-1.6 -Dgpg.skip -Prelease Build Fresh: false Always Build: false Default Build Definition: true Schedule: COMMONS_SCHEDULE Profile Name: Maven 3.0.2 Description: Group (shared) Maven 3 Build Definition (Java 1.6) Test Summary: Tests: 5219 Failures: 0 Errors: 0 Success Rate: 100 Total time: 318.94812 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
