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 - 17:07:48 CEST