[
https://issues.apache.org/jira/browse/MATH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292525#comment-13292525
]
Luc Maisonobe commented on MATH-803:
------------------------------------
Perhaps we should use a post-processing branch to handle infinite or spacial
values:
{code}
// current implementation looping over non-zero instance elements goes here
if (v.isNaN() || v.isInfinite()) {
// post-processing loop, to handle 0 * infinity and 0 * NaN cases
for (int i = 0; i < v.getDimension(); ++v) {
if (Double.isInfinite(v.getElement(i)) || Double.isNaN(v.getElement(i)) {
res.setEntry(i, Double.NaN);
}
}
}
{code}
This could be fast only if isNaN() and isInfinite() results are cached and the
same vector is reused, otherwise the outer if statement should be removed and
the post-processing should be done in all cases.
> Bugs in OpenMapRealVector.ebeMultiply(RealVector) and ebeDivide(RealVector)
> ---------------------------------------------------------------------------
>
> Key: MATH-803
> URL: https://issues.apache.org/jira/browse/MATH-803
> Project: Commons Math
> Issue Type: Bug
> Affects Versions: 3.0
> Reporter: Sébastien Brisard
> Assignee: Sébastien Brisard
>
> {{OpenMapRealVector.ebeMultiply(RealVector)}} and
> {{OpenMapRealVector.ebeDivide(RealVector)}} return wrong values when one
> entry of the specified {{RealVector}} is nan or infinity. The bug is easy to
> understand. Here is the current implementation of {{ebeMultiply}}
> {code:java}
> public OpenMapRealVector ebeMultiply(RealVector v) {
> checkVectorDimensions(v.getDimension());
> OpenMapRealVector res = new OpenMapRealVector(this);
> Iterator iter = entries.iterator();
> while (iter.hasNext()) {
> iter.advance();
> res.setEntry(iter.key(), iter.value() * v.getEntry(iter.key()));
> }
> return res;
> }
> {code}
> The assumption is that for any double {{x}}, {{x * 0d == 0d}} holds, which is
> not true. The bug is easy enough to identify, but more complex to solve. The
> only solution I can come up with is to loop through *all* entries of v
> (instead of those entries which correspond to non-zero entries of this). I'm
> afraid about performance losses.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
