This message follows the RFC
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019560.html
posted on August 2.
The issue is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430.
The proposed patch http://cr.openjdk.java.net/~bpb/8010430/ has the effect of
option (A) in the
The specification of java.lang.Math.round() says
* Returns the closest {@code int} to the argument, with ties
* rounding up.
It is not clarified what is "ties rounding up".
I guess that it should correspond to the direction "roundTiesToAway" of
IEEE 754-2008
and to the java.math.RoundingM
With respect to this issue, the argument satisfies the condition
a == (int)a
or
a == (long)a
so there really is no tie, unless I am missing something. The problem is that
in the current implementation the intermediate result
a + 0.5
is rounded according to the IEEE standard so the conditions
The specification of java.lang.Math.round in the first edition of the
Java Language Specification is quite clear:
public static int round(float a)
The result is rounded to an integer by adding 1/2, taking the floor of
the result, and casting the result to type int.
In other words, the result
I guess that the method java.lang.Math.round() should correspond to
roundToIntegralTiesToAway of the IEEE 754-2008. Standard says about it
(section 5.9):
===
roundToIntegralTiesToAway(x) rounds x to the nearest integral value, with
halfway cases
rounding away from zero
===
So the halfway cases are
This is an interesting point and roundToIntegralTiesToAway() does have an
appealing symmetry, but I think it is a broader issue than the constrained case
I originally posted.
Whichever of the approaches obtains, it seems that if the floating point
argument A represents a real number which is al
There seem to be two distinct issues here:
(1) As originally specified in the first edition of JLS, java.lang.Math.round
sometimes
accepts an argument that is equal to a mathematical integer and returns a value
that
is another (larger) mathematical integer because IEEE rounding occurs in the
ad
Guy pointed to JLS 1 semantics. Yes, it was clearer.
Ok. I agree that java.lang.Math.round() and IEEE 754-2008
roundToIntegralTiesToAway() has different semantics.
The current API specification is a little misleading.
I tried to implement JLS 1 semantics in a bit-twiddling way:
===
public stat
Dmitry Nadezhin wrote:
>Nevertheless, I send this variant now in hope that it may be useful.
Great! It's much faster than what I proposed, cleaner (only integers),
and according to my tests it behaves the same.
-Jeff
On Aug 24, 2013, at 3:02 PM, Jeff Hain wrote:
>
> Dmitry Nadezhin wrote:
>> Nevertheless, I send this variant now in hope that it may be useful.
>
> Great! It's much faster than what I proposed, cleaner (only integers),
> and according to my tests it behaves the same.
Excellent! Nice piece o
On Aug 26, 2013, at 7:52 AM, Guy Steele wrote:
> On Aug 24, 2013, at 3:02 PM, Jeff Hain wrote:
>
>>
>> Dmitry Nadezhin wrote:
>>> Nevertheless, I send this variant now in hope that it may be useful.
>>
>> Great! It's much faster than what I proposed, cleaner (only integers),
>> and according t
Is it reasonable to make specification clearer ?
Either to return JLS 1 specification:
<<<
The result is rounded to an integer by adding , taking the floor of the
result, and casting the result to type long.
>>>
or to replace "rounding up" with "rounding to positive infinity":
<<<
Returns the clos
On Aug 27, 2013, at 7:44 PM, Dmitry Nadezhin wrote:
> Is it reasonable to make specification clearer ?
>
> Either to return JLS 1 specification:
> <<<
> The result is rounded to an integer by adding , taking the floor of the
> result, and casting the result to type long.
> >>>
This verbiage wou
TLS 1 specification contained verbal statement
"The result is rounded to an integer by adding , taking the floor of the
result, and casting the result to type int".
and Java code
Math.floor(f + 0.5).
It seems to me that the verbal statement says about mathematical "+" .
It maps a pair of reals to
On Aug 28, 2013, at 10:55 AM, Dmitry Nadezhin wrote:
> TLS 1 specification contained verbal statement
> "The result is rounded to an integer by adding , taking the floor of the
> result, and casting the result to typeint".
> and Java code
> Math.floor(f + 0.5).
>
> It seems to me that the verbal
Hello,
On 8/23/2013 1:36 PM, Guy Steele wrote:
The specification of java.lang.Math.round in the first edition of the
Java Language Specification is quite clear:
public static int round(float a)
The result is rounded to an integer by adding 1/2, taking the floor of
the result, and casting
Thanks for this context, Joe. And, truth be told, the fact there was a
discrepancy
between the textual and code descriptions of the operation may well have been
my error. (I don't have a clear memory either way, but it's the sort of text
I would have worked on rather than Bill.)
In any case, I
I will update the javadoc in the webrev and repost tomorrow.
Brian
On Aug 28, 2013, at 7:03 PM, Guy Steele wrote:
> In any case, I think everyone is now agreed on "the right thing" for going
> forward.
All right, so I've updated the webrev
http://cr.openjdk.java.net/~bpb/8010430/
which will need final JDK 8 Reviewer approval, I think.
Do the changes at lines 649 and 687 (in the new version) require CCC approval?
Thanks,
Brian
JDK 8 Reviewers:
Following up on this thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/020421.html
an approval from a JDK 8 Reviewer is still needed (assuming of course that the
change is acceptable).
Also, there is the stated question of CCC request necessity.
Thanks,
Hi Brian,
I'd appreciate some additional comments in the body of the code
explaining what is attempted to be implemented.
On the ccc front, since a behavioral change is presumably being made for
a few values, a ccc is justified.
Thanks,
-Joe
On 9/3/2013 1:29 PM, Brian Burkhalter wrote:
J
Hi Joe,
I will proceed on these two points.
Thanks,
Brian
On Sep 3, 2013, at 4:48 PM, Joe Darcy wrote:
> I'd appreciate some additional comments in the body of the code explaining
> what is attempted to be implemented.
>
> On the ccc front, since a behavioral change is presumably being made
Hi Joe,
On Sep 3, 2013, at 4:48 PM, Joe Darcy wrote:
> I'd appreciate some additional comments in the body of the code explaining
> what is attempted to be implemented.
I've updated the webrev to this effect:
http://cr.openjdk.java.net/~bpb/8010430/
There are also some new tests in RoundTests
Hi Brian,
Looks fine; approved to go back.
Thanks,
-Joe
On 9/4/2013 3:16 PM, Brian Burkhalter wrote:
Hi Joe,
On Sep 3, 2013, at 4:48 PM, Joe Darcy wrote:
I'd appreciate some additional comments in the body of the code
explaining what is attempted to be implemented.
I've updated the webre
Hi Joe,
Thanks. I will push this myself once the Committer role is finalized for pushes.
Brian
On Sep 4, 2013, at 8:17 PM, Joe Darcy wrote:
> Looks fine; approved to go back.
25 matches
Mail list logo
