Force leading zero for minimal field width format

[Beliavsky]

The code

write (*,"(2(f0.2,','))") 1.23,0.23

gives output

1.23,.23,

I wish there were a version of the minimal field width format that forces a leading zero before the decimal point, so that the output would be

1.23,0.23,

I think 0.23 is easier to read than .23.

[Gary Scott]

Yes, I run across this and your prior example frequently when processing
Excel files and wanting to match existing processing when I stuff data
back to Excel.

[Gary Scott]

well, more an issue when translating to/from other file formats and
wanting to restore the final form at the end.

[herrman...@gmail.com]

C printf has an option for zero padding, most often used
for integer formats, but I believe it works for floating
formats, too. It all zeros before the MSD, though, not
just one.

But you are asking about list directed output.
How does F format usually do it?

[Gary Scott]

Omits the leading 0 as in ".23".

[dom...@lps.ens.fr]

write (*,"(2(g0.2,','))") 1.23,0.23
write (*,"(2(f5.2,','))") 1.23,0.23
end

gives

1.23,.23,
1.2,0.23,
1.23, 0.23,

(gfortran)

[Steve Lionel]

The leading zero is optional. Some implementations supply it, some do
not. There is not a standard way of choosing the behavior. The standard
says (10.7.2.3.2p9):

"Leading zeros are not permitted except for an optional zero immediately
to the left of the decimal symbol if the magnitude of the value in the
output field is less than one. The optional zero shall appear if there
would otherwise be no digits in the output field."
--
Steve Lionel
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran

[dpb]

On 22-Oct-17 10:05 AM, Steve Lionel wrote:
> On 10/22/2017 9:35 AM, Gary Scott wrote:
>> On 10/22/2017 2:59 AM, herrman...@gmail.com wrote:
>>> But you are asking about list directed output.
>>> How does F format usually do it?
>>>
>> Omits the leading 0 as in ".23".
>
> The leading zero is optional. Some implementations supply it, some do

> not. There is not a standard way of choosing the behavior. ...

...[snip quote of same solely for brevity]...

Seems like a useful vendor extension albeit like all has the
ramification of differing behavior depending upon vendor.

I suppose it came from the "olden days" when saving the extra column on
punched-card output was deemed more important than visual aesthetics and
never reached the level of concern to be addressed in Standard.

--

[herrman...@gmail.com]

On Sunday, October 22, 2017 at 9:35:55 AM UTC-7, dpb wrote:
> On 22-Oct-17 10:05 AM, Steve Lionel wrote:

(snip)

> > The leading zero is optional. Some implementations supply it, some do
> > not. There is not a standard way of choosing the behavior. ...

> ...[snip quote of same solely for brevity]...

> Seems like a useful vendor extension albeit like all has the
> ramification of differing behavior depending upon vendor.

> I suppose it came from the "olden days" when saving the extra column on
> punched-card output was deemed more important than visual aesthetics and
> never reached the level of concern to be addressed in Standard.

With fixed output formats, their is either a column for the
ones digit, or their isn't. I believe if there isn't, for
example F5.4, it won't print one, and won't consider that the
value doesn't fit (and print asterisks).

If there is a column, such as F10.4, it takes the same amount
output space, which could be on a printer or cards.

It does save ink on the printer, or wear on the punch, but
that isn't usually a consideration.

Seems to me, just one of those historical accidents.

[jfh]

Steve has told us the sad state of the Fortran standard on leading zeros. What I did about it was to write a character function to simulate f0.n output format with options to let the user decide whether to get leading zero when there would otherwise be no digits before the decimal point, and also whether to get +
as the first character for a positive number. Two versions (for systems with and
without IEEE NaN and Inf) are in
http://homepages.ecs.vuw.ac.nz/~harper/fortranstuff.shtml
under the heading
. . Fortran 95/2003 module with test programs to simulate F0.n format with various options. If you don't like mine, write your own.

[Dan Nagle]

Hi,

