commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MATH-433) Signal overflow by raising an exception
Date Sun, 07 Nov 2010 21:14:06 GMT

    [ https://issues.apache.org/jira/browse/MATH-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929398#action_12929398
] 

Gilles commented on MATH-433:
-----------------------------

So, IIUC, you agree that the library is inconsistent. But you also don't wish to trap overflow
in floating point methods (to be on par with IEEE754).
The question then becomes: Why is it necessary to check for overflow in integer methods?
We could either drop the checks everywhere, or we keep the inconsistency (and, if not done
already, someone should maybe write a word about it in the user guide).


> Signal overflow by raising an exception
> ---------------------------------------
>
>                 Key: MATH-433
>                 URL: https://issues.apache.org/jira/browse/MATH-433
>             Project: Commons Math
>          Issue Type: Improvement
>            Reporter: Gilles
>            Priority: Minor
>
> Referring to the ML thread (with subject "Factorial").
> Shouldn't Commons-Math always raise an exception when overflow is detected, including
in cases where the Java language specification has decided to return infinity?
> It was argued, in the ML thread on "FunctionEvaluationException", that it was much better
to raise an exception than to rely on special values to detect problems. I think that the
same argument fits perfectly in this case.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message