Java precision question

B

Bryan

Hi we are using a offshore company to convert some legacy c++ code to java.

One of the developers is telling me that java has higher multiplication
precision than c++, which is something I find interesting.

Is this true? If so why? I had thought that the precision was
determined by the data type and the architecture, i.e. a double in c++
should have the same precision as a double in java?

Can anyone explain this a bit to me?

Thanks,
B
 
C

Chris Uppal

Bryan said:
One of the developers is telling me that java has higher multiplication
precision than c++, which is something I find interesting.

It's bollocks.

Barring running on J2ME-style devices, where I know nothing about either Java's
floating point requirements, nor what typical C/C++ compilers do.

-- chris
 
T

Tom Hawtin

Bryan said:
One of the developers is telling me that java has higher multiplication
precision than c++, which is something I find interesting.

Is this true? If so why? I had thought that the precision was
determined by the data type and the architecture, i.e. a double in c++
should have the same precision as a double in java?

In general Java defines results for consistency over accuracy.

The original 1.0/1.1 semantics for floating point, required every
operation result to be rounded to a value exactly representable as
double/float. In C++ it may stay in extended precision if it remains in
an FLU register. 1.2+ is slack by default, with strictfp restoring the
predictable semantics.

http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#249198

Trig for *large values* on x87 architectures is likely to be more
accurate, and slower. Java requires normalisation using an arbitrary
accurate value of pi. x87 doesn't support that directly (to be fair
reasonable algorithms didn't exist to do it at the time the 8087 was
first released).

The Math and StrictMath give some information about their methods
(although there is still specification by referencing another
implementation).


Tom Hawtin
 
J

John W. Kennedy

Bryan said:
Hi we are using a offshore company to convert some legacy c++ code to java.

One of the developers is telling me that java has higher multiplication
precision than c++, which is something I find interesting.

Is this true? If so why? I had thought that the precision was
determined by the data type and the architecture, i.e. a double in c++
should have the same precision as a double in java?

Can anyone explain this a bit to me?

A double in Java is /always/ IEEE-754 long (and a float in Java is
/always/ IEEE-754 short). A double or float in C++ is whatever the
compiler writer thought it should be.

Similarly, in Java:
a byte is always twos-complement 8 bits,
a short is always twos-complement 16 bits,
a char is always unsigned 16 bits, and is encoded in UTF-16.
an int is always twos-complement 32 bits, and
a long is always twos-complement 64 bits.

In a Java class or method with the strictfp modifier, and in expressions
evaluated at compile time, all arithmetic will be done strictly
according to IEEE-754. Otherwise, the last few bits may be either more
or less accurate, if it is convenient for the hardware. C++ does not go
into the issue at all.
 
T

tam

Tom said:
The original 1.0/1.1 semantics for floating point, required every
operation result to be rounded to a value exactly representable as
double/float. In C++ it may stay in extended precision if it remains in
an FLU register. 1.2+ is slack by default, with strictfp restoring the
predictable semantics.

http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#249198

This may be misleading. The precision of virtually all floating point
expressions in Java is unaffected by the strictfp qualfier. The only
time
this qualifier comes into play is when very large or small values are
obtained
as intermediate results. Java allows non-strictfp intermediate results
to use
more bits in the exponent but the number of bits used in the mantissa
does not change (see Table 4.1 in the JLS). So regardless of
the availability of extended precision mantissa's in the hardware,
Java programs may not take advantage of them.

Regards,
Tom McGlynn
 
M

Mark Thornton

John said:
A double in Java is /always/ IEEE-754 long (and a float in Java is
/always/ IEEE-754 short). A double or float in C++ is whatever the
compiler writer thought it should be.

Similarly, in Java:
a byte is always twos-complement 8 bits,
a short is always twos-complement 16 bits,
a char is always unsigned 16 bits, and is encoded in UTF-16.
an int is always twos-complement 32 bits, and
a long is always twos-complement 64 bits.

In a Java class or method with the strictfp modifier, and in expressions
evaluated at compile time, all arithmetic will be done strictly
according to IEEE-754. Otherwise, the last few bits may be either more
or less accurate, if it is convenient for the hardware.

Not true. The absence of strictfp only permits an extended range
exponent, no extra (or fewer) mantissa bits are permitted. The only
other effect of not having strictfp is to alter the accuracy
requirements for the Math methods --- strictfp must used a specified
algorithm.

Mark Thornton
 
T

tam

Mark said:
Not true. The absence of strictfp only permits an extended range
exponent, no extra (or fewer) mantissa bits are permitted. The only
other effect of not having strictfp is to alter the accuracy
requirements for the Math methods --- strictfp must used a specified
algorithm.

Mark Thornton

Isn't this slightly confusing two issues? The StrictMath library is
required to produce results identically on all platforms regardless of
the availability of potentially more precise and efficient
implemenetations,
while the standard Math library is given a bit more leeway in how it is
implemented. However I don't think a call to a Math library routine in
a strictfp block uses StrictMath. It still uses the local version of
the Math library
and thus can vary from machine to machine.

So, to ensure the same results on all machines you need to use
StrictMath for all mathematical functions and all calculations need to
be down within strictfp blocks (or methods or classes).

Regards,
Tom McGlynn
 
M

Mark Thornton

Isn't this slightly confusing two issues? The StrictMath library is
required to produce results identically on all platforms regardless of
the availability of potentially more precise and efficient
implemenetations,
while the standard Math library is given a bit more leeway in how it is
implemented. However I don't think a call to a Math library routine in
a strictfp block uses StrictMath. It still uses the local version of
the Math library
and thus can vary from machine to machine.

Sorry you're right.

Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,057
Latest member
KetoBeezACVGummies

Latest Threads

Top