On 09/07/2012 02:39, Gilles Sadowski wrote:
On Sat, Jul 07, 2012 at 02:31:54PM +0200, Sébastien Brisard wrote:
Hi,
recent bugs have revealed that the use of sparseIterator() is quite
delicate. Also, the current Javadoc is confusing, since it says
Specialized implementations may choose to not
On 09/07/2012 07:08, Sébastien Brisard wrote:
2012/7/9 Gilles Sadowski gil...@harfang.homelinux.org:
On Sat, Jul 07, 2012 at 01:49:25PM +0200, Sébastien Brisard wrote:
Hello,
most existing methods in class RealVector allow method chaining.
Chaining does not always make for readable code.
HI,
2012/7/9 Sébastien Brisard sebastien.bris...@m4x.org:
Hello,
2012/7/9 Luc Maisonobe luc.maison...@free.fr:
On 09/07/2012 07:08, Sébastien Brisard wrote:
2012/7/9 Gilles Sadowski gil...@harfang.homelinux.org:
On Sat, Jul 07, 2012 at 01:49:25PM +0200, Sébastien Brisard wrote:
Hello,
All,
in Commons-Math, class RealVector has a method unitize() which divides
each component of this by the norm. The vector is changed in place.
The current signature of this method is
public void unitize()
Most methods in class RealVector implement a fluent API. I would like
unitize() to follow
Hi Sebastien,
have a look at:
http://wiki.eclipse.org/Evolving_Java-based_APIs
http://wiki.eclipse.org/Evolving_Java-based_APIs_2
http://wiki.eclipse.org/Evolving_Java-based_APIs_3
In section Evolving API classes - API methods and constructors it says:
Change result type (including void) -
In fact, changing the return type does break binary compatibility (binary
compatibility is different from source compatibility), since the return
type of a method is part of is java signature.
This means that if someone would want to use the new jar (with changed
return type) as a drop-in
Hi,
In fact, changing the return type does break binary compatibility (binary
compatibility is different from source compatibility), since the return
type of a method is part of is java signature.
This means that if someone would want to use the new jar (with changed
return type) as a
Hi,
2012/7/9 Sébastien Brisard sebastien.bris...@m4x.org:
HI,
2012/7/9 Sébastien Brisard sebastien.bris...@m4x.org:
Hello,
2012/7/9 Luc Maisonobe luc.maison...@free.fr:
On 09/07/2012 07:08, Sébastien Brisard wrote:
2012/7/9 Gilles Sadowski gil...@harfang.homelinux.org:
On Sat, Jul 07,
Hello,
I have developed a new component for the Apache Camel project written using
pure Java JMS APIs (the current component is a Spring JMS wrapper). There
have been requests made to make the API pulled out of the Camel component
and to place them in a commons project for use by other projects
On 09/07/2012 22:12, Scott England-Sullivan wrote:
Hello,
Hi Scott,
I have developed a new component for the Apache Camel project written using
pure Java JMS APIs (the current component is a Spring JMS wrapper). There
have been requests made to make the API pulled out of the Camel
If Scott were an Apache committer (he is not), that would be true. ;)
Instead, the situation is more complicated. Is this component part
of the current Camel codebase? If so (or even if not?), perhaps one
or more of the Camel committers would care to manage the code in the
Commons sandbox,
Hello,
I have implemented some classes for multivariate Normal distributions,
multivariate normal mixture models, and an expectation maximization fitting
class for the mixture model. I would like to submit it to Apache Commons Math.
I still have some touching up to do so that they fit the
Dear Jared,
Yes, that would be very nice to have such an addition! Remember to
also include unit tests (refer to the current ones for examples). The
best would be to split a submission up into multiple minor ones, each
covering a natural submission (e.g. multivariate Normal distribution
in one
On 7/9/12 2:08 PM, Matt Benson wrote:
I am still thinking this through... Commons policy permits any Apache
committer to start a sandbox component, but IMO it is tacitly implied
that the associated code come directly from the committer/s, or from
another Apache project. This implies that this
14 matches
Mail list logo
