Home > Archive > Fortran > January 2006 > Is there a Fortran feature to do this?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Is there a Fortran feature to do this?
|
|
| Colin Watters 2006-01-22, 9:59 pm |
| I often need to write data and results to formatted text files. I would like
a standard way to format a real number into a fixed number of columns, that
would provide the maximum possible precision, and deal correctly with values
of any legal magnitude.
For example a quantity such as 1.23456789, in a 6-column field, would appear
as '1.2346'. And 1.23456789e+5 would (could?) appear as '123457'. And
1.23456789e+7 might appear as as 1.23e7, but better as 1234e4.
More interesting examples can be found in negative numbers, or/and with
negative exponents.
Currently I do this sort of formatting with a collection of routines and
character functions that vary in age up to 20 years. Efficient ... they are
not.
So ... Has Fortran 90, 95 or 2003 got anything new to offer in this regard,
that I have so far managed to avoid discovering? And failing that, can
anyone offer a suitable algorithm?
--
Qolin
Email: my qname at domain
Domain: qomputing dot demon dot co dot uk
| |
| Dan Nagle 2006-01-22, 9:59 pm |
| Hello,
I'm not certain exactly what you want,
but have you examined Gw.d format in conjunction
with the rounding modes?
Colin Watters wrote:
> I often need to write data and results to formatted text files. I would like
> a standard way to format a real number into a fixed number of columns, that
> would provide the maximum possible precision, and deal correctly with values
> of any legal magnitude.
>
> For example a quantity such as 1.23456789, in a 6-column field, would appear
> as '1.2346'. And 1.23456789e+5 would (could?) appear as '123457'. And
> 1.23456789e+7 might appear as as 1.23e7, but better as 1234e4.
>
> More interesting examples can be found in negative numbers, or/and with
> negative exponents.
>
> Currently I do this sort of formatting with a collection of routines and
> character functions that vary in age up to 20 years. Efficient ... they are
> not.
>
> So ... Has Fortran 90, 95 or 2003 got anything new to offer in this regard,
> that I have so far managed to avoid discovering? And failing that, can
> anyone offer a suitable algorithm?
>
> --
> Qolin
>
> Email: my qname at domain
> Domain: qomputing dot demon dot co dot uk
>
>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
| |
| Colin Watters 2006-01-22, 9:59 pm |
| I confess, not recently.
My previous experiments with G format (over 10 years ago) led me to conclude
that it has an 'overhead' of 7 columns, thus it required at least 8 columns
to obtain just one significant digit. (Now that may have been the particular
compilers I was using, and it was certainly FORTRAN-77, so maybe things have
changed.)
For example, with G12.5, the quantity -1.23456789e-22 would appear as
'-0.12346E-21'; more precision could be preserved in the available 12 colums
if instead the output were to appear like this: '-.123457e-21', or:
'-.1234568-21', or: '-12345679-29', ... admitedly at the expense of
readability. Can this be done with a G format?
With the same G12.5 format, the quantity 1.23456789 would appear as ' 1.2346
'... 6 columns going to waste holding nothing but blanks.
If I have 8 colums to hold the output instead of 12, a G8.6 will often
result in an output field filled with asterisks. A G8.2 gives only 2
significant figures. I am forced to create a procedure that examines the
magnitude and sign of the quantity, and chooses a sensable format for the
available number of columns.
Is there any better way these days?
--
Qolin
Email: my qname at domain
Domain: qomputing dot demon dot co dot uk
"Dan Nagle" <dannagle@verizon.net> wrote in message
news:QjTAf.7967$Fb3.3901@trnddc08...
> Hello,
>
> I'm not certain exactly what you want,
> but have you examined Gw.d format in conjunction
> with the rounding modes?
>
> Colin Watters wrote:
like[color=darkred]
that[color=darkred]
values[color=darkred]
appear[color=darkred]
are[color=darkred]
regard,[color=darkred]
>
>
> --
> Cheers!
>
> Dan Nagle
> Purple Sage Computing Solutions, Inc.
| |
| Ken Plotkin 2006-01-22, 9:59 pm |
| On Mon, 23 Jan 2006 23:06:23 -0000, "Colin Watters"
<qolin.see_signature@nowhere.co.uk> wrote:
[snip]
>For example, with G12.5, the quantity -1.23456789e-22 would appear as
>'-0.12346E-21'; more precision could be preserved in the available 12 colums
>if instead the output were to appear like this: '-.123457e-21', or:
>'-.1234568-21', or: '-12345679-29', ... admitedly at the expense of
>readability. Can this be done with a G format?
[snip]
What's wrong with e16.9? Ot e17.9 if you want a leading space in
front of negative numbers?
If you really want to save one or two spaces by eliminating the E or
the . , you can write to a string, then read the numeric parts (easy,
since the format is fixed), then juwt write whatever parts you want.
Ken Plotkin
| |
| Louis Krupp 2006-01-22, 9:59 pm |
| Colin Watters wrote:
> I often need to write data and results to formatted text files. I would like
> a standard way to format a real number into a fixed number of columns, that
> would provide the maximum possible precision, and deal correctly with values
> of any legal magnitude.
>
> For example a quantity such as 1.23456789, in a 6-column field, would appear
> as '1.2346'. And 1.23456789e+5 would (could?) appear as '123457'. And
> 1.23456789e+7 might appear as as 1.23e7, but better as 1234e4.
>
> More interesting examples can be found in negative numbers, or/and with
> negative exponents.
>
> Currently I do this sort of formatting with a collection of routines and
> character functions that vary in age up to 20 years. Efficient ... they are
> not.
>
> So ... Has Fortran 90, 95 or 2003 got anything new to offer in this regard,
> that I have so far managed to avoid discovering? And failing that, can
> anyone offer a suitable algorithm?
If you want optimal packing, you could pick a floating point format with
a hidden bit (such as IEEE 754), make it a multiple of 24 bits, and
encode it in base 64. If your files are *always* written and read on
systems that use IEEE 754 (and most do these days), you might be able to
get away with rounding the 32-bit single-precision IEEE word to 24 bits,
which would be base-64 encoded into four bytes. The rounding process is
probably a subject in itself, and one about which others will know more.
Louis
| |
| Ron Shepard 2006-01-23, 3:58 am |
| In article <dr0uph$q4g$1$830fa795@news.demon.co.uk>,
"Colin Watters" <qolin.see_signature@nowhere.co.uk> wrote:
> I often need to write data and results to formatted text files. I would like
> a standard way to format a real number into a fixed number of columns, that
> would provide the maximum possible precision, and deal correctly with values
> of any legal magnitude.
This is something I've wanted for the past 25 years or so too. It
seems to me like it would be a common need, and if it were
available, then there would be lots of uses for it. There is
nothing like this in f77, f90, or f95. I don't think this was
included in f2003, but I'm not absolutely certain. IMO, this is
what the g format in f77 should have been, but now that the g format
has been defined the way it has, some other format descriptor would
be needed to be added for this functionality.
$.02 -Ron Shepard
| |
| David Flower 2006-01-23, 3:58 am |
|
Colin Watters wrote:
> I often need to write data and results to formatted text files. I would like
> a standard way to format a real number into a fixed number of columns, that
> would provide the maximum possible precision, and deal correctly with values
> of any legal magnitude.
>
> For example a quantity such as 1.23456789, in a 6-column field, would appear
> as '1.2346'. And 1.23456789e+5 would (could?) appear as '123457'. And
> 1.23456789e+7 might appear as as 1.23e7, but better as 1234e4.
>
> More interesting examples can be found in negative numbers, or/and with
> negative exponents.
>
> Currently I do this sort of formatting with a collection of routines and
> character functions that vary in age up to 20 years. Efficient ... they are
> not.
>
> So ... Has Fortran 90, 95 or 2003 got anything new to offer in this regard,
> that I have so far managed to avoid discovering? And failing that, can
> anyone offer a suitable algorithm?
>
> --
> Qolin
>
> Email: my qname at domain
> Domain: qomputing dot demon dot co dot uk
As this is inherently involved with I/O,it is likely that efficiency is
of minor importance.
A similar problem is the determination of the shortest format
appropriate for all members of an array.
Dave Flower
| |
| Colin Watters 2006-01-23, 7:04 pm |
| "Ken Plotkin" <kplotkin@nospam-cox.net> wrote in message
news:1kg8t19t22fjpaqpe07ih8allhaupbgnqs@
4ax.com...
> What's wrong with e16.9? Ot e17.9 if you want a leading space in
> front of negative numbers?
.... In most of the important parts of the text files I am writing, I can't
really afford more than 8 columns for each value. Then one of these gets
used for a decimal point, another for a leading negative, and pretty soon an
exponent will leave me with just 3 significant figures, or even less.
> If you really want to save one or two spaces by eliminating the E or
> the . , you can write to a string, then read the numeric parts (easy,
> since the format is fixed), then juwt write whatever parts you want.
....yes I have considered doing this. For sure, it can't be less efficient
than my current method.
--
Qolin
Email: my qname at domain
Domain: qomputing dot demon dot co dot uk
| |
| Colin Watters 2006-01-23, 7:04 pm |
|
"Louis Krupp" <lkrupp@pssw.nospam.com.invalid> wrote in message
news:11t8k0a5m220d96@corp.supernews.com...
> Colin Watters wrote:
like[color=darkred]
that[color=darkred]
values[color=darkred]
appear[color=darkred]
are[color=darkred]
regard,[color=darkred]
>
> If you want optimal packing, you could pick a floating point format with
> a hidden bit (such as IEEE 754), make it a multiple of 24 bits, and
> encode it in base 64. If your files are *always* written and read on
> systems that use IEEE 754 (and most do these days), you might be able to
> get away with rounding the 32-bit single-precision IEEE word to 24 bits,
> which would be base-64 encoded into four bytes. The rounding process is
> probably a subject in itself, and one about which others will know more.
>
> Louis
....um, the idea is to write a text file, by which I mean a file readable by
a human, an engineer, not a programmer. But thanks anyway.
--
Qolin
Email: my qname at domain
Domain: qomputing dot demon dot co dot uk
| |
| glen herrmannsfeldt 2006-01-24, 7:56 am |
| Colin Watters wrote:
> My previous experiments with G format (over 10 years ago) led me to conclude
> that it has an 'overhead' of 7 columns, thus it required at least 8 columns
> to obtain just one significant digit. (Now that may have been the particular
> compilers I was using, and it was certainly FORTRAN-77, so maybe things have
> changed.)
> For example, with G12.5, the quantity -1.23456789e-22 would appear as
> '-0.12346E-21'; more precision could be preserved in the available 12 colums
> if instead the output were to appear like this: '-.123457e-21', or:
> '-.1234568-21', or: '-12345679-29', ... admitedly at the expense of
> readability. Can this be done with a G format?
1PG12.5, I believe since Fortran 66, should get you -1.23456E-21
be sure to cancel the 1P (with 0p) before any F format items.
That is one digit more than you get without the P, but increasing
P doesn't get any more than that. So six column overhead with 1P,
seven with 0P.
Fortran has traditionally allowed either two digit exponents
with E or D, or three digit exponents without. I don't know
what Cray did with four digit exponents.
> With the same G12.5 format, the quantity 1.23456789 would appear as ' 1.2346
> '... 6 columns going to waste holding nothing but blanks.
Generally (yes, a generalization) floating point is used for values
with relative error, and so the same number of digits are available
independent of value.
> If I have 8 colums to hold the output instead of 12, a G8.6 will often
> result in an output field filled with asterisks. A G8.2 gives only 2
> significant figures. I am forced to create a procedure that examines the
> magnitude and sign of the quantity, and chooses a sensable format for the
> available number of columns.
> Is there any better way these days?
1P is one digit better, I don't know why it isn't default, except
for tradition. 1PG8.2 will give three significant digits (though
numbers with the first digit close to one really have only about
two digits, anyway). Still, one more than 0P, up to 100%
improvement!
(snip)
-- glen
|
|
|
|
|