Dear all,
in this thread,
http://markmail.org/thread/hhvm6wv3d3uhkwqs
we had an interesting discussion on a bug which was revealed by
abstract unit tests on all implementations of RealVector. It turns out
that the bug is more far-reaching than we initially thought, and I
would like to make sure that it has been brought to everyone's
attention (as the subject of the previous thread was pretty cryptic).
So here goes. In RealVector, we provide ebeMultiply(RealVector) and
ebeDivide(RealVector). Also, in sparse implementations of RealVector,
zero entries are not stored. This is all very well, but for the fact
that 0.0 is actually signed in Java. The sign of zero is effectively
lost in OpenMapRealVector. This affects the correctness of the
returned values of ebeMulltiply() and ebeDivide()
1. For ebeMultiply()
final RealVector v1 = new ArrayRealVector(new double[] { 1d });
final RealVector v2 = new OpenMapRealVector(new double[] { -0d });
final RealVector w = v1.ebeMultiply(v2);
System.out.println(1d / w.getEntry(0));
prints Infinity, instead of -Infinity (because the sign is lost in
v2). This means that w holds +0d instead of -0d.
2. For ebeDivide()
final RealVector v1 = new ArrayRealVector(new double[] { 1d });
final RealVector v2 = new OpenMapRealVector(new double[] { -0d });
final RealVector w = v1.ebeDivide(v2);
System.out.println(w.getEntry(0));
prints Infinity, instead of -Infinity. For this last bug, Gilles
suggested the following fix
>
> public OpenMapRealVector ebeDivide(OpenMapRealVector v) {
> if (v.getDefaultEntry() == 0) {
> throw new ZeroException();
> }
>
> // ...
> }
>
which was indeed no big deal, since the exception occured only when
the expected entry should have been + or -Infinity (which means that
the calculation had effectively failed).
However, this fix is not the end of the story, because it should be
applied to *any* implementation of RealVector.ebeDivide, as long as
the provided argument is an OpenMapRealVector. This makes things
cumbersome. Also, other implementations of RealVector (not only
OpenMapRealVector) might be affected by the same limitation. In my
view, this would require the definition of a new abstract method in
RealVector
protected boolean preservesSignOfZeroEntries()
which returns true if the sign of zero entries can be reliably
retrieve from this vector. Then, for each implementation of
ebeMultiply and ebeDivide,, we should test for
preservesSignOfZeroEntries(), and handle the boundary cases
accordingly.
The question is then: how should the boundary case be handled in the
ebeMultiply example? In this case, the expected value is perfectly
valid, and throwing an exception would effectively stop a computation
which is not yet in failed state. I would be tempted to quietly
accept operations like : any double * (zero with undecidable sign).
The returned value would be zero with undecidable sign (remember that
the sign of zero is only used to compute (any double) / (signed
zero)). But then, preservesSignOfZeroEntries() must be specified at
construction time, because even ArrayRealVector might in some
circumstances end up with zero entries with undecidable sign... This
quickly gets very complicated!
I think there is no satisfactory implementation of ebeMultiply and
ebeDivide, and I would go as far as deprecate them. Users who need to
perform these operations can always use visitors to do so efficiently
(if not in an absolute fool-proof way).
Any better idea?
Thanks in advance,
Sébastien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
