Java and Mathematics; modes, means, and extent.
stefan.reich.maker.of.eye at googlemail.com
Mon Apr 30 22:26:49 UTC 2018
Sorry to be so critical :)
On 1 May 2018 at 00:03, Stefan Reich <
stefan.reich.maker.of.eye at googlemail.com> wrote:
> I supported the OP in the beginning, but now I think the request is
> actually dubious.
> Show us some code - yes you have to open it up! - and then say "It is
> running too slowly for application X".
> Otherwise, why should we bother?
> On 30 April 2018 at 12:49, Martijn Verburg <martijnverburg at gmail.com>
>> I think this question has been answered multiple times before. We need to
>> wait on the building blocks of value types et al to see what new
>> mathematics libraries can be written.
>> In the mean time if you need the type of mathematical support you are
>> in a programming language then you’ll have to choose one with that
>> On Mon, 30 Apr 2018 at 08:33, A Z <poweruserm at live.com.au> wrote:
>> > What sorts of changes are possible in Java 2 SE
>> > in the areas of floating point, arithmetic, and mathematics?
>> > The whole thing is, is that certain floating point operators,
>> > upon two floating point types, with the base 10 solution
>> > within range accuracy or not, produces overflow and underflow.
>> > With no option to enforce range accuracy and turn the denormals
>> > off.
>> > There is the case of javax.vecmath.Vector3d, which uses non range
>> > accurate presumption to try and form a denormal vulnerable results
>> > for cross products.
>> > If you need numbers and operations, to range accuracy, beyond the extend
>> > of long, or decimal numbers more precise than double, you then need to
>> > other types.
>> > However the problem is that BigInteger and BigDecimal, or any available
>> > other types,
>> > don't allow the use of operators. BigInteger and BigDecimal types also
>> > aren't pro extensible
>> > inside virtual machine memory either, being heir to an array length
>> > they are not pro extensible.
>> > Also combined with the fact that there isn't an Oracle robust StrictMath
>> > equivalent for BigDecimal,
>> > for trigonometry, advanced powers, nth root, pi and e.
>> > All of these problems are serious reductions in development and
>> > maintanence time, legibility,
>> > even cross language code legibility for less Java centric folk. However
>> > the set of these problems
>> > also includes a forbidding of the extent of allowed numbers (certainly
>> > 64 bit Java).
>> Cheers, Martijn (Sent from Gmail Mobile)
> Stefan Reich
More information about the adoption-discuss