ANINT for large doubles with Intel Fortran

[Michaël Baudin]

Hi,

I am interested in rounding large double precision real values in the
range [2^52,2^53]. I use Intel(R) Visual Fortran Compiler XE 12.0.4.196
[IA-32] and I compile the following test program.

program test_anint
double precision x
double precision nearestx
x= 4503599627370499
nearestx = anint(x)
print *, x, nearestx
end program test_anint

For this particular value of x, we should have ANINT(X) and X equal.

In Debug mode, I get an error:
4.503599627370499E+015 4.503599627370500E+015

But in release mode, I get the correct result:
4.503599627370499E+015 4.503599627370499E+015

Hence, I feel that the debug compiling process fails, but the release
(i.e. optimized) process successes.

Does anyone have an explanation for this ?

Regards,

Michaël Baudin

[arjenmarkus]

I can reproduce this behaviour on Windows (with Intel Fortran 11), but
not on Linux. Really odd.

Regards,

Arjen

[arjenmarkus]

Just a minor issue, and it does not solve the problem either,
but the constant is too large to fit into an ordinary integer
as gfortran indicates.

After turning it into a double precision constant, the complaint
by gfortran is gone but the error remains.

Regards,

Arjen

[Tim Prince]

It's been a very long time since I've installed the 32-bit compiler.
As you no doubt noted, the Intel IA32 compiler still uses some "IA32"
x87 mode code when /Od is set. I get the same discrepant result for
release mode when setting /arch:IA32.
If you're concerned about the behavior of IA32 mode, you could try the
effect of setting precision mode to 64-bit precision. Perhaps it is a
CPU glitch associated with 53-bit precision mode (dictated by Microsoft)
and double rounding. Ifort and Windows don't make it easy to change
precision mode. If you do set precision mode to 64, of course, you
bring back all the issues of unpredictable extra precision.
It's been a decade since SSE2 was introduced, and most of a decade since
Windows X64 came out. If you have a reason for putting priority on the
behavior of IA32 mode, or getting pure SSE2 in debug mode in the 32-bit
compiler, you might submit a ticket explaining your requirement on your
premier.intel.com account.

--
Tim Prince

[gmail-unlp]

On Linux (x86_64) - gfortran (4.4.4):

1) The example does not compile.

2) With
x = 4503599627370499.0

(compile-run)
$ gfortran test_anint.f90
$ ./a.out
4503599627370496.0 4503599627370496.0
(right hand value taken as a real constant, I think)

3) With
x = 4503599627370499.0D0

$ gfortran test_anint.f90
$ ./a.out
4503599627370499.0 4503599627370499.0

Do you have something like Linux i686? Does it make the difference?

Fernando.

[John Harper]

That program is nonstandard if x is bigger than any default integer, as it
is in an i386 linux system. All four of gfortran, g95, Sun f95 and ifort
said so, though ifort wouldn't without the -stand f90 or f95 or f03 option.
If I change the program as below it compiles, runs and gives the right
answer with no error or warning messages with all four of those compilers.

program test_anint
integer,parameter:: ilong = selected_int_kind(16)

double precision x
double precision nearestx

x= 4503599627370499_ilong

nearestx = anint(x)
print *, x, nearestx
end program test_anint

--
John Harper

[Tim Prince]

Try ifort -Qpc80 if you want to avoid this glitch in x87 code. It has
the effect of setting precision mode back to 64. But maybe you really
don't want x87 (or 32-bit mode).

[Louisa]

First, your constant is integer, may overflow, may not be converted
to real correctly.
Second, the PRINT statement can do anything it likes.
You need to use formatted output.
Third, you probably need to look at the internal representations
of x and nearestx to verify that you have the nearest integer.

[Terence]

On Sep 26, 7:05 pm, Michaël Baudin <michael.bau...@scilab.org> wrote:

