IEEE arithmetic has ~nothing~ to do with Fortran per se (see my comment above) -- the Fortran standard demands its implementation.
Correct. And it is also correct, that the C++ standard does not demand IEEE 754 compliance. There are hardware requirements (i.e. CPU/FPU support) for this. Requireing these would exclude a whole bunch of embedded systems for example.
Fact is that the hardware you will run on is very likely to support IEEE 754.
a type is the union of its storage with its operators. In Fortran, (to the best of my knowledge) using IEEE arithmetic alters these operators,
Huh? Fortran rewires my CPU?!
Different CPUs have different performance characteristics for various operations. Where there is a preferred/faster order of operations, then the compiler can reorganize so that things run faster.
IEEE 754 defines a set of basic operations. What it does not define are rules for the compiler how it must or must not order these operations!
Bear in mind that this goes beyond simple reordering of terms in one calculation. The order can be impacted by MPI communications for example. IEEE 754 says nothing about this, and neither does the Fortran standard.
do you expect bitwise arithmetic to be different, provided that the same sequence of instructions with the same starting values?
Of course not, because the sequence of operations is not the same on different systems and parallelization topologies.
You also think/thought that scientists don't post their trajectories or snapshots.
Nonsense. Maybe you will learn through repetition: Exact trajectories are almost never a relevant physical observable. Read the stuff about uncertainties in initial conditions again please.
The problem you believe Fortran can help you with is not a problem, and furthermore Fortran cannot help you with it anyways. Sorry, man.
