Greetings,
The e-less (or E-less, or d-less or D-less) format is readable by any
programming language -- provided the person understands what is in the file.
Technically there might be a tiny pre-processing step of string-replacement, as
noted by Chris. A simple one-liner would do the job.
The ENDF circle of data is never meant to be passed around (also never meant to
be received) without information or definitions. In fact one shouldn't touch
ENDF data before studying the ENDF bible. More so if one is not even sure
whether it is a value or an expression.
A bit anti-social in terms of portability indeed, but the e-less (or E-less, or
d-less or D-less) is certainly very economical in real ENDF data, snapping
tightly and neatly into the fixed-column format.
Whichever language made its way to the podium of that generation, fortran or
not, the common trait is that cross-platform compatibility was not the goal.
Old-fashioned or not, fortran did provide a strong tradition from which modern
languages grew / evolved from.
:) mary
> On 10 August 2015 at 07:47 Chris Theis <Christian.Theis_at_cern.ch> wrote:
>
> 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
> > > <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 <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 Tue Aug 11 2015 - 21:43:35 CEST