Re: [fluka-discuss]: Bug in formatted output of RESNUCLEi

From: Chris Theis <Christian.Theis_at_cern.ch>
Date: Mon, 10 Aug 2015 14:47:14 +0000

Dear Alberto,


Fortran was the first

compiled language and for many years has been the ONLY computer language.

I highly value your sense of history and I'm always happy to discuss one of my favorite topics (maybe offline as it might not be if general interest), but I'm afraid your knowledge in this specific matter is not complete. The first compiled language was not FORTRAN but A-0 by Grace Hopper developed for the univac I. The compiler, which was a 2 step approach, was developed several years (I'd have to look up the exact date) before Backus developed the first complete 1-step compiler for FORTRAN in 57. One should not forget A-2 and A-3 developed in 1955. So I'm afraid there have been several languages in parallel to FORTRAN, though the latter one was certainly the most successful of them.

There is no standardized E notation and therefore newer languages are not required to ensure backward compatibility. There is just a common understanding how modern languages handle this problem of the decimals used in the exponent and FORTRAN is now perfectly capable of using 3 digits as well, if specified.

I'm afraid that if I need to know specifics of a program that created a value in order to correctly read and interpret this value, then I still consider this "feature" flawed. However, everybody is entitled to his opinion and if you consider it as good practice then you agree of course free to do so. Yet, it is an opinion which was clearly not shared by the standardization committees of most other languages that were developed later.

Chris


On 10 Aug 2015, at 16:16, Fasso, Alberto <fasso_at_slac.stanford.edu<mailto:fasso_at_slac.stanford.edu>> wrote:


Dear Chris,

your mail shows a complete lack of historical sense. Fortran was the first

compiled language and for many years has been the ONLY computer language. You cannot say that one of its feature is "a flawed one" because you have "a supposedly human-readable ASCII file" and you don't know which language has written it. Of course, if Fortran is the only language, the file has been written by Fortran :-)

Now people have invented new languages: it was up to them to ensure back-compatibility. At the time Fortran was invented, there was no reason to prepare for something else.


Having said that, I must admit that the so-called "E less" floating point format is not foreseen in the Fortran standard, although many

documents on neutron cross sections have been written for decades

in that format. The whole story is told by the "inventor" of "E less"

(D.E. "Red" Cullen) in the IAEA Note IAEA-NDS-217, which can be

found here:

http://home.comcast.net/~redcullen1/Papers/ENDF2C/ENDF2C-IAEA%20NDS-2015.pdf

Please note that the same document presents a "universal" code

ENDF2C, which "is designed to convert ENDF data to standard FORTRAN, C and C++ format". This code is designed for:

1) ENDF data in any ENDF format = ENDF-1 through ENDF-6.
2) On any type of computer = 32- or 64-bit system/compiler ​
The story can be read from Page 5 on.

Alberto


________________________________
From: Chris Theis <Christian.Theis_at_cern.ch<mailto:Christian.Theis_at_cern.ch>>
Sent: Monday, August 10, 2015 6:27 AM
To: Fasso, Alberto; Alexander Michael Krainer
Cc: fluka-discuss_at_fluka.org<mailto:fluka-discuss_at_fluka.org>
Subject: Re: [fluka-discuss]: Bug in formatted output of RESNUCLEi

Dear Alexander and Alberto,

as pointed out by Alberto this is not a bug but a feature of the language, even though a flawed one.

Alexander, as a workaround you can either read the values as strings and then search for the last (!) + or - and insert an "E" before conversion to a number. Please keep also in mind that FORTRAN might also use a D instead of an E to denote double precision. This usually poses a problem for other languages as well, who commonly use double precision for non-integer constants by default.

Another solution is possible if you're working with languages that provide support for I/O streams like C++ or Java. Then you can extract a real number from the stream and subsequently check the status. If the error bit is set and the stream is not empty then you can retrieve the remainder assuming that it is the exponent and reconstruct the original value.

Other languages are not so tolerant...

Alberto, with all due respect but where exactly do you see tolerance if one is forced to use a specific language with specific formatting identifiers in order to correctly read back a value from a supposedly human-readable ASCII file? If you only receive a data file containing "5.9910-213" without any additional information then how do you know if you are dealing with an expression or a rather odd notation artifact? Just on a side-note, other languages like C, C++, Java etc. circumvent this problem by design already as they use 3 decimals for the e notation by default. Thus, they can always output the full range available for normalized double precision values without resorting to notation that is ambiguous without prior knowledge about the language and the program creating those values.

Cheers
Chris



On 06 Aug 2015, at 19:29, Fasso, Alberto <fasso_at_SLAC.Stanford.EDU<mailto:fasso_at_SLAC.Stanford.EDU>> wrote:

Hi Alexander,
that is not a bug, and should not give any problem when reading this data into
another program, provided the other program is written in Fortran. The E is
not compulsory when expressing floating point numbers in Fortran.
Many important data (e.g. evaluated ENDF cross sections) are written that way.

See the discussion in http://stackoverflow.com/questions/24004824/for-three-digit-exponents-fortran-drops-the-e-in-the-output
In particular:
"There is a strong flavour of "fixed column width" to Fortran formatted input and output. Without the exponent field width specification, the "default" width is two. If the exponent part requires one more position than that, then the column normally occupied by the E is borrowed to at least permit output to continue without loss of information. If the exponent output requires two more than the default, then you'll see stars".

Other languages are not so tolerant...

Alberto


________________________________________
From: owner-fluka-discuss_at_mi.infn.it<mailto:owner-fluka-discuss_at_mi.infn.it> <owner-fluka-discuss_at_mi.infn.it<mailto:owner-fluka-discuss_at_mi.infn.it>> on behalf of Alexander Michael Krainer <krainer_at_student.tugraz.at<mailto:krainer_at_student.tugraz.at>>
Sent: Thursday, August 6, 2015 8:11 AM
To: fluka-discuss_at_fluka.org<mailto:fluka-discuss_at_fluka.org>
Subject: [fluka-discuss]: Bug in formatted output of RESNUCLEi

Der Fluka authors,

I have found a bug in the formatted output of the RESNUCLEi card when
using it with
IRRPROFI, DCYTIMES and DCYSCORE. (see attached input file)

If you score the residual nuclei after a specific decay time, some of
the activities become really small (e.g. 5.9910E-213), but the
formatted output can only handle two digits exponents so the output
becomes
5.9910-213. This can cause problems when reading this data into
another program.

Best regards
Alexander Krainer
__________________________________________________________________________
You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id¬c_info


__________________________________________________________________________
You can manage unsubscription from this mailing list at https://www.fluka.org/fluka.php?id=acc_info
Received on Mon Aug 10 2015 - 18:20:09 CEST

This archive was generated by hypermail 2.3.0 : Mon Aug 10 2015 - 18:20:10 CEST