To who it may concern,

'There was a JSR to add a new mode'


then I suppose I would be asking for that change on float and double, that 
being the case,


as well as an extra mathematics class for BigDecimal.


Despite all the time since 1.1, these are necessary changes,


since having to use BigDecimal for all accurate arithmetic begins


to waste memory, instructions, and the presently unavoidable


translation betwee get/set (float or double) and compute (BigDecimal)


and convert to (float or double).


These are in fact not opinions, but very great needs that the Software


community has needed from java for a very long time now,


despite statement in the Java Language Specification.

________________________________
From: core-libs-dev <core-libs-dev-boun...@openjdk.java.net> on behalf of 
core-libs-dev-requ...@openjdk.java.net <core-libs-dev-requ...@openjdk.java.net>
Sent: Saturday, 3 March 2018 11:00 PM
To: core-libs-dev@openjdk.java.net
Subject: core-libs-dev Digest, Vol 131, Issue 19

Send core-libs-dev mailing list submissions to
        core-libs-dev@openjdk.java.net

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
core-libs-dev Info Page - 
java.net<http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev>
mail.openjdk.java.net
core-libs-dev -- Technical discussion about the development of the core 
libraries About core-libs-dev


or, via email, send a message with subject or body 'help' to
        core-libs-dev-requ...@openjdk.java.net

You can reach the person managing the list at
        core-libs-dev-ow...@openjdk.java.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of core-libs-dev digest..."


Today's Topics:

   1. Re: Floating Point and Arithmetic Changes for Java SE Lnguage
      (Bernd Eckenfels)


----------------------------------------------------------------------

Message: 1
Date: Sat, 3 Mar 2018 08:13:12 +0100
From: Bernd Eckenfels <e...@zusammenkunft.net>
To: "core-libs-dev@openjdk.java.net" <core-libs-dev@openjdk.java.net>
Subject: Re: Floating Point and Arithmetic Changes for Java SE Lnguage
Message-ID: <5a9a4b08.4bab500a.97905.f...@mx.google.com>
Content-Type: text/plain; charset="utf-8"

Hello Anon,

It is impossible to Change the Java behavior for already existing Features like 
the simple Floating Point types. I would not expect much in this area. There 
was a JSR to add a new mode, but it seems to be abandoned: 
https://jcp.org/en/jsr/detail?id=84
The Java Community Process(SM) Program - JSRs: Java 
...<https://jcp.org/en/jsr/detail?id=84>
jcp.org
This JSR has been Withdrawn Reason: Due to the general absence of interest in 
the community, the Specification lead withdrew the JSR. Original Java 
Specification ...



I think there was some discussion on Underflow/Overflow handlers, cant remeber 
where I have seen it. It seems to be not on the current JEP list: 
http://openjdk.java.net/jeps/0
JEP 0: JEP Index<http://openjdk.java.net/jeps/0>
openjdk.java.net
This JEP is the index of all JDK Enhancement Proposals, known as JEPs. See JEP 
1 for an overview of the JEP Process.




BTW: please reconsider your communication strategy (especially on Mailing 
lists). Marking mails as urgent should only be done if you are sure they are 
urgent to all (thousand) receivers, not only to you.

Gruss
Bernd
--
http://bernd.eckenfels.net
Bernd Eckenfels - Home<http://bernd.eckenfels.net/>
bernd.eckenfels.net
Bernd Eckenfels Kurzprofil. Seit 2004 lebe ich in Karlsruhe und seit 1998 mit 
Mela Eckenfels verheiratet. Ich arbeite bei einem mittelständischen Software ...



Von: A Z
Gesendet: Samstag, 3. M?rz 2018 04:25
An: core-libs-dev@openjdk.java.net
Betreff: Floating Point and Arithmetic Changes for Java SE Lnguage
Wichtigkeit: Hoch

I have found that double and float types in java are heirs to arithmetic 
underflow and overflow at any use.

I have found that presently, floating point is an arithmetic approximation.  My 
problem is that

the java language needs to be changed here, so that one may have arithmetic 
accuracy with

floats and doubles.



There is also a trigonometric shortfall when it comes to BigDecimal.



I have attempted to, and have more carefully described these problems, via the 
java bugs database:



JDK-8190947

JDK-8197995

JDK-8190991

JDK-8190946



-These types, as things are, must be computationally discarded, used only in 
terms of push and pull,

and be programmed around using BigDecimal, which will be a waste of memory,

program execution speed, and a total confusion due to the lack of any operator

usage options on BigDecimals.



-It is the case that set, get methods, constructors and mutability methods are 
all based

around float and double, not BigDecimal, which is part of the previous problem.



-It is the case that setting up BigDecimals can be and is a circumstantial 
waste of memory

with very many tasks, combined with the fact that the fact that having to use 
BigDecimal

method calls is nowhere near as efficient or legible to developers or 
mathematics and enginner

programmers (and useful with their time) as



+, -, *, /, %, +=,-+,*=,/=,%=, ++, --



.This is a syntax argument largely, but also an instruction argument

since BigDecimals have to be set up or used with an extra, thereby second, call.



-It is the case that every other major language includes both floating point 
and accuracy mode

options with these two types and or Objects, either as a source code 
instruction or as a

compiler switch option.  These languages at least provide both options for 
floating

point and mathematical accuracy mode.



-It is so that the present arithmetic underflow and underflow are total 
disadvantages,

that need only be changed in place, for preconditions and postconditions.

This is in regard to programs that have been compiled and built already.



-It is also the case that the state of Java floating point for the last 10 
years or so is not really

any argument, given that things can be changed in place remaining reverse 
compatible,

along with how clear and necessary the problem is.



-My Oracle Support technical reviews seem not to recognise these real problems 
whatsoever, or

only interpret matters in terms of the Java Language Specification on these 
issues,

which of itself possesses inadequecies in these places.



Can someone please reply to me on these things?

Can Oracle update the Java SE language?




End of core-libs-dev Digest, Vol 131, Issue 19
**********************************************

Reply via email to