[
https://issues.apache.org/jira/browse/NUMBERS-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16874441#comment-16874441
]
Heinrich Bohne commented on NUMBERS-119:
----------------------------------------
I've merged the master branch into PR #56. For some reason, this made the false
reports by Coveralls about uncovered lines in {{ArithmeticUtils}} go away. Now,
according to the report, the only line previously covered but now uncovered is
the line in {{reduce()}} that becomes unreachable after this change because the
numerator and denominator are now _always_ reduced to lowest terms, meaning
that line cannot possibly be covered by unit tests. But deleting the line would
be illegal unless the contract of the class were changed as well, because the
class' contract doesn't require the numerator and denominator to be reduced to
lowest terms, and changing the class' contract in this way seems to be outside
the scope of this ticket.
> BigFraction(double) constructor does not treat subnormal numbers correctly
> --------------------------------------------------------------------------
>
> Key: NUMBERS-119
> URL: https://issues.apache.org/jira/browse/NUMBERS-119
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
> Affects Versions: 1.0
> Reporter: Heinrich Bohne
> Priority: Minor
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The constructor {{BigFraction(double)}} does not take into account the fact
> that, when the biased exponent of a {{double}} value is {{0}} and the
> mantissa is not {{0}} (i.e. when the value represents a subnormal number),
> the actual exponent in effect is not {{-1023}} but {{-1022}} (or, in other
> words, the effective exponent bias is not {{1023}} but {{1022}}).
> The value of the created {{BigFraction}} is therefore not equal to the value
> of the passed {{double}} argument.
> Also, since the constructor does not handle the case of zero separately, it
> creates a fraction with a numerator of 0 and a denominator of 2^1075^, which
> is not very memory-efficient.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
