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

About the code coverage decrease in the method {{reduce()}} caused by PR #56 (the coverage
decrease in {{ArithmeticUtils}} is a myth invented by Coveralls, my IDE even shows that the
condition in line 112 is always false):
Since the local variable {{k}} had to be set inside the conditional tree that depends on the
value of the exponent rather than outside it as was previously the case, I thought I would
also make a special case for zero, because it doesn't make sense for the denominator of a
zerofraction to be 2^1074^. It didn't occur to me that this would have an effect on the
code coverage.
However, with this change, the uncovered line in the method {{reduce()}} becomes unreachable,
because the zero fraction created from this double constructor was the only case where the
fraction was not already reduced to lowest terms. This renders the {{reduce()}} method obsolete
anyway, which could be the target of a new JIRA ticket.
> BigFraction(double) constructor does not treat subnormal numbers correctly
> 
>
> Key: NUMBERS119
> URL: https://issues.apache.org/jira/browse/NUMBERS119
> Project: Commons Numbers
> Issue Type: Bug
> Components: fraction
> Affects Versions: 1.0
> Reporter: Heinrich Bohne
> Priority: Minor
> Time Spent: 1h
> 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.

This message was sent by Atlassian JIRA
(v7.6.3#76005)
