Java and Mathematics; modes, means, and extent.

[Stefan Reich]

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?
>
> 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
>



-- 
Stefan Reich
BotCompany.de