Re: hotspot-dev Digest, Vol 128, Issue 13

classic Classic list List threaded Threaded
3 messages Options
A Z
Reply | Threaded
Open this post in threaded view
|

Re: hotspot-dev Digest, Vol 128, Issue 13

A Z
These are Java SE questions.

-Is it likely that JEP 306 could be updated in a Java update, earlier?
Apart from the assertion 'will not fix', accurate floating point
is a massive requirement.  It isn't very possible to do within-range
float or double multiplies, divides, powers, roots, or even things
in other classes like obtaining the distances between two points
(in Java2D and Java3D).

-Could there be a BigDecimal version of StrictMath
being put in to the standard libraries, under Java's own umbrella,
and not as someone else's separate library?


'Consider the square root function on the interval [1, 2), that is the
half-open region that includes 1 but does not include 2. This
corresponds to the floating-point numbers with an exponent of 0. There
are 2^52 floating-point values with this exponent. Mathematically,
sqrt(1) = 1 and sqrt(2) ~= 1.414... Therefore, in floating-point, for
values 1.0 <= x < 2.0, the result of sqrt(x) also has an exponent of 0.
Now we see that there are 2^52 floating-point values with an exponent of
0 and taking a square root of those values will only yield about 0.414 *
2^52 distinct answers. Therefore, we see that using a fixed
floating-point precision, the square root function on [1.0, 2.0)
*cannot* be inverted losslessly since only a minority of the input
elements have distinct answers.'

It is the case, however, that if the policy is taken, even slightly beyond the range of a decimal value,
e.g. that if the precision is 64, you can rationally aim to get the obverse and inverse of
a value in a function call if you round HALF_UP by means of considering the decimal
in precision 65, which is what I'm trying to suggest.  Some extra logic at the boundary zone,
to facilitate

(pow(sqrt(3),2) == 3) //true

Reply | Threaded
Open this post in threaded view
|

Re: hotspot-dev Digest, Vol 128, Issue 13

David Holmes
"A Z" you already basically asked this in your "Java SE Maths questions"
thread. Please don't create multiple threads on the same issue - and
please never use the subject "hotspot-dev Digest, Vol XXX, Issue NN" -
if replying to a digest please add the correct subject.

Thank you.
David

On 7/12/2017 12:04 PM, A Z wrote:

> These are Java SE questions.
>
> -Is it likely that JEP 306 could be updated in a Java update, earlier?
> Apart from the assertion 'will not fix', accurate floating point
> is a massive requirement.  It isn't very possible to do within-range
> float or double multiplies, divides, powers, roots, or even things
> in other classes like obtaining the distances between two points
> (in Java2D and Java3D).
>
> -Could there be a BigDecimal version of StrictMath
> being put in to the standard libraries, under Java's own umbrella,
> and not as someone else's separate library?
>
>
> 'Consider the square root function on the interval [1, 2), that is the
> half-open region that includes 1 but does not include 2. This
> corresponds to the floating-point numbers with an exponent of 0. There
> are 2^52 floating-point values with this exponent. Mathematically,
> sqrt(1) = 1 and sqrt(2) ~= 1.414... Therefore, in floating-point, for
> values 1.0 <= x < 2.0, the result of sqrt(x) also has an exponent of 0.
> Now we see that there are 2^52 floating-point values with an exponent of
> 0 and taking a square root of those values will only yield about 0.414 *
> 2^52 distinct answers. Therefore, we see that using a fixed
> floating-point precision, the square root function on [1.0, 2.0)
> *cannot* be inverted losslessly since only a minority of the input
> elements have distinct answers.'
>
> It is the case, however, that if the policy is taken, even slightly beyond the range of a decimal value,
> e.g. that if the precision is 64, you can rationally aim to get the obverse and inverse of
> a value in a function call if you round HALF_UP by means of considering the decimal
> in precision 65, which is what I'm trying to suggest.  Some extra logic at the boundary zone,
> to facilitate
>
> (pow(sqrt(3),2) == 3) //true
>
Reply | Threaded
Open this post in threaded view
|

Re: hotspot-dev Digest, Vol 128, Issue 13

dalibor topic-2
In reply to this post by A Z


On 07.12.2017 03:04, A Z wrote:
> These are Java SE questions.
>
> -Is it likely that JEP 306 could be updated in a Java update, earlier?

No.

cheers,
dalibor topic
--
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment