Is Fortran more accurate than Java ?

M

mmquan

public class ex4{
public static void main(String[] args){
double eps[] = new double[5];
double a12, a34;
eps[1] = Double.longBitsToDouble(0x4037CB020C49BA5EL);
eps[2] = Double.longBitsToDouble(0x403C1E76C8B43958L);
eps[3] = Double.longBitsToDouble(0xBFF943D46B26BF87L);
eps[4] = Double.longBitsToDouble(0xBFF943D46B26BF87L);
System.out.println(Long.toHexString(Double.doubleToLongBits(eps[1]*eps[2]-eps[3]*eps[4])));
a12 = eps[1]*eps[2];
a34 = eps[3]*eps[4];
System.out.println(Long.toHexString(Double.doubleToLongBits(a12-a34)));
}
}
I wrote a similar program in Fortran, but I get different results of
the first output. I know the second output should be the same because
the two operands of the subtraction are rounded to 64 bits. But the
first one in Fortran is an intermediate results with 80 bits but what
about Java, did Java also use the same 80 bits as the subtraction
operands?
this is the output of Java:
4084d455e2cff391
4084d455e2cff391
this is the output of Fortran:
4084D455E2CFF392
4084D455E2CFF391
Thanks for your responding!
 
A

ak

this is the output of Java:
4084d455e2cff391
4084d455e2cff391
this is the output of Fortran:
4084D455E2CFF392
4084D455E2CFF391

it looks like java is more accurate than Fortran!
 
T

Tom McGlynn

VisionSet said:
more precise
While I'm not clear what the original poster was comparing -- the message didn't
show up here -- there is no general answer about whether Fortran's
arithmetic is more or less precise or accurate than Java's. Unlike Java, Fortran does not
specify as part of the language the precision of arithmetic types nor
the accuracy of numerical computations. There are, e.g., many implementations
of Fortran with 16-byte floating point numbers as arithmetic type. Indeed
the very first Fortran I worked with on the old IBM 1620 allowed floating
point numbers of arbitrary precision up to the storage limits of the machine --
a massive 20,000 digits (not bytes this was a decimal machine).

This approach has strengths and weaknesses. Fortran is far more portable
than Java since it doesn't specify a detailed arithmetic model. There is no problem
if you have one's complement integers and non-IEEE floating point. Users can
dynamically indicate the desired range and precision they need for variables and get the
appropriate types for the current architecture. On the other hand the behavior
of Fortran programs can be sensitive to the details of these models in ways
that Java's strict specification of the underlying arithmetic precludes. By making
the language itself rather less portable, Java makes programs written in it more so.

Regards,
Tom McGlynn
 
A

Andrea Polci

Tom said:
...

This approach has strengths and weaknesses. Fortran is far more portable
than Java since it doesn't specify a detailed arithmetic model.

When you say "Fortran is far more portable than Java" you mean:

1) The Fortan compiler is more portable

2) A program written in Fortran is more portable

May be 1) is true but 2) is false, based on what you ar saying. And
programmers are more interested in 2) than in 1)

Users in java don't have to care about the specific implementation of
the wirtual machine. They know that int or double means every time the
same thing.

This is what I call a portable language.

May be Fortran is more efficient (in aritmetic calculations) tha Java,
cause the implementation don't have to reproduce a behavior that can
differ from the one produced by the hardware.

Andrea
 
R

Roedy Green

ndeed
the very first Fortran I worked with on the old IBM 1620 allowed floating
point numbers of arbitrary precision up to the storage limits of the machine --
a massive 20,000 digits (not bytes this was a decimal machine).

old COGO or something else? Are you confusing this with the 1410?
 
E

Eric Sosman

Roedy said:
old COGO or something else? Are you confusing this with the 1410?

Tom's description matches the IBM 1620 that was my
first computer, too -- except we had *40,000* digits!

Along with its value of 0-9, each digit could also
carry a "flag" (and there were a few special-purpose non-
digits, too). Arithmetic operated on "fields," addressed
at the least-significant digit and proceeding leftwards
until a flagged digit was encountered (a flag on the
low-order digit itself indicated a negative number). So
setting up numbers of arbitrary precision was dead easy:
you just gave yourself a little more space and plunked the
left-end flag a little farther from the right-end.

The machine's arithmetic circuitry used an addition
table resident in 100 low-core memory locations (and if
you were unlucky enough to overwrite them with a wild
array index, *nothing* worked right any more). Hence
the unofficial and disparaging nickname of CADET: "Can't
Add, Doesn't Even Try."

<http://www.fact-index.com/i/ib/ibm_1620.html>
 
R

Roedy Green

So
setting up numbers of arbitrary precision was dead easy:
you just gave yourself a little more space and plunked the
left-end flag a little farther from the right-end.

My very first exposure to computers was GOGO on the 1620. I don't
recall the ability to set the "word marks" in Fortran. I remember that
my first program 12! overflowed the int. From that I can probably
guess what the default precision was.
 
J

John B. Matthews

Andrea Polci said:
When you say "Fortran is far more portable than Java" you mean:

1) The Fortan compiler is more portable

2) A program written in Fortran is more portable

May be 1) is true but 2) is false, based on what you ar saying. And
programmers are more interested in 2) than in 1)

Users in java don't have to care about the specific implementation of
the wirtual machine. They know that int or double means every time the
same thing.

This is what I call a portable language.

May be Fortran is more efficient (in aritmetic calculations) tha Java,
cause the implementation don't have to reproduce a behavior that can
differ from the one produced by the hardware.

Andrea

Implying 1), Tom went on to say:

I would extend this characterization of Java portability to
include data as well. This is immensely valuable in a
heterogenous architecture.

John
 
E

Eric Sosman

Roedy said:
My very first exposure to computers was GOGO on the 1620. I don't
recall the ability to set the "word marks" in Fortran. I remember that
my first program 12! overflowed the int. From that I can probably
guess what the default precision was.

The FORTRAN compiler could be fed an "IandF" control
card specifying the sizes of integer and floating-point
variables. I no longer recall the default sizes.

Of course, SPS (the assembler) let you put the flags
wherever you wanted, so you could mix'n'match different
field sizes in a single program. An excellent way to
become confused ...
 
T

Tom McGlynn

Andrea Polci said:
When you say "Fortran is far more portable than Java" you mean:

1) The Fortan compiler is more portable

2) A program written in Fortran is more portable

May be 1) is true but 2) is false, based on what you ar saying. And
programmers are more interested in 2) than in 1)

Users in java don't have to care about the specific implementation of
the wirtual machine. They know that int or double means every time the
same thing.

This is what I call a portable language.

May be Fortran is more efficient (in aritmetic calculations) tha Java,
cause the implementation don't have to reproduce a behavior that can
differ from the one produced by the hardware.

Andrea

Portability has a variety of shadings. I'd tend to think of it
as being able to move a working program to another machine/environment
easily. In this context it's certainly easy to move Java programs
amongst environments that support the JVM. On the other hand it's
hard to implement the JVM (at least with any efficiency)
on any environment that doesn't use two complements integers and
IEEE real arithmetic. So if there is a JVM in the destination
environment, a Java program probably ports pretty easily, but if
not one may be entirely out of luck.

Fortunately (though certainly not by coincidence), there was far
greater agreement amongst computer manufacturers about
the arithmetic models to be used at the time Java was developed than
when
Fortran was originally developed, so that this restricted model
is not as limiting as it would have been even as late as 1985 or even
1990.
There are still plenty of machines for which it is a problem but they
don't seem to have much market share (and I suppose emulators can
be used when efficiency is not an issue).

Even the first release of Java did run into this issue. Most
implementations
of Java 1.0 on PC's were non-compliant with the restrictive arithemtic
model that was in the original standard -- I think this includes
Sun's own implementation for PCs. The next release loosened
the requirements on the model a little to make reasonably efficient
implementations on PCs feasible.

That's why I said in my earlier message that Fortran is more portable
since it can fit naturally into a much wider variety of environments
than Java can, e.g., even on machines which use decimal rather than
binary numbers. I could run the first program I wrote, a random
numbers
finder, on the IBM 1620 and I believe it would probably run correctly
with
essentially no changes on the computer I'm writing this on -- though
I've long since lost the cards it was punched on. I find it unlikely
that there will be a port of Java to the IBM 1620 so here's a test
of portability where Fortran might win...

However that same flexibility means that legal Fortran
programs can and do give somewhat different results on different
machines
or even on the same machine using different compilers. Usually this
isn't an issue, but it can occasionally be a real problem.

For most of us peons who need to port software from one machine to
another
this is rarely an issue that we need to address. Occasionally it
might come up when we consider the language in which we are going
to write an application. However, both Java and standard Fortran are
very
widely portable among the machines commonly in use today.
So other differences between the languages usually dominate that
choice.

Note that most Fortran compilers provide support for extensions to the
language. Most issues with portability of Fortran programs arise from
use of such extensions rather than constructs within the language
standard. These
are sometimes comparable to the concerns that many Java programmers
have in trying to build portable code that runs efficiently in
multiple Java releases.

Regards,
Tom McGlynn
 
M

Michael Borgwardt

mmquan said:
I wrote a similar program in Fortran, but I get different results of
the first output. I know the second output should be the same because
the two operands of the subtraction are rounded to 64 bits. But the
first one in Fortran is an intermediate results with 80 bits but what
about Java, did Java also use the same 80 bits as the subtraction
operands?

No, Java's floating point arithmetic is strictly specified to be 64 bit,
it's not allowed to use the 80 bit registers for additional precision.
Actually, it can make some use of the additional bits, but not for
precision, see this thread for details:
http://groups.google.de/[email protected]
 

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,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top