@CRquantum , if you’re seeking a general and lengthy discourse on numeric edit descriptors in Fortran, then ok.
But with what you mention in the original post with importing on data in Origin Pro, the numeric formatting itself is of far less relevance than the electronic data exchange options with Origin Pro. And what you can do to facilitate the data exchange in your Fortran program (or library code). Here, a CSV library or your own simple solution based on list-directed output, or even G0 can generally meet the needs:
@certik and @sblionel will be looking at the suggestions at the above site in their planning toward Fortran 202Y and it will be most useful for Fortran to have all your ideas and proposals captured there.
During the recent standard revisions including Fortran 2018 and now 202X, the committee led by @sblionel has also paid close attention to various improvements in the IO facilities and a fair number of “goodies” got developed and voted in. For example, “Control over leading zeros in output of real values” in Fortran 202X.
Your ideas and recommendations too can move forward if they can be developed into well formulated and actionable proposals.
If I attach the runtime check option as follows (with ifort2021.6 + Ubuntu20),
ifort -check all test.f90
I get this runtime error:
forrtl: severe (61): format/variable-type mismatch, unit -1, file /proc/3572/fd/1
So maybe we need to set some similar option in the “Run-time” tag in your screen image? (and I think it is useful to both consider “compile-time errors” and “runtime errors”).
FWIW, both gcc and g++ gives warning messages when I attach -Wall
(both gcc-10 and g++-10)
test.c:7:17: warning: format '%f' expects argument of type 'double', but argument 2 has type 'int' [-Wformat=]
7 | printf( "%15.7f\n", n );
| ~~~~~^ ~
| | |
| | int
| double
| %15.7d
(I was a bit surprised that the message of gcc and g++ are very readable in this case… though they give silently wrong values without -Wall, so seem to still need much caution.)
Unfortunately I have been using only gfortran recently, so not very sure about the performance hit by -check all, but I guess the speed-down is pretty significant (but this is just a guess from previous experiences, so YMMV )
FWIW, I attach many check options (both compile-time warnings, runtime errors, set nan to floats, etc) during the development stage. Even close to production runs, I usually keep using those options (e.g. -fcheck=all) together with -O3 etc, which leads to, say, 20-30% speed-down as compared to -O3 only. But I would like to avoid potential problems/issues as much as possible, so I attach check options even at the cost of some slow-down. (And if I really need highest speed, I will of course remove all check options, which is a “dangerous” run in a sense.)
FWIW, nim provides the -d:danger option in addition to the -d:release option to remove all the checks. The naming reminds the users that they are doing something dangerous
(old thread from Nim forum (the current options may be different) Nim forum )
IIRC Julia also keeps bounds check by default even with -O2 (unless macros like @inbounds is attached). I guess this trend is rather common for other languages as well (i.e. default = with all checks, and the user needs to add more and more options etc to “remove” checks).
Thank very much @FortranFan .
The G0 is again amazing
The Origin Pro is just an example, not too important. I just wanted to say that if the format is not displayed correctly such as 1.610456-162, it may cause some trouble. But thanks Origin Pro and let me realized such format issues, and I very much enjoyed learning from you all
)
