On Mon, 17 Feb 2014 11:40:57 -0800, Phil Steitz wrote:
On 2/17/14, 9:57 AM, Luc Maisonobe wrote:
Le 17/02/2014 16:15, Ted Dunning a écrit :
On Mon, Feb 17, 2014 at 5:01 AM, Emmanuel Joliet
<ejol...@sciops.esa.int>wrote:
https://issues.apache.org/jira/browse/MATH-870
" Recently, many problems have been found out with class ..."
Please, consider not removing it.
We use it heavily and need the class as it gives what we need
(handling
the input of course is necessary regarding NaN and infinities!).
I understand the problem of an incorrect/improper handling of
NaN/Infinity
conditions but can't justify to remove the iterfaces/classes
completely?
Isn't it??
For now, the classes are still there and will remain at least as
long as
we release versions in the 3.x series. The next version will be 3.3,
so
the classes will still be there.
Yeah... welcome to commons math.
It does seem like an extreme sanction to me.
I agree. I think we get over zealous here regarding NaNs, as it
seems
all other libraries simply ignore this, and it seems to be a widely
accepted way.
+1 - lets just doc the limitations as best we can and keep this
stuff.
A few things we could do before releasing 3.3:
1. Add the following text in the class Javadoc for "OpenMapRealMatrix"
and "OpenMapRealVector".
---CUT---
* <p>
* Caveat: This implementation assumes that, for any {@code x},
* the equality {@code x * 0d == 0d} holds. But it is is not true for
* {@code NaN}. Moreover, zero entries will lose their sign.
* Some operations (that involve {@code NaN} and/or infinities) may
* thus give incorrect results.
* </p>
---CUT--
2. Add unit tests that demonstrate the pitfalls (i.e. cases that are
known
to give incorrect results). [Patches welcome.]
3. Have a look into the implementations of the (up to now) considered
problematic operations (see comments in the code) and decide whether
to remove the code intended to work around the problem (which is not
be a problem anymore but a documented limitation). This could
enhance
performance of those classes.
4. "Undeprecate" the above two classes.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