There's a note in my old Fortran Manual, that the ANINT function (and
similar) requires that the value X to be operated on, must not have an
absolute magnitude than can be stored as an integer, (even though the
final result is of type real).
Could this be the case here?

[Tim Prince]

The reported anomaly, as several of us verified, applies only to the
debug and /arch:IA32 modes of the Intel 32-bit compiler, with the
default /Qpc64 option, which is not the version I normally use. So it
appears to be an ancient "hardware" "feature" of the x87 precision mode
implementation.
As you rightly point out, ifort has an extension to accept a constant
which doesn't fit a default integer, which the -stand option will disable.

--
Tim Prince

[Richard Maine]

Louisa <louisa...@gmail.com> wrote:

> On Sep 26, 7:05 pm, Michaël Baudin <michael.bau...@scilab.org> wrote:

...
> > print *, x, nearestx
...

> Second, the PRINT statement can do anything it likes.
> You need to use formatted output.

Please note that the PRINT statement shown (well, and any PRINT
statements for that matter) *IS* formatted. It uses list-directed
formatting. What you almost certainly intend is to suggest using an
explicit format.

It is a moderately common error for people to refer to list-directed as
"unformatted". The standard uses the term "list-directed". The term
"free format" is also common. The term "unformatted" is just wrong. This
terminology error can be important because it directly causes people to
write code that doesn't work. For example, I have seen people specify
form="unformatted" in an OPEN statement because they intended to use
what they referred to as unformatted output.

That kind of programming error is why I tend to give a knee-jerk
reaction like this one to that particular terminology error.

This terminology error also causes problems when people try to describe
code to someone helping them with it, but it is just one of many
problems with that mode of operation. It is one I've seen enough to know
to prompt for clarification of to make sure that they actually mean what
they said, much like I prompt when people describe something as being a
parameter (they often mean a dummy argument instead of a named
constant).

As somewhat of an aside, the standard does allow compilers a lot of
freedom in some details of list-directed output, but it isn't entirely
accurate to say that the compiler can do "anything it likes". In
particular, changing this particular example to use an explicit format
would not help. For list-directed output of a real, the compiler is
required to use an E or F format. The compiler can choose the particular
precision and field width, but it can't do just anything. It is
certainly possible for the compiler to choose a precision or field with
that is unsuitable for a particular application, in which case I quite
agree that specifying the details yourself in an explicit format is the
usually recommended solution.

However, in this particular case, the compiler's choice of precision and
field width does not appear to be problematic. The only potential
problem that I see here in the formatting relates to the possibility of
rounding. The standard does not guarantee the details of rounding in
formatted output (unless one is using the IEEE features of the f95 TR or
f2003). I would not guess that does not appear to be the problem here,
but if it were, it could apply equally to list-directed and explicit
formatting.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[glen herrmannsfeldt]

Terence <tbwr...@cantv.net> wrote:

(snip)

> There's a note in my old Fortran Manual, that the ANINT function (and
> similar) requires that the value X to be operated on, must not have an
> absolute magnitude than can be stored as an integer, (even though the
> final result is of type real).

For a really old manual, there wouldn't be an ANINT function, but
AINT goes back pretty far. Way too often I have seen people use INT
in this case, which does likely cause problems if the result won't
fit in an integer. That shouldn't be true for AINT, and also,
I would hope, not for ANINT. It might be a feature of your compiler.

> Could this be the case here?

-- glen

[timprince]

Seems unlikely, given that the additional pc80 option suppresses this
artifact of x87 53-bit precision mode for this specific compiler version.

--
Tim Prince

[Ron Shepard]

In article <9eghuf...@mid.individual.net>,

timprince <tpr...@computer.org> wrote:

> > There's a note in my old Fortran Manual, that the ANINT function (and
> > similar) requires that the value X to be operated on, must not have an

not?

> > absolute magnitude than can be stored as an integer, (even though the
> > final result is of type real).
> > Could this be the case here?
>
> Seems unlikely, given that the additional pc80 option suppresses this
> artifact of x87 53-bit precision mode for this specific compiler version.

