commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Mannix <>
Subject Re: [math] Questions about the linear package
Date Fri, 16 Oct 2009 06:30:18 GMT
On Thu, Oct 15, 2009 at 7:18 PM, Bill Barker <>wrote:

> I'm +1 on this (including being willing to help).  Like Luc, I don't
> believe that there are very many people implementing custom versons of these
> interfaces.

Ok great, I feel a consensus building here, so I'm going to write up a JIRA
ticket with a nice beefy patch implementing these ideas along with providing
the AbstractRealVector which uses the newly added iterator() and
nonDefaultIterator() abstract methods, in combination with the general
map(UnaryFunction), map(BinaryFunction, RealVector),
collect(UnaryCollector), collect(BinaryCollector, RealVector) abstractions,
to provide base implementations for all the various mapXXX and mapXXXtoSelf,
normXXX and distanceXXX methods so that subclasses can either stick with the
default or do some perf-enhancing speedups of their own.

I'll leave the huge plethora of methods alone for now, and we can decide
later if there is some subset of them which we can feel comfortable breaking
back-compat on by removing from the interface.

I'm +1 to deprecate these methods in 2.x, but -1* on removing them from the
> interface before 3.0.  There is a high expectation for commons projects that
> you can upgrade to minor versions by just dropping in the new jar file.

And to play the devil's advocate: how many users of commons-math have
upgraded to 2.0 since it came out, and in that time, started using
"mapCoshToSelf()" on their vectors? :)  In all practicality, there might not
be a single person out there who would be affected by a 2.1 coming out with
deprecation warnings, followed by 2.2 losing the more esoteric methods

In principle I'm definitely behind the back-compat clause, but technically,
if we're going with the route suggested by Luc that we add new methods to
this interface, we *are* opening the possibility of someone having their own
custom impl of RealVector linked against 2.0 which would flat out break when
trying to drop in 2.1 with the new interface.

But as I said - I'm new here, so I'll just leave methods already there in
place, and whatever you guys want to do about deprecation/removal seems fine
- the api/interface would be cleaner without all those methods, but
providing an AbstractRealVector which lets you safely ignore them should
make that uncleanness pretty ignorable.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message