[ https://issues.apache.org/jira/browse/NUMBERS99?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=16945475#comment16945475
]
Heinrich Bohne commented on NUMBERS99:

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 signedmagnituderepresentation. 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 signedmagnituderepresentation 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: NUMBERS99
> URL: https://issues.apache.org/jira/browse/NUMBERS99
> 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)