I agree with this. If I interpret the OP sentence the way I think it
was meant, then that would seem to defeat the purpose of the
function for many input values. In addition to AINT() and ANINT()
to extract the integer part of floating point values, there is also
the complementary AMOD() to extract the fractional part. If the
AINT() function returns the wrong result, then the AMOD() probably
does too.

This is probably a quality of implementation issue (rather than a
standards conformance issue), but this does seem like an important
set of functions for an implementation to get wrong.

$.02 -Ron Shepard

[ken.fa...@gmail.com]

But isn't the root of all this that the OP's example used an integer (on the RHS of "x=4503599627370499") that was too large in magnitude to be represented in a default integer?

And wasn't the solution to either (a) make the RHS a "proper" double precision constant, i.e., by appending ".D0" to the integer part, or (b) by using a sufficient integer kind, i.e., by appending "_longint" to the integer on the RHS with a suitable definition of "longint"?

A lot of the surrounding discussion seems to have lost the core of the problem and degenerated into what amounts to compiler extensions or particular HW options.

Just asking...

-Ken

[Tim Prince]

On 9/28/2011 2:02 PM, ken.fa...@gmail.com wrote:
> But isn't the root of all this that the OP's example used an integer (on the RHS of "x=4503599627370499") that was too large in magnitude to be represented in a default integer?
>
> And wasn't the solution to either (a) make the RHS a "proper" double precision constant, i.e., by appending ".D0" to the integer part, or (b) by using a sufficient integer kind, i.e., by appending "_longint" to the integer on the RHS with a suitable definition of "longint"?
>

No, while it was agreed that one of those changes would make it a
conforming program, it was also shown they didn't affect the result in
question.

--
Tim Prince

[glen herrmannsfeldt]

ken.fa...@gmail.com wrote:

> But isn't the root of all this that the OP's example used an
> integer (on the RHS of "x=4503599627370499") that was too large
> in magnitude to be represented in a default integer?

x= 4503599627370499
nearestx = anint(x)
print *, x, nearestx

Possible, but it shouldn't be. Note that as far as the program
is concerned, it is the value in x that is important. That could
be different from the constant given, but anint should still give
the appropriate result.

But there are many ways to get this wrong. One is to do it as
compile time constants, in which case it can depend on the compiler
simulation of a floating point processor. (Many compilers of that
age did software floating point, even when compiling on, and
for targets with, the x87 coprocessor.)

Now, if the result was 4503599627370499 modulo 2**32 then I
would agree that it was converting to integer.

-- glen

[ken.fa...@gmail.com]

On Wednesday, September 28, 2011 11:53:33 AM UTC-7, Tim Prince wrote:
[...]

> No, while it was agreed that one of those changes would make it a
> conforming program, it was also shown they didn't affect the result in
> question.

That's not how I read John Harper's response.

He said, "If I change the program as below it compiles, runs

and gives the right answer with no error or warning messages

with all four of those compilers (gfortran, g95, Sun f95 and ifort)."

Where John's changes were:

integer,parameter:: ilong = selected_int_kind(16)
and:
x= 4503599627370499_ilong

What is it about "...and gives the right answer..." that
leads you to say, "it was also shown they didn't affect
the result in question"???

-Ken

[Tim Prince]

Arjen pointed out that changing the big integer to a double precision
constant didn't alter the behavior of the Intel compiler, except for
allowing it to accept the code when -stand is set. The discrepancy is
seen only when using the Intel 32-bit compiler to generate x87 code,
possibly only on Windows, when the /Qpc option is defaulted to /Qpc64
(53-bit precision mode). /Qpc80 is needed to set 64-bit precision mode,
which is the default for other compilers mentioned, when running x87
mode (and is required to support real*10, for those compilers which have
such a data type).
John didn't specify whether he tested x87 code in 53-bit precision mode,
so I have to assume not.

--
Tim Prince

