[
https://issues.apache.org/jira/browse/NUMBERS-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16945475#comment-16945475
]
Heinrich Bohne commented on NUMBERS-99:
---------------------------------------
Hello,
sorry for having been absent for so long, I was a bit more preoccupied than I
anticipated. In fact, I still am, in a way, as I don't have as much time as I
used to, but I also don't want to leave all the open issues and pull requests
that I created just lying around.
About your question: If the denominator instance variable is always positive,
then either the contract of the factory method {{of(int, int)}} needs to be
changed to declare when the exception will be thrown, or another field must be
introduced that would cause the representation of a fraction to resemble a
signed-magnitude-representation. In the latter case, it would probably be
better to require the denominator to be always negative instead of positive, to
increase the number of possible denominator or numerator values by one.
But I don't think a signed-magnitude-representation makes things easier than
allowing both the numerator and the denominator to be negative OR positive, and
it would probably require more refactoring. So I think it will be either
changing the public contract, or allowing the denominator variable to be
negative.
What would be useful in any case would be a signum function method (I think you
suggested something like this somewhere), because even currently, there is no
publicly guaranteed way of determining the sign of a fraction other than
obtaining both the numerator and the denominator (because the denominator
reflecting the sign of the fraction is an implementation detail).
> Fraction.add(int) and Fraction.subtract(int) ignore risk of integer overflow
> ----------------------------------------------------------------------------
>
> Key: NUMBERS-99
> URL: https://issues.apache.org/jira/browse/NUMBERS-99
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
> Reporter: Heinrich Bohne
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The methods {{add(int)}} and {{subtract(int)}} in the class
> {{org.apache.commons.numbers.fraction.Fraction}} do not take into account the
> risk of an integer overflow. For example, (2^31^ - 1)/2 + 1 = (2^31^ +
> 1)/2, so the numerator overflows an {{int}}, but when calculated with
> {{Fraction.add(int)}}, the method still returns normally.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
