Java and Mathematics; modes, means, and extent.

[Stefan Reich]

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?

Cheers
Stefan

On 30 April 2018 at 12:49, Martijn Verburg <martijnverburg at gmail.com> wrote:

> 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 after
> in a programming language then you’ll have to choose one with that support.
>
> Cheers,
> Martijn
>
> 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
> use
> > 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
> limit;
> > 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 in
> > 64 bit Java).
> >
> --
> Cheers, Martijn (Sent from Gmail Mobile)
>



-- 
Stefan Reich
BotCompany.de