[ken.fa...@gmail.com]

OK, fair enough. :-)

-Ken

[John Harper]

Sorry if I gave insufficient information about my experiments. I was using a
linux Redhat system and not in 53-bit precision mode. My default integers
use 32 bits, and huge(1) was 2147483647 with all four of the compilers I
tried. My ifort version was 12.0.2.

--
John Harper

[glen herrmannsfeldt]

John Harper <john....@vuw.ac.nz> wrote:

(snip)

> Sorry if I gave insufficient information about my experiments. I was using a
> linux Redhat system and not in 53-bit precision mode. My default integers
> use 32 bits, and huge(1) was 2147483647 with all four of the compilers I
> tried. My ifort version was 12.0.2.

Some compilers that don't support larger integers might instead,
and contrary to the standard, generate a floating point constant.

It is sometimes hard to predict the results from x87 code
keeping values in extended precision, though, so you can
still get unexpected answers with a REAL constant.

-- glen

[Louisa]

On Sep 30, 12:21 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:

> Some compilers that don't support larger integers might instead,
> and contrary to the standard, generate a floating point constant.

Now why would they do that?
It wouldn't be valid in an integer-valued expression,
and would immediately overflow when loaded and converted.

[Louisa]

On Sep 27, 10:56 pm, Terence <tbwri...@cantv.net> wrote:

> There's a note in my old Fortran Manual, that the ANINT function (and
> similar) requires that the value X to be operated on, must not have an
> absolute magnitude than can be stored as an integer, (even though the
> final result is of type real).

> Could this be the case here?-

Can overflow when the largest integer is exceeded.
Whether a specific error is generated may depend on the
compiler.

[Louisa]

On Sep 28, 1:45 am, nos...@see.signature (Richard Maine) wrote:

> Louisa <louisa.hu...@gmail.com> wrote:
> > On Sep 26, 7:05 pm, Michaël Baudin <michael.bau...@scilab.org> wrote:
> ...
> > >        print *, x, nearestx
> ...
> > Second, the PRINT statement can do anything it likes.
> >         You need to use formatted output.
>
> Please note that the PRINT statement shown (well, and any PRINT
> statements for that matter) *IS* formatted. It uses list-directed
> formatting. What you almost certainly intend is to suggest using an
> explicit format.

The term "list-directed formatting" is an inappropriate description.
To say that such output (that follows little rhyme or reason) is
"formatted" is ridiculous.

Real programmers understand that formatted output means explicit
format control, using such items as I, F, E, A, etc.

> It is a moderately common error for people to refer to list-directed as
> "unformatted". The standard uses the term "list-directed". The term
> "free format" is also common. The term "unformatted" is just wrong. This
> terminology error can be important because it directly causes people to
> write code that doesn't work. For example, I have seen people specify
> form="unformatted" in an OPEN statement because they intended to use
> what they referred to as unformatted output.

That has nothing to do with formatted output.

> That kind of programming error is why I tend to give a knee-jerk
> reaction like this one to that particular terminology error.
>
> This terminology error also causes problems when people try to describe
> code to someone helping them with it, but it is just one of many
> problems with that mode of operation. It is one I've seen enough to know
> to prompt for clarification of to make sure that they actually mean what
> they said, much like I prompt when people describe something as being a
> parameter (they often mean a dummy argument instead of a named
> constant).

That, of course, has nothing whatever to do with the subject.

> As somewhat of an aside,

How curious to call it an "aside", when it is directly relevant
(unlike the irrelevant references to dummy arguments).

> the standard does allow compilers a lot of
> freedom in some details of list-directed output, but it isn't entirely
> accurate to say that the compiler can do "anything it likes". In
> particular, changing this particular example to use an explicit format
> would not help. For list-directed output of a real, the compiler is
> required to use an E or F format. The compiler can choose the particular
> precision and field width, but it can't do just anything.

Did I exaggerate? I don't think so.

It does (do anything). And can (do anything).
It can use any layout that it likes; it can print any number of digits
that it likes.
And it can give insufficient digits.
And it doesn't even have to do that.
It can even use the notation n*value where n is a repeat factor.
There's no guarantee as to what rounding it uses.
It can (and does) put in any number of superfluous blanks.
Little if anything is consistent from compiler to compiler.
Surely you have noticed this?

> It is
> certainly possible for the compiler to choose a precision or field with
> that is unsuitable for a particular application, in which case I quite
> agree that specifying the details yourself in an explicit format is the
> usually recommended solution.
>
> However, in this particular case, the compiler's choice of precision and
> field width does not appear to be problematic.

You don't know, because the internal values weren't supplied.

> The only potential
> problem that I see here in the formatting relates to the possibility of
> rounding. The standard does not guarantee the details of rounding in
> formatted output (unless one is using the IEEE features of the f95 TR or
> f2003). I would not guess that does not appear to be the problem here,
> but if it were, it could apply equally to list-directed and explicit
> formatting.

It could, but there's no guarantee that it would.
That's why I suggested printing the internal values.

[glen herrmannsfeldt]

Even more, they might do it in double precision. For many years,
systems with 16 bit INTEGER, 32 bit REAL, and 64 bit DOUBLE PRECISION
(again, contrary to the standard which requires INTEGER and REAL
to be the same size) were in use. REAL and DOUBLE PRECISION
(or, often, REAL*8) were used in place of larger integers.

-- glen

[glen herrmannsfeldt]

Louisa <louisa...@gmail.com> wrote:
> On Sep 28, 1:45 am, nos...@see.signature (Richard Maine) wrote:

(snip)

>> Please note that the PRINT statement shown (well, and any PRINT
>> statements for that matter) *IS* formatted. It uses list-directed
>> formatting. What you almost certainly intend is to suggest using an
>> explicit format.

> The term "list-directed formatting" is an inappropriate description.
> To say that such output (that follows little rhyme or reason) is
> "formatted" is ridiculous.

Many of us make the mistake, usually without thinking about it,
at least once.

The formatted/unformatted distinction goes back to Fortran I.

List-directed, at least by that name as far as I know, comes
from PL/I with the GET LIST and PUT LIST statements. It wasn't
added to the standard until Fortran 77.

> Real programmers understand that formatted output means explicit
> format control, using such items as I, F, E, A, etc.

(snip)

>> the standard does allow compilers a lot of
>> freedom in some details of list-directed output, but it isn't entirely
>> accurate to say that the compiler can do "anything it likes". In
>> particular, changing this particular example to use an explicit format
>> would not help. For list-directed output of a real, the compiler is
>> required to use an E or F format. The compiler can choose the particular
>> precision and field width, but it can't do just anything.

> Did I exaggerate? I don't think so.

> It does (do anything). And can (do anything).
> It can use any layout that it likes; it can print any number of digits
> that it likes.
> And it can give insufficient digits.
> And it doesn't even have to do that.
> It can even use the notation n*value where n is a repeat factor.
> There's no guarantee as to what rounding it uses.
> It can (and does) put in any number of superfluous blanks.
> Little if anything is consistent from compiler to compiler.
> Surely you have noticed this?

As far as I know, those are all true. I have not seen one use
a repitition factor, though it is legal in list-directed input.

List-directed is especially useful for debugging, as it takes
much less writing.

PL/I uses a different distinction. There is STREAM I/O, which
has many of the same properties as Fortran stream I/O, and
RECORD I/O, which has many of the properties of Fortran
UNFORMATTED I/O.

(snip)

-- glen

[Richard Maine]

Louisa <louisa...@gmail.com> wrote:

> The term "list-directed formatting" is an inappropriate description.
> To say that such output (that follows little rhyme or reason) is
> "formatted" is ridiculous.

I will not debate with you whether or not it is ridiculous. That path
leads pretty directly to flame wars. Feel free to be of that opinion if
you like. It *IS* however the standard Fortran term for it. See, for
example, section10.9 List-directed formatting" in f2003.

> Real programmers understand that formatted output means explicit
> format control, using such items as I, F, E, A, etc.

Unless we are using the term "real programmers" in the sense of Ed
Post's well known parody (which the above claim sounds a *AWFUL* lot
like), real programmers pay some attention to the standard. Per the
Fortran standard, formatting is the process of converting internal
representations to character form. Explicit format control is just one
particular means of specifying the format details.

> > the standard does allow compilers a lot of
> > freedom in some details of list-directed output, but it isn't entirely
> > accurate to say that the compiler can do "anything it likes".

> Did I exaggerate? I don't think so.
>
> It does (do anything). And can (do anything).
> It can use any layout that it likes; it can print any number of digits
> that it likes.
> And it can give insufficient digits.
> And it doesn't even have to do that.
> It can even use the notation n*value where n is a repeat factor.
> There's no guarantee as to what rounding it uses.
> It can (and does) put in any number of superfluous blanks.
> Little if anything is consistent from compiler to compiler.
> Surely you have noticed this?

I refer you to the standard (specifically the above-mentioned section
10.9), which gives a specific list of the things that are allowed. That
list includes quite a lot of freedom. It does not include "anything" by
rather a long shot. For one trivial example, the compiler is not allowed
to output the integer value 1000000 as 1 000 000, or 1,000,000 (or, for
the Europeans, 1.000.000).

[Louisa]

On Oct 2, 2:18 am, nos...@see.signature (Richard Maine) wrote:

> Louisa <louisa.hu...@gmail.com> wrote:
> > The term "list-directed formatting" is an inappropriate description.
> > To say that such output (that follows little rhyme or reason) is
> > "formatted" is ridiculous.
>
> I will not debate with you whether or not it is ridiculous. That path
> leads pretty directly to flame wars. Feel free to be of that opinion if
> you like. It *IS* however the standard Fortran term for it. See, for
> example, section10.9 List-directed formatting" in f2003.

I know that it is. That's why I said it was a ridiculous term
for output that is not formatted.

Formatted output is output that is specified as to the columns
used and as to the number of digits etc.

List-directed "formatting" isn't.

> > Real programmers understand that formatted output means explicit
> > format control, using such items as I, F, E, A, etc.
>
> Unless we are using the term "real programmers" in the sense of Ed
> Post's well known parody (which the above claim sounds a *AWFUL* lot
> like), real programmers pay some attention to the standard.

Real programmers are practical programmers, experienced programmers.
They don't call a 'spade' a 'pick'.

> Per the
> Fortran standard, formatting is the process of converting internal
> representations to character form.

Formatted output is output where the layout is specified in detail,
as I described above.

> Explicit format control is just one
> particular means of specifying the format details.
>
> > > the standard does allow compilers a lot of
> > > freedom in some details of list-directed output, but it isn't entirely
> > > accurate to say that the compiler can do "anything it likes".
> > Did I exaggerate?  I don't think so.
>
> > It does (do anything).  And can (do anything).
> > It can use any layout that it likes; it can print any number of digits
> > that it likes.
> > And it can give insufficient digits.
> > And it doesn't even have to do that.
> > It can even use the notation   n*value   where n is a repeat factor.
> > There's no guarantee as to what rounding it uses.
> > It can (and does) put in any number of superfluous blanks.
> > Little if anything is consistent from compiler to compiler.
> > Surely you have noticed this?
>
> I refer you to the standard (specifically the above-mentioned section
> 10.9), which gives a specific list of the things that are allowed. That
> list includes quite a lot of freedom.

Freedon that renders the output not formatted.

> It does not include "anything"

I refer you to what I wrote.
"List-directed formatting" [sic] is at best decimal output
for numerc values. It is not formatted output.

> by
> rather a long shot. For one trivial example, the compiler is not allowed
> to output the integer value 1000000 as 1 000 000, or 1,000,000 (or, for
> the Europeans, 1.000.000).

That's irrelevant.

[glen herrmannsfeldt]

Louisa <louisa...@gmail.com> wrote:
(snip on unformatted)

>> you like. It *IS* however the standard Fortran term for it. See, for
>> example, section10.9 List-directed formatting" in f2003.

> I know that it is. That's why I said it was a ridiculous term
> for output that is not formatted.

In most cases it is formatted, with a G format of the appropriate
width and digits after the decimal point. The format is chosen
by the library writers, not you, but it is there.

The Fortran 66 compilers for some of the DEC systems, before
list-directed, allowed for commas in the input to terminate an
input field. That resulted in something similar to list directed,
but you still needed a FORMAT statement.

(As far as I know, the term list-directed came from PL/I. The term
for input with a format string is edit-directed. The form similar
to namelist is data-directed. Those correspond to the keyword used
in the I/O statements.)

> Formatted output is output that is specified as to the columns
> used and as to the number of digits etc.

> List-directed "formatting" isn't.

If you don't like list directed, then you can write with a FORMAT
something like (6(G12.8,1X)/) since all data types can be written
with G format. (Well, not so convenient for character data.)

Otherwise, consider it the grab-bag FORMAT. You get the luck
of the draw, which may or may not be what you wanted.
(I am not sure if it is allowed to use different widths as you might
get with a true grab-bag.)

-- glen

[Louisa]

On Oct 4, 11:58 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Louisa <louisa.hu...@gmail.com> wrote:
>
> (snip on unformatted)
>
> >> you like. It *IS* however the standard Fortran term for it. See, for
> >> example, section10.9 List-directed formatting" in f2003.
> > I know that it is.  That's why I said it was a ridiculous term
> > for output that is not formatted.
>
> In most cases it is formatted,

What I said was that it isn't formatted;
and it isn't.

> with a G format of the appropriate
> width and digits after the decimal point.  The format is chosen
> by the library writers, not you, but it is there.
>
> The Fortran 66 compilers for some of the DEC systems, before
> list-directed, allowed for commas in the input to terminate an
> input field.  That resulted in something similar to list directed,
> but you still needed a FORMAT statement.  
>
> (As far as I know, the term list-directed came from PL/I.  The term
> for input with a format string is edit-directed.  The form similar
> to namelist is data-directed.  Those correspond to the keyword used
> in the I/O statements.)
>
> > Formatted output is output that is specified as to the columns
> > used and as to the number of digits etc.
> > List-directed "formatting" isn't.
>
> If you don't like list directed, then you can write with a FORMAT
> something like (6(G12.8,1X)/) since all data types can be written
> with G format.  (Well, not so convenient for character data.)

I didn't say I didn't like it.
I said that it was inappropriate to call it "list-directed formatting"
when it clearly isn't (formatted).

[dpb]

On 10/4/2011 3:18 AM, Louisa wrote:
> On Oct 4, 11:58 am, glen herrmannsfeldt<g...@ugcs.caltech.edu> wrote:
>> Louisa<louisa.hu...@gmail.com> wrote:
>>
>> (snip on unformatted)
>>
>>>> you like. It *IS* however the standard Fortran term for it. See, for
>>>> example, section10.9 List-directed formatting" in f2003.
>>> I know that it is. That's why I said it was a ridiculous term
>>> for output that is not formatted.
>>
>> In most cases it is formatted,
>
> What I said was that it isn't formatted;
> and it isn't.

...

NONSENSE. If for no other reason it is because the Standard says it is.

Actually it is because if it weren't it wouldn't be on the
page/monitor/wherever in a recognizable form because it would still be
unformatted.

The choice of format isn't material to whether is or isn't.

Suck it up and accept that in Fortran the Standard uses the term as
defined and to try to refer to it in any other way is at best confusing.
In reality to do so is simply wrong.

<this is enough to finally go... <plonk>

--