[jira] [Created] (NUMBERS-120) Major loss of precision in BigFraction.doubleValue() and BigFraction.floatValue()
Heinrich Bohne created NUMBERS-120:
--
Summary: Major loss of precision in BigFraction.doubleValue() and
BigFraction.floatValue()
Key: NUMBERS-120
URL: https://issues.apache.org/jira/browse/NUMBERS-120
Project: Commons Numbers
Issue Type: Bug
Components: fraction
Affects Versions: 1.0
Reporter: Heinrich Bohne
The method {{BigFraction.doubleValue()}} calculates the double value of
fractions with numerators or denominators that, when converted to a {{double}},
round up to {{Double.POSITIVE_INFINITY}}, by right-shifting both the numerator
and denominator synchronously until both numbers fit into 1023 bits. Apart from
the fact that the maximum number of bits an integer representable as a finite
{{double}} can have is 1024 (an unbiased exponent of 1023, which is the largest
possible unbiased exponent of a {{double}} number, means 1. ⋅ 2^1023^,
which amounts to 1024 bits), this way of converting the fraction to a
{{double}} is incredibly wasteful with precision if the numerator and
denominator have a different bit length, because the smaller of the two numbers
will be truncated beyond what is necessary to represent it as a finite
{{double}}. Here is an extreme example:
The smallest integer that rounds up to {{Double.POSITIVE_INFINITY}} when
converted to a {{double}} is 2^1024^ - 2^970^. This is because
{{Double.MAX_VALUE}} as an integer is a 1024-bit number with the most
significant 53 bits set to 1 and all other 971 bits set to 0. If the 970 least
significant bits are changed in any way, the number will still round down to
{{Double.MAX_VALUE}} as long as the 971st bit remains 0, but as soon as the
971st bit is set to 1, the number will round up to {{Double.POSITIVE_INFINITY}}.
The smallest possible denominator greater than 1 where a single right-shift
will cause a loss of precision is 3. 2^1024^ - 2^970^ is divisible by 3, so
in order to create an irreducible fraction, let's add 1 to it:
(2^1024^ - 2^970^ + 1) / 3 ≈ 5.992310449541053 ⋅ 10^307^ (which can be
verified with {{BigDecimal}}, or, more easily, with [this online
tool|https://www.wolframalpha.com/input/?i=(2%5E1024+-+2%5E970+%2B+1)+%2F+3].
However, the current implementation of BigFraction.doubleValue() returns
8.98846567431158 ⋅ 10^307^, which differs from the correct result by a
relative error of 50%! The same problem applies to the method
{{BigFraction.floatValue()}}.
This can be prevented by truncating the numerator and denominator separately,
so that for each of the two numbers, the maximum possible precision is retained.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (IO-585) FilenameUtils#normalizeNoEndSeparator does not sanitize multiple backslashes directly after the colon in windows file paths
[
https://issues.apache.org/jira/browse/IO-585?focusedWorklogId=265389=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-265389
]
ASF GitHub Bot logged work on IO-585:
-
Author: ASF GitHub Bot
Created on: 23/Jun/19 12:41
Start Date: 23/Jun/19 12:41
Worklog Time Spent: 10m
Work Description: adammcclenaghan commented on issue #79: IO-585:
Sanitize double slash after prefix
URL: https://github.com/apache/commons-io/pull/79#issuecomment-504747969
Jenkins builds are failing due to missing javadoc in a class unrelated to
this change
```
[ERROR]
src/main/java/org/apache/commons/io/output/NullPrintStream.java:[34,5]
(javadoc) JavadocMethod: Missing a Javadoc comment.
```
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 265389)
Time Spent: 20m (was: 10m)
> FilenameUtils#normalizeNoEndSeparator does not sanitize multiple backslashes
> directly after the colon in windows file paths
> ---
>
> Key: IO-585
> URL: https://issues.apache.org/jira/browse/IO-585
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Adam McClenaghan
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> FilenameUtils#normalizeNoEndSeparator states in the javadoc that :
> "A double slash will be merged to a single slash (but UNC names are
> handled)."
> It has been observed that if a double backslash occurs after the colon in a
> windows filepath, then the returned path still contains this double
> backslash. For example:
> {code:java}
> C:\\Program Files\\ExampleDirectory --> C:\\Program Files\ExampleDirectory
> {code}
> While the expectation is that we should be returning ' C:\Program
> Files\ExampleDirectory '
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-io] adammcclenaghan commented on issue #79: IO-585: Sanitize double slash after prefix
adammcclenaghan commented on issue #79: IO-585: Sanitize double slash after prefix URL: https://github.com/apache/commons-io/pull/79#issuecomment-504747969 Jenkins builds are failing due to missing javadoc in a class unrelated to this change ``` [ERROR] src/main/java/org/apache/commons/io/output/NullPrintStream.java:[34,5] (javadoc) JavadocMethod: Missing a Javadoc comment. ``` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (IO-585) FilenameUtils#normalizeNoEndSeparator does not sanitize multiple backslashes directly after the colon in windows file paths
[
https://issues.apache.org/jira/browse/IO-585?focusedWorklogId=265381=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-265381
]
ASF GitHub Bot logged work on IO-585:
-
Author: ASF GitHub Bot
Created on: 23/Jun/19 11:36
Start Date: 23/Jun/19 11:36
Worklog Time Spent: 10m
Work Description: adammcclenaghan commented on pull request #79: IO-585:
Sanitize double slash after prefix
URL: https://github.com/apache/commons-io/pull/79
Fixes [IO-585](https://issues.apache.org/jira/browse/IO-585)
When a double slash immediately followed a prefix such as "C:\\" we would
fail to merge the adjoining slashes. This change ensures that slashes of these
type are merged.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 265381)
Time Spent: 10m
Remaining Estimate: 0h
> FilenameUtils#normalizeNoEndSeparator does not sanitize multiple backslashes
> directly after the colon in windows file paths
> ---
>
> Key: IO-585
> URL: https://issues.apache.org/jira/browse/IO-585
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Adam McClenaghan
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> FilenameUtils#normalizeNoEndSeparator states in the javadoc that :
> "A double slash will be merged to a single slash (but UNC names are
> handled)."
> It has been observed that if a double backslash occurs after the colon in a
> windows filepath, then the returned path still contains this double
> backslash. For example:
> {code:java}
> C:\\Program Files\\ExampleDirectory --> C:\\Program Files\ExampleDirectory
> {code}
> While the expectation is that we should be returning ' C:\Program
> Files\ExampleDirectory '
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-io] adammcclenaghan opened a new pull request #79: IO-585: Sanitize double slash after prefix
adammcclenaghan opened a new pull request #79: IO-585: Sanitize double slash after prefix URL: https://github.com/apache/commons-io/pull/79 Fixes [IO-585](https://issues.apache.org/jira/browse/IO-585) When a double slash immediately followed a prefix such as "C:\\" we would fail to merge the adjoining slashes. This change ensures that slashes of these type are merged. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (NUMBERS-119) BigFraction(double) constructor does not treat subnormal numbers correctly
[
https://issues.apache.org/jira/browse/NUMBERS-119?focusedWorklogId=265380=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-265380
]
ASF GitHub Bot logged work on NUMBERS-119:
--
Author: ASF GitHub Bot
Created on: 23/Jun/19 11:21
Start Date: 23/Jun/19 11:21
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #56: NUMBERS-119: Correct
bug in BigFraction(double) constructor
URL: https://github.com/apache/commons-numbers/pull/56#issuecomment-504617374
[](https://coveralls.io/builds/24154043)
Coverage decreased (-0.2%) to 94.169% when pulling
**62c5fd68a18a42eebb3b3913a788359450d094b5 on Schamschi:NUMBERS-119** into
**b1daf7ba9b474c2bc480c006cca1816fa401d1a1 on apache:master**.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 265380)
Time Spent: 50m (was: 40m)
> 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: 50m
> 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)
[GitHub] [commons-numbers] coveralls edited a comment on issue #56: NUMBERS-119: Correct bug in BigFraction(double) constructor
coveralls edited a comment on issue #56: NUMBERS-119: Correct bug in BigFraction(double) constructor URL: https://github.com/apache/commons-numbers/pull/56#issuecomment-504617374 [](https://coveralls.io/builds/24154043) Coverage decreased (-0.2%) to 94.169% when pulling **62c5fd68a18a42eebb3b3913a788359450d094b5 on Schamschi:NUMBERS-119** into **b1daf7ba9b474c2bc480c006cca1816fa401d1a1 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