On 2017-10-24 01:25:50 +0000, jfh said:
>
> Steve has told us the sad state of the Fortran standard on leading
> zeros. What I did about it was to write a character function to
> simulate f0.n output format with options to let the user decide whether
> to get leading zero when there would otherwise be no digits before the
> decimal point, and also whether to get +
> as the first character for a positive number. Two versions (for systems
> with and
> without IEEE NaN and Inf) are

> inhttp://homepages.ecs.vuw.ac.nz/~harper/fortranstuff.shtml

> under the heading
> . . Fortran 95/2003 module with test programs to simulate F0.n format
> with various options. If you don't like mine, write your own.

Can you post this observation to Steve's new feature list?

Use-cases you encountered with your software are valuable input
to the standards committees.

I tried to make an LZ edit descriptor modeled on the SS/SP descriptors,
but there was too little support for it to go anywhere.

--
Cheers!

Dan Nagle

[herrman...@gmail.com]

On Thursday, October 26, 2017 at 7:22:17 AM UTC-7, Dan Nagle wrote:

(snip)

> I tried to make an LZ edit descriptor modeled on the
> SS/SP descriptors, but there was too little support
> for it to go anywhere.

In another thread, I mentioned the PL/I P (picture)
format descriptor.

PL/I has a Picture data type, I believe inherited from
COBOL. But it also has the format descriptor, which
allows picture specification for other data types.

Among others, it allows one to specify the leading
zeros one wants. Not just zero or one, but more if
one wants them. Also, one can have commas, conditional
on there being digits to the left of some column.

One could add or subtract features in adapting it, but
it does seem a more general solution to some output
formatting problems, and probably not all that hard
to implement.

Some examples of the COBOL version are:

https://en.wikipedia.org/wiki/COBOL#PICTURE_clause

[robin....@gmail.com]

On Friday, October 27, 2017 at 2:53:38 AM UTC+11, herrman...@gmail.com wrote:
> On Thursday, October 26, 2017 at 7:22:17 AM UTC-7, Dan Nagle wrote:
>
> (snip)
>
> > I tried to make an LZ edit descriptor modeled on the
> > SS/SP descriptors, but there was too little support
> > for it to go anywhere.
>
> In another thread, I mentioned the PL/I P (picture)
> format descriptor.
>
> PL/I has a Picture data type,

I already mention that.

> I believe inherited from
> COBOL. But it also has the format descriptor, which
> allows picture specification for other data types.
>
> Among others, it allows one to specify the leading
> zeros one wants. Not just zero or one, but more if
> one wants them. Also, one can have commas, conditional
> on there being digits to the left of some column.

I already mentioned that.
I also metioned the drifting currency symbol, etc, and DR and DB.
There is also drifting sign, etc.

[campbel...@gmail.com]

My use of F0 or I0 is typically as 1X,F0.
I mostly want a leading space (for numeric results), although not always such as for string generation.

Minimal field length is a useful feature.

[FortranFan]

On Saturday, October 21, 2017 at 9:52:20 PM UTC-4, Beliavsky wrote:

> ..
>
> I wish there were a version of the minimal field width format that forces a leading zero before the decimal point ..


A thread at the Intel Fortran forum for Windows looking for the same:

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/753807

[Ron Shepard]

There are two related formats that I would like to see too, both
involving floating point numbers. One format would be to specify the
output field width, and the compiler would then figure out how to show
the largest number of significant digits within that fixed field width.
The other format would allow the user to specify the number of
significant digits to display, and the compiler would when figure out
the minimal field width required to show those digits. It turns out
that when you account for minus signs, the minimal exponent field width,
and the choice between f and e style output, these are rather
complicated to implement. Sometimes, there are even multiple solutions,
which would need to be resolved in some well-defined way in order to
allow outputs from different compilers to be compared easily. Another
useful option would be to force the + sign to be displayed for positive
values, which has the effect of making outputs symmetric for positive
and negative values.

$.02 -Ron Shepard

[urba...@comcast.net]

Additional control would be nice, especially since I was always told constants without a leading zero or a trailing zero in coding real numbers was bad practice -- ie .1 ==> 0.1, 1. ==> 1.0. But for forcing a plus sign on output why is the SP edit descriptor not sufficient? (or "SIGN='PLUS'" on the OPEN(3f) if using list directed formatting?
a=12.3456
i=789
open(unit=6,sign='suppress')
write(*,'(sp,g0,1x,sp,i0)') a,i
write(*,*)'FIRST WITH SUPPRESSED MODE'
do j=1,2
write(*,*) a,i
write(*,'(g0,1x,i0)') a,i
open(unit=6,sign='plus')
write(*,*)'AGAIN WITH PLUS MODE'
enddo
end

+12.3456001 +789
FIRST WITH SUPPRESSED MODE
12.3456001 789
12.3456001 789
AGAIN WITH PLUS MODE
+12.3456001 789
+12.3456001 +789
AGAIN WITH PLUS MODE

[FortranFan]

On Friday, December 22, 2017 at 4:24:52 PM UTC-5, Ron Shepard wrote:

> .. One format would be to specify the output field width, and the compiler

> would then figure out how to show the largest number of significant digits
> within that fixed field width. The other format would allow the user to
> specify the number of significant digits to display, and the compiler would

> when figure out the minimal field width required to show those digits ..


Is this not achieved with the G0 edit descriptor introduced in the Fortran 2008 standard?

--- begin example code ---
integer, parameter :: WP = selected_real_kind( p=15, r=300 )

! https://physics.nist.gov/cuu/Constants/
real(WP), parameter :: Avogadro_Constant = 6.022140857E23_wp ! 1/mol
real(WP), parameter :: Planck_Constant = 6.626070040E-34_wp ! J*s

print "(g0,1pg0.10)", "Avogardo Constant (1/mol) with 1pg0.10 format: ", Avogadro_Constant
print "(*(g0))", "Avogardo Number (1/mol) with g0 format: ", Avogadro_Constant

print "(g0,1pg0.8)", "Planck Constant (J*s) with 1pg0.8 format: ", Planck_Constant
print "(g0,1pg0)", "Planck Constant (J*s) with 1pg0 format: ", Planck_Constant

end
--- end code ---

Upon execution,

Avogardo Constant (1/mol) with 1pg0.10 format: 6.0221408570E+023
Avogardo Number (1/mol) with g0 format: 0.60221408570000002E+024
Planck Constant (J*s) with 1pg0.8 format: 6.62607004E-034
Planck Constant (J*s) with 1pg0 format: 6.6260700399999999E-034

[Ron Shepard]

On 12/22/17 7:23 PM, FortranFan wrote:
> On Friday, December 22, 2017 at 4:24:52 PM UTC-5, Ron Shepard wrote:
>
>> .. One format would be to specify the output field width, and the compiler
>> would then figure out how to show the largest number of significant digits
>> within that fixed field width. The other format would allow the user to
>> specify the number of significant digits to display, and the compiler would
>> when figure out the minimal field width required to show those digits ..
>
>
> Is this not achieved with the G0 edit descriptor introduced in the Fortran 2008 standard?
>
> --- begin example code ---
> integer, parameter :: WP = selected_real_kind( p=15, r=300 )
>
> ! https://physics.nist.gov/cuu/Constants/
> real(WP), parameter :: Avogadro_Constant = 6.022140857E23_wp ! 1/mol
> real(WP), parameter :: Planck_Constant = 6.626070040E-34_wp ! J*s
>
> print "(g0,1pg0.10)", "Avogardo Constant (1/mol) with 1pg0.10 format: ", Avogadro_Constant
> print "(*(g0))", "Avogardo Number (1/mol) with g0 format: ", Avogadro_Constant
>
> print "(g0,1pg0.8)", "Planck Constant (J*s) with 1pg0.8 format: ", Planck_Constant
> print "(g0,1pg0)", "Planck Constant (J*s) with 1pg0 format: ", Planck_Constant
>
> end
> --- end code ---
>
> Upon execution,
>
> Avogardo Constant (1/mol) with 1pg0.10 format: 6.0221408570E+023

The + sign and the leading zero in the exponent waste two slots in the
output field. Also as far as minimum field width, the decimal could be
removed and the exponent adjusted accordingly to eliminate one more
output character.

> Avogardo Number (1/mol) with g0 format: 0.60221408570000002E+024

The leading zero and the exponent + sign and leading zero are three
wasted slots.

> Planck Constant (J*s) with 1pg0.8 format: 6.62607004E-034
> Planck Constant (J*s) with 1pg0 format: 6.6260700399999999E-034

In these two, the leading zero in the exponent is wasted.

The g format also does not do well when it switches to f style output.

Also, there is the requirement to specify the output field width, and
then have the compiler figure out how to squeeze in the largest number
of digits. There isn't really anything like that at all in the past or
current language. That seems like it would be a fairly common task when
aligning columns in a table.

I did not mention this possibility before, but it might be useful to
have an option to output floating point numbers without the "e". This is
already done when the exponent value exceeds its output field width, and
that could be used also in these minimum field formats. For example, in
a field width of 14 characters, the compiler could output

60221408570+13

That has the same number of significant digits as the 1pg0.10 format
above which consumes 17 characters.

Dropping the "e" is another way to enforce symmetry between values with
positive and negative exponents. However, some lesser languages do not
support this floating point format, so it is not always useful when the
data is consumed by other programs.

Just as an aside, there are new values for Avogadro's number and
Planck's constant that is scheduled to take effect in 2018. They are
6.02214082e23 and 6.626069934e-34 respectively.

$.02 -Ron Shepard

[FortranFan]

On Saturday, December 23, 2017 at 3:58:20 AM UTC-5, Ron Shepard wrote:

> On 12/22/17 7:23 PM, FortranFan wrote:

> ..

> > Upon execution,
> >
> > Avogardo Constant (1/mol) with 1pg0.10 format: 6.0221408570E+023
>
> The + sign and the leading zero in the exponent waste two slots in the
> output field. Also as far as minimum field width, the decimal could be
> removed and the exponent adjusted accordingly to eliminate one more
> output character.
>
> > Avogardo Number (1/mol) with g0 format: 0.60221408570000002E+024
>
> The leading zero and the exponent + sign and leading zero are three
> wasted slots.
>

> ..

> The g format also does not do well when it switches to f style output.
>
> Also, there is the requirement to specify the output field width, and
> then have the compiler figure out how to squeeze in the largest number
> of digits. There isn't really anything like that at all in the past or
> current language. That seems like it would be a fairly common task when
> aligning columns in a table.
>
> I did not mention this possibility before, but it might be useful to
> have an option to output floating point numbers without the "e". This is
> already done when the exponent value exceeds its output field width, and

> that could be used also in these minimum field formats. ..


These comments probably explain the unspoken motto for most committees:

Give 'em an inch and they'll take a mile,
Give 'em a *foot* and they'll learn to avoid you!

[dpb]

On 12/22/2017 3:24 PM, Ron Shepard wrote:
...

> There are two related formats that I would like to see too, both
> involving floating point numbers. One format would be to specify the
> output field width, and the compiler would then figure out how to show
> the largest number of significant digits within that fixed field width.

...

The WAPD (Westinghouse Atomic Power Division) devised a consistent
input/output format for the nuclear design codes they were contracted to
write back in the 50s/60s for old AEC/US Navy initially for nuclear
submarine program that were adapted for widespread commercial nuclear
power design by all the vendors.

It uses a form of

012334+00

where the decimal is implied as leading but not output nor required on
input. An explicit decimal on input will override the assumed location.

We took this code out of one of those design codes and packaged it as a
set of routines before the days of libraries on the old Philco 2000 and
then the successor CDC machines and incorporated it into all our other
proprietary design codes. I don't have a copy of the source at hand on
the desktop; not sure if I can dig one up on readable medium or not if
were interested...

--

[robin....@gmail.com]

On Sunday, December 24, 2017 at 2:20:50 AM UTC+11, dpb wrote:
> On 12/22/2017 3:24 PM, Ron Shepard wrote:
> ...
>
> > There are two related formats that I would like to see too, both
> > involving floating point numbers. One format would be to specify the
> > output field width, and the compiler would then figure out how to show
> > the largest number of significant digits within that fixed field width.
> ...
>
> The WAPD (Westinghouse Atomic Power Division) devised a consistent
> input/output format for the nuclear design codes they were contracted to
> write back in the 50s/60s for old AEC/US Navy initially for nuclear
> submarine program that were adapted for widespread commercial nuclear
> power design by all the vendors.
>
> It uses a form of
>
> 012334+00
>
> where the decimal is implied as leading but not output nor required on
> input. An explicit decimal on input will override the assumed location.

That sort of thing was common in the 1950s.

For DEUCE [1955], the standard float format was sd.ddddddddsddddddddd
without the letter E and without the decimal point (shown here for clarity),
with mantissa first, exponent second.
The mantissa, m, was either zero, or in the range 1 <= m < 10.

Other formats did exist.

[Clive Page]

On 23/12/2017 01:23, FortranFan wrote:
> Is this not achieved with the G0 edit descriptor introduced in the Fortran 2008 standard?
>
> --- begin example code ---

> print "(g0,1pg0.8)", "Planck Constant (J*s) with 1pg0.8 format: ", Planck_Constant
> print "(g0,1pg0)", "Planck Constant (J*s) with 1pg0 format: ", Planck_Constant

Yes, that does indeed do what is required, at least for the G format.

But the it is perhaps not a good idea to encourage inexperienced programmers to use P format because it has unexpected effects on any subsequent F format like this:

real(wp), parameter :: pi = 3.141592653589_wp

print "(g0,1pg0.8,f20.10)", "Planck Constant (J*s) with 1pg0.8 format: ", Planck_Constant, pi
print "(g0,1pg0,f20.10)", "Planck Constant (J*s) with 1pg0 format: ", Planck_Constant, pi

Results:

Planck Constant (J*s) with 1pg0.8 format: 6.62607004E-034 31.4159265359
Planck Constant (J*s) with 1pg0 format: 6.6260700399999999E-034 31.4159265359

A big enough Pi to feed more people, I suppose.

--
Clive Page

[robin....@gmail.com]

Have you tried the ES format field descritor?

[Ron Shepard]

Of course I have used the ES format, and of course it does not satisfy
the requirements by itself either. For example, sometimes an F format
will show more significant figures than an ES format, such as when the
exponent is zero.

Although this seems like a simple requirement that should have lots of
demand in creating aligned tables or in interchanging data in formatted
form, there is nothing in the past or current fortran language
specifications that really satisfies these minimum field width and
maximum significant figure requirements.

$.02 -Ron Shepard

[robin....@gmail.com]

On Monday, December 25, 2017 at 3:09:42 PM UTC+11, Ron Shepard wrote:

My comment was directed to Fortran Fan.

> and of course it does not satisfy
> the requirements by itself either.

It does, for it eliminates the leading zero.

> For example, sometimes an F format
> will show more significant figures than an ES format,

An F-format? Has nothing to do with ES format.

The number of significant digits depends on the field width --
and that's chosen by the programmer.

> such as when the exponent is zero.

> Although this seems like a simple requirement that should have lots of
> demand in creating aligned tables

Aligned tables cannot, in general, be produced by a minimum field width
specification, as the number of significant digits before the decimal point
changes from nuber to number. The minimum field width is for producing text
interspersed with numbers.

> or in interchanging data in formatted
> form, there is nothing in the past or current fortran language
> specifications that really satisfies these minimum field width and
> maximum significant figure requirements.

I think that you have not investigated what can be done with
existing format field descriptors.

[Ron Shepard]

My mistake. In any case, the ES does not achieve the goals as I have
already demonstrated.

>> and of course it does not satisfy
>> the requirements by itself either.
>
> It does, for it eliminates the leading zero.

Not necessarily in the exponent, and it also does not eliminate the
unnecessary + sign in the exponent.

>
>> For example, sometimes an F format
>> will show more significant figures than an ES format,
>
> An F-format? Has nothing to do with ES format.

As I have explained several times in this thread already, the
descriptors that I am talking about would involve switching between F
and E formats in order to achieve their goals.

> The number of significant digits depends on the field width --
> and that's chosen by the programmer.

Yes, the number of significant digits displayed does depend on the field
width, but the current E, F, and G formats do not result in either the
maximum digits within a field width or in the minimum field width given
the specified number of significant digits.

>> such as when the exponent is zero.
>
>> Although this seems like a simple requirement that should have lots of
>> demand in creating aligned tables
>
> Aligned tables cannot, in general, be produced by a minimum field width
> specification,

No, but the other requirement does. Namely, given the specified field
width, find a format that results in the maximum number of significant
digits displayed. Of course the current formats can be used to produce
aligned tables, but those formats do not result in the maximum number of
digits displayed.

> as the number of significant digits before the decimal point
> changes from nuber to number. The minimum field width is for producing text
> interspersed with numbers.

That would be one use for it, and a nice one at that. Another would be
to minimize data transfer volume between different programs or processes
while strictly maintaining a specified relative precision. That was the
main goal when I have written my own formatting routines in the past.

>> or in interchanging data in formatted
>> form, there is nothing in the past or current fortran language
>> specifications that really satisfies these minimum field width and
>> maximum significant figure requirements.
>
> I think that you have not investigated what can be done with
> existing format field descriptors.

Then it should be easy to show how one of those existing format
descriptors satisfies either or both of the goals.

$.02 -Ron Shepard

[robin....@gmail.com]

On Tuesday, December 26, 2017 at 3:15:05 AM UTC+11, Ron Shepard wrote:

If leading zeros in the exponent are eliminated, then
the format is unultable for producing tables.

> and it also does not eliminate the
> unnecessary + sign in the exponent.

If the "+" sign is eliminated, the format is unsuitable for
producing tables.

> >> For example, sometimes an F format
> >> will show more significant figures than an ES format,
> >
> > An F-format? Has nothing to do with ES format.
>
> As I have explained several times in this thread already, the
> descriptors that I am talking about would involve switching between F
> and E formats in order to achieve their goals.

Then the output will be unsuitable for producing a table.

What you need is to write your own conversion.

> > The number of significant digits depends on the field width --
> > and that's chosen by the programmer.
>
> Yes, the number of significant digits displayed does depend on the field
> width, but the current E, F, and G formats do not result in either the
> maximum digits within a field width

They do, if you choose the approproate value for field width.

> or in the minimum field width given
> the specified number of significant digits.

Try the 0.n specification for the relevant format feld descriptor.

> >> such as when the exponent is zero.
> >
> >> Although this seems like a simple requirement that should have lots of
> >> demand in creating aligned tables
> >
> > Aligned tables cannot, in general, be produced by a minimum field width
> > specification,
>
> No, but the other requirement does. Namely, given the specified field
> width, find a format that results in the maximum number of significant
> digits displayed.

You can get that already by specifying the appropriate field width.

> Of course the current formats can be used to produce
> aligned tables, but those formats do not result in the maximum number of
> digits displayed.

They do if you choose the appropriate field width.

> > as the number of significant digits before the decimal point
> > changes from nuber to number. The minimum field width is for producing text
> > interspersed with numbers.
>
> That would be one use for it, and a nice one at that. Another would be
> to minimize data transfer volume between different programs or processes
> while strictly maintaining a specified relative precision. That was the
> main goal when I have written my own formatting routines in the past.
>
> >> or in interchanging data in formatted
> >> form, there is nothing in the past or current fortran language
> >> specifications that really satisfies these minimum field width and
> >> maximum significant figure requirements.
> >
> > I think that you have not investigated what can be done with
> > existing format field descriptors.
>
> Then it should be easy to show how one of those existing format
> descriptors satisfies either or both of the goals.

I already did.

[Ron Shepard]

On 12/25/17 6:34 PM, robin....@gmail.com wrote:
[...]

> If leading zeros in the exponent are eliminated, then
> the format is unultable for producing tables.

No, that would allow more significant digits to be written into the
specified width column fields. That would be the goal in this case, to
write the maximum number of significant digits into the fixed width
output field.

>> As I have explained several times in this thread already, the
>> descriptors that I am talking about would involve switching between F
>> and E formats in order to achieve their goals.
>
> Then the output will be unsuitable for producing a table.

Yes, a table with fixed column width fields can be written with the
appropriate mixtures of f and e descriptors. I would also want
unnecessary leading zeros to be eliminated from exponent fields, and at
least the option to eliminate any leading + signs.

> What you need is to write your own conversion.

I have already done this in specific situations. What I'm suggesting is
that this would be a popular output option if it were incorporated into
the language standard as standard field descriptors for everyone to use.


[...]>> Yes, the number of significant digits displayed does depend on

the field
>> width, but the current E, F, and G formats do not result in either the
>> maximum digits within a field width
>
> They do, if you choose the approproate value for field width.

Well, duh.

>> or in the minimum field width given
>> the specified number of significant digits.
>
> Try the 0.n specification for the relevant format feld descriptor.

Have you read any of the previous posts in this thread? I have already
shown examples of how this is inadequate for the two tasks with the
current field descriptors. Currently to achieve this goal, you could
determine the output field descriptor at runtime, write the data into a
character variable, and write out that character variable. I am
proposing that this effort be collapsed into a new pair of field
descriptors and made available as the current e, f, and g descriptors
are available.

[...]

>> No, but the other requirement does. Namely, given the specified field
>> width, find a format that results in the maximum number of significant
>> digits displayed.
>
> You can get that already by specifying the appropriate field width.

Well, duh, again. What I am proposing is that the compiler does that
work instead of the programmer. It is not a trivial task, and it needs
to be done in a robust way.

>> Of course the current formats can be used to produce
>> aligned tables, but those formats do not result in the maximum number of
>> digits displayed.
>
> They do if you choose the appropriate field width.

Well, duh, yet again.

>>> I think that you have not investigated what can be done with
>>> existing format field descriptors.
>>
>> Then it should be easy to show how one of those existing format
>> descriptors satisfies either or both of the goals.
>
> I already did.

Still waiting on this one. If you think this already exists, then show
me examples of a field descriptors that satisfy each of the two types of
output requirements.

$.02 -Ron Shepard

[robin....@gmail.com]

On Tuesday, December 26, 2017 at 1:28:48 PM UTC+11, Ron Shepard wrote:

> On 12/25/17 6:34 PM, r.....@gmail.com wrote:
> [...]
> > If leading zeros in the exponent are eliminated, then

> > the format is unsuitable for producing tables.
>
> No,

Well, it's unsuitable because the values in a table do not line up.

> that would allow more significant digits to be written into the
> specified width column fields.

It you ask for the required number of significant digits via the format,
then you don't get more significant digits.

> That would be the goal in this case, to
> write the maximum number of significant digits into the fixed width
> output field.

The digits don't line up for tabular output, do they!

> >> As I have explained several times in this thread already, the
> >> descriptors that I am talking about would involve switching between F
> >> and E formats in order to achieve their goals.
> >
> > Then the output will be unsuitable for producing a table.
>
> Yes, a table with fixed column width fields can be written with the
> appropriate mixtures of f and e descriptors. I would also want
> unnecessary leading zeros to be eliminated from exponent fields, and at
> least the option to eliminate any leading + signs.

Then the values in the table do not line up.

> > What you need is to write your own conversion.
>
> I have already done this in specific situations.

Good.

> What I'm suggesting is
> that this would be a popular output option

It isn't. Values would not line up in a table.

> if it were incorporated into
> the language standard as standard field descriptors for everyone to use.

> [...]>> Yes, the number of significant digits displayed does depend on
> the field
> >> width, but the current E, F, and G formats do not result in either the
> >> maximum digits within a field width
> >
> > They do, if you choose the approproate value for field width.
>
> Well, duh.
>
> >> or in the minimum field width given
> >> the specified number of significant digits.
> >
> > Try the 0.n specification for the relevant format feld descriptor.
>
> Have you read any of the previous posts in this thread? I have already
> shown examples of how this is inadequate for the two tasks with the
> current field descriptors. Currently to achieve this goal, you could
> determine the output field descriptor at runtime, write the data into a
> character variable, and write out that character variable. I am
> proposing that this effort be collapsed into a new pair of field
> descriptors and made available as the current e, f, and g descriptors
> are available.

Why is it that people want the compiler to do everything they want?
Fortran has the facilities to do what you want.
It's trivial.

> [...]
> >> No, but the other requirement does. Namely, given the specified field
> >> width, find a format that results in the maximum number of significant
> >> digits displayed.
> >
> > You can get that already by specifying the appropriate field width.
>
> Well, duh, again. What I am proposing is that the compiler does that
> work instead of the programmer. It is not a trivial task, and it needs
> to be done in a robust way.

It's a trivial task.

> >> Of course the current formats can be used to produce
> >> aligned tables, but those formats do not result in the maximum number of
> >> digits displayed.
> >
> > They do if you choose the appropriate field width.
>
> Well, duh, yet again.

> >>> I think that you have not investigated what can be done with
> >>> existing format field descriptors.
> >>
> >> Then it should be easy to show how one of those existing format
> >> descriptors satisfies either or both of the goals.
> >
> > I already did.
>
> Still waiting on this one.

I already told you.

> If you think this already exists, then show
> me examples of a field descriptors that satisfy each of the two types of
> output requirements.

The facilities that you want are trivial to write.

[Dick Hendrickson]

I don't they are trivial to write for what he wants (this thread is a
tad long and the original request might have been lost). What I think
Ron wants is the ability to write out an N column wide field that has no
unnecessary characters; extra significant digits are provided instead.
You can't do this with any of the E outputs. The exponent field is
required to be of the form ESXY, where S is a plus or minus sign and X
and Y are single integer digits. It's the S and X he'd like to suppress
and get one or two more mantissa digits. As far as I know, none of the
edit descriptors allow that.

Ron wants all of the output fields to be, say, 12 columns wide; thus
everything will be vertically aligned, but the decimal point, number of
mantissa digits, and E field will vary from line to line depending on
whether or not the exponent absolute value is < 12, between 12 and 99,
and greater than 99.

Whether or not this is important enough to add is a judgment call. But,
it's not trivial with current Fortran in a robust way. The compiler
writer only has to get it right once.

Dick Hendrickson

[FortranFan]

On Monday, December 25, 2017 at 9:28:48 PM UTC-5, Ron Shepard wrote:

> .. That would be the goal in this case, to

> write the maximum number of significant digits into the fixed width

> output field. ..


@Ron Shepard,

You should submit a formal proposal to the Fortran standard committee with the points you have made in this thread with use cases and suggestions on how the language can incorporate what you're seeking.

It'll be rather interesting to see the committee's response for your comments come across as "asking for a mile" whereas the original post is more like "give an inch" i.e., if it is anything other than give you both the "foot"!!

[robin....@gmail.com]

On Wednesday, December 27, 2017 at 4:50:51 AM UTC+11, Dick Hendrickson wrote:

The outputs will not be vertically aligned if the sign and significant
digits of the exponent are omitted, and the position of the decimal point
can change, and the sign of the mantissa can be omitted.

> Whether or not this is important enough to add is a judgment call. But,
> it's not trivial with current Fortran in a robust way.

I do not agree. It is trivial.