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 |
"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 > |
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 |
Free forum by Nabble | Edit this page |