How to convert characters to number

fortran, How to convert characters to number Hi,

If I have a character variable A and real*4 variable B, how can I assign
the value in A to B?

I know this works: read(A,'(f15.6)') B when a='57.1234' or a='57.0' but not
when a='57'.

Is there a smarter way to convert? I am using visual fortran 6.6.

Thanks,

Haifang Li

fortran >> How to convert characters to number "Haifang Li" <haifang.li@stonybrook.edu> writes:

> If I have a character variable A and real*4 variable B, how can I assign
> the value in A to B?
>
> I know this works: read(A,'(f15.6)') B when a='57.1234' or a='57.0' but not
> when a='57'.
>
> Is there a smarter way to convert? I am using visual fortran 6.6.

Your problem is just in understanding the F edit descriptor. Do you
know what the .6 part of f15.6 means on input? Why do you have a .6
there? It specifies where to put an implied decimal point if there
isn't an explicit one. Mostly, I consider the business about implied
decimal points to be archaic. One should generally make decimal
points explicit, except when you have whole numbers, that is the
implied decimal point is on the right.

With f15.6, you tell the compiler to interpret 57 with an implied
decimal point of 0.000057, which I assume is the result you get.

Just use f15.0 instead of f15.6. Then if you don't have a decimal
point, the implied one is at the right, just like humans would
normally assume. If you ever have a decimal point anywhere other
that the right, then make it explicit. Don't *EVER* write code
that anticipates users will enter 5.7 as 57 just to save typing
the decimal point.

An alternative is to just use

read(A,*) B

As of f90, list-directed internal I/O is standard (and CVF supports
f90).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

fortran >> How to convert characters to number Richard Maine wrote:

(snip)

>>I know this works: read(A,'(f15.6)') B when a='57.1234' or a='57.0' but not
>>when a='57'.
(snip)

> Your problem is just in understanding the F edit descriptor. Do you
> know what the .6 part of f15.6 means on input? Why do you have a .6
> there? It specifies where to put an implied decimal point if there
> isn't an explicit one. Mostly, I consider the business about implied
> decimal points to be archaic. One should generally make decimal
> points explicit, except when you have whole numbers, that is the
> implied decimal point is on the right.

It made a lot of sense in the days of cards, though even then putting
in the decimal point was usually best.

> With f15.6, you tell the compiler to interpret 57 with an implied
> decimal point of 0.000057, which I assume is the result you get.

I would have guessed that the '57' would expand with blanks on the
right as '57 ' and the result would be 570000000.

If you put 57 in columns 1 and 2 of a card that is what it would do.

> Just use f15.0 instead of f15.6. Then if you don't have a decimal
> point, the implied one is at the right, just like humans would
> normally assume. If you ever have a decimal point anywhere other
> that the right, then make it explicit. Don't *EVER* write code
> that anticipates users will enter 5.7 as 57 just to save typing
> the decimal point.

If my guess above is right, then this won't work.

> An alternative is to just use

> read(A,*) B

> As of f90, list-directed internal I/O is standard
> (and CVF supports f90).

I thought it was in F77, but then again, I haven't checked lately.

-- glen

fortran >> How to convert characters to number glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Richard Maine wrote:
>
>> With f15.6, you tell the compiler to interpret 57 with an implied
>> decimal point of 0.000057, which I assume is the result you get.
>
> I would have guessed that the '57' would expand with blanks on the
> right as '57 ' and the result would be 570000000.
...
>> Just use f15.0 instead of f15.6....
> If my guess above is right, then this won't work.

I'll admit to cheating. :-(

Since I don't really think this good practice, I didn't spend a lot
of time carefully analyzing it. But I did a quick check with
NAG f95 and that's what it did. I just assumed they have it right.
But I didn't check. Maybe I'm wrong.

>> An alternative is to just use
>
>> read(A,*) B
>
>> As of f90, list-directed internal I/O is standard
> > (and CVF supports f90).
>
> I thought it was in F77, but then again, I haven't checked lately.

No. Definitely not. List-directed I/O was in f77. Internal I/O
was also in f77, but list-directed internal I/O was not. Several
compilers didn't support it (and some had pretty obscure symptoms
if you tried it). I think that most of the later vintage f77
compilers supported it, but earlier ones did not and it was not
standard.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

fortran >> How to convert characters to number Richard Maine wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>Richard Maine wrote:

>>>With f15.6, you tell the compiler to interpret 57 with an implied
>>>decimal point of 0.000057, which I assume is the result you get.

>>I would have guessed that the '57' would expand with blanks on the
>>right as '57 ' and the result would be 570000000.

(snip)

> I'll admit to cheating. :-(

> Since I don't really think this good practice, I didn't spend a lot
> of time carefully analyzing it. But I did a quick check with
> NAG f95 and that's what it did. I just assumed they have it right.
> But I didn't check. Maybe I'm wrong.

I seem to remember DEC compilers doing non-standard things
with terminal I/O. Especially before list directed input.

It might be that they did what people expected, instead of what
the standard expected. Formatted input, especially with
implied decimal points, is not convenient from a terminal.

What does your compiler do with 2F15.6 format, two variables,
and '57 12' for the input string?

I would say that it should be 570120000, as blanks are zeros.
Since it isn't wide enough to reach the second is 0.0.

I believe, though, that some of the DEC compilers would assign
57 to the first, and 12 to the second.

(alt.sys.pdp10 added, in case anyone there knows about that.)

(snip regarding list directed internal I/O, especially I)

>>I thought it was in F77, but then again, I haven't checked lately.

> No. Definitely not. List-directed I/O was in f77. Internal I/O
> was also in f77, but list-directed internal I/O was not. Several
> compilers didn't support it (and some had pretty obscure symptoms
> if you tried it). I think that most of the later vintage f77
> compilers supported it, but earlier ones did not and it was not
> standard.

Yes, I had remembered the two separately and hadn't thought that
they would work differently when combined. Very strange.

I suppose no-one remembers FIO999.

http://www.soton.ac.uk/~fortran/libraries/cern/old/fio999

-- glen

fortran >> How to convert characters to number On Fri, 23 Jan 2004, glen herrmannsfeldt wrote:
> What does your compiler do with 2F15.6 format, two variables,
> and '57 12' for the input string?
> I would say that it should be 570120000, as blanks are zeros.
> Since it isn't wide enough to reach the second is 0.0.

My Fortran is very rusty, but the following Fortran program:
ACCEPT 10,A,B
TYPE 10,A,B
10 FORMAT (2F15.6)
STOP
END
ran as follows on a TOPS-20 system:

@execute foo
FORTRAN: FOO
MAIN.
LINK: Loading
[LNKXCT MAIN. execution]
57 12
0.005712 0.000000
CPU time 0.01 Elapsed time 5.54
@

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

fortran >> How to convert characters to number Mark Crispin wrote:

(snip)

> My Fortran is very rusty, but the following Fortran program:
> ACCEPT 10,A,B
> TYPE 10,A,B
> 10 FORMAT (2F15.6)
> STOP
> END
> ran as follows on a TOPS-20 system:

(snip)

> [LNKXCT MAIN. execution]
> 57 12
> 0.005712 0.000000
> CPU time 0.01 Elapsed time 5.54

I am 100% sure that blanks count as zero, so that can't
be right. Very strange.

F66, section 7.2.3.6 "With all numeric input conversions, leading
blanks are not significant, and other blanks are zero."

I had thought I remembered one from TOPS-10 days where it
would start the next field after such a blank, even though
it would have been too early in column count.

-- glen

fortran >> How to convert characters to number On Fri, 23 Jan 2004, glen herrmannsfeldt wrote:
> > My Fortran is very rusty, but the following Fortran program:
> > ACCEPT 10,A,B
> > TYPE 10,A,B
> > 10 FORMAT (2F15.6)
> > STOP
> > END
> > ran as follows on a TOPS-20 system:
> > 57 12
> > 0.005712 0.000000
> I am 100% sure that blanks count as zero, so that can't
> be right. Very strange.

You said that you were referring to the F66 specification. The TOPS-20
FORTRAN-20 compiler is F77.

The UNIX f77 compiler more or less agrees with TOPS-20 FORTRAN-20; or
rather, it reads them as the same numeric values but the output is
slightly different.

I had to change the ACCEPT 10 and TYPE 10 statements to READ (5,10) and
WRITE (6,10) before f77 would compile it, but the results are nearly
identical:

% a.out
57 12
.005712 .000000
%

I can understand why TOPS-20 FORTRAN-20 deleted a space in the output of
the first number; it's obviously carriage control. I don't understand why
UNIX f77 added two spaces.

I have long since forgotten enough of my Fortran to know whether F15.6
should output with a zero in front of the decimal point. After all, it
has been 30 years!!!!

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

fortran >> How to convert characters to number glen herrmannsfeldt wrote:

> Mark Crispin wrote:

> (snip)

>> My Fortran is very rusty, but the following Fortran program:
>> ACCEPT 10,A,B
>> TYPE 10,A,B
>> 10 FORMAT (2F15.6)
>> STOP
>> END

(snip)

>> [LNKXCT MAIN. execution]
>> 57 12
>> 0.005712 0.000000

> I am 100% sure that blanks count as zero, so that can't
> be right. Very strange.

> F66, section 7.2.3.6 "With all numeric input conversions, leading
> blanks are not significant, and other blanks are zero."

OK, I tried both WATFIV and Fortran G, and they do what I would
have expected. Reading in with 2F15.6 and out with 2G25.6,
reading from (simulated) card input.

0.570120E 09 0.0

The blank counts as zero, and the decimal point is 9 columns
from the left.

WATFIV will do internal I/O with CHARACTER variables but not
constants, so with a CHARACTER*5 variable containing '71 12' I get:

***ERROR*** FORMATTED LINE EXCEEDS BUFFER LENGTH (IBM CODE IHC212)

That is, reading more characters than the length of the input record.

This would be the error reading more than 80 columns off a card.

-- glen

fortran >> How to convert characters to number glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> OK, I tried both WATFIV and Fortran G, and they do what I would
> have expected. Reading in with 2F15.6 and out with 2G25.6,
> reading from (simulated) card input.

OMG. How are you running THOSE?

fortran >> How to convert characters to number On Fri, 23 Jan 2004, glen herrmannsfeldt wrote:
> OK, I tried both WATFIV and Fortran G, and they do what I would
> have expected.

Could this be an F66/F77 difference?

We seem to have two compilers which do it one way, and two which do it the
other way.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

fortran >> How to convert characters to number Mark Crispin wrote:
> On Fri, 23 Jan 2004, glen herrmannsfeldt wrote:

>>OK, I tried both WATFIV and Fortran G, and they do what I would
>>have expected.

> Could this be an F66/F77 difference?

> We seem to have two compilers which do it one way, and two which do it the
> other way.

It could be. Others have the F77 standard and may tell us.

-- glen

fortran >> How to convert characters to number Paul Rubin wrote:

> glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

>>OK, I tried both WATFIV and Fortran G, and they do what I would
>>have expected. Reading in with 2F15.6 and out with 2G25.6,
>>reading from (simulated) card input.

> OMG. How are you running THOSE?

I run them on a P/370, but others run them on Hercules.

I believe they will still run under z/OS on machines
currently in production.

You didn't ask where Mark Crispin was running TOPS-20, though.

-- glen

fortran >> How to convert characters to number Mark Crispin wrote:

(snip)

>>I am 100% sure that blanks count as zero, so that can't
>>be right. Very strange.

> You said that you were referring to the F66 specification. The TOPS-20
> FORTRAN-20 compiler is F77.

Well, that is mostly because I have a copy of the F66 standard
and not the F77 standard. It may be that it changed, though
I wouldn't expect the blanks are zeros part to change.

> The UNIX f77 compiler more or less agrees with TOPS-20 FORTRAN-20; or
> rather, it reads them as the same numeric values but the output is
> slightly different.

> I had to change the ACCEPT 10 and TYPE 10 statements to READ (5,10) and
> WRITE (6,10) before f77 would compile it, but the results are nearly
> identical:
>
> % a.out
> 57 12
> .005712 .000000
> %

> I can understand why TOPS-20 FORTRAN-20 deleted a space in the output of
> the first number; it's obviously carriage control. I don't understand why
> UNIX f77 added two spaces.

> I have long since forgotten enough of my Fortran to know whether F15.6
> should output with a zero in front of the decimal point. After all, it
> has been 30 years!!!!

The standard, at least F66, leaves some things open. Plus signs
are optional both for the number and the exponent. A leading
zero might be, too. In your case, it is a leading blank that went
to carriage control. A leading zero in F format output is also
optional.

The one I quote from F66 is that on input blanks are treated as
zeros. With blanks treated as zeros, and the decimal point in
the position specified, it should not come out .005712.

-- glen

fortran >> How to convert characters to number glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

>>>I am 100% sure that blanks count as zero...[in f66]

> Well, that is mostly because I have a copy of the F66 standard
> and not the F77 standard. It may be that it changed, though
> I wouldn't expect the blanks are zeros part to change.

Now that you mention it....It has been a long time, but memories
now come back. Yes, that is a difference between f66 and f77,
though the difference is in a subtle place, which causes strange
consequences, as I now recall running into.

In f66, as you note, blanks were treated as zeros (on formatted
input - that's what we are talking about, so I won't keep repeating
the qualification).

F77 added the BLANK= specifier to the OPEN statement and it
defaults to BLANK='NULL'. I recall thinking this a big improvement
for integer input. You no longer got 420 instead of 42 if you
accidentally were off a column in your typing....or as 4200000000
if you typed it left-justified instead of right. Of course, for
reals, I always used an explicit decimal point, so it didn't matter.

The subtlety is that the specification that the default is null
is in the definition of the OPEN statement. If you didn't use an
OPEN statement, then this didn't apply and nothing in the
standard specified the default. I initially failed to notice
this subtlety and got bitten when I ported some of my codes to
a compiler that defaulted to blanks zero for internal reads
(which don't involve an OPEN statement). At the time I thought
it quite quirky that the compiler made the default different
for reads without an OPEN. I now suppose that was probably for
f66 compatibility. So strictly speaking, f77 doesn't specify
whether f66 code (without OPENs) is compatabile with f66 in this
regard or not.

Later versions of the standard specified that the default for
other kinds of input was also null, just like it was for an
OPEN statement. I'd have to do some extra reading to track
down exactly when this additional specification was added
(might have been done in 2 stages).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

fortran >> How to convert characters to number glen herrmannsfeldt wrote:
...
> Well, that is mostly because I have a copy of the F66 standard
> and not the F77 standard. It may be that it changed, though
> I wouldn't expect the blanks are zeros part to change.

Last time I looked, the F77 standard was online at www.fortran.com.
It's in html and not pdf, but it's all there. There's also a plain text
version which I find harder to read.

Try http://www.fortran.com/F77_std/rjcnf.html

--
J. Giles

fortran >> How to convert characters to number On Fri, 23 Jan 2004, glen herrmannsfeldt wrote:
> You didn't ask where Mark Crispin was running TOPS-20, though.

That's because it's well known that I have a TOPS-20 system on the
Internet 24/7.

I also own two working 2020 systems, but I generally don't run them any
more given that Lingling is about 75 times faster and runs an extended
addressing monitor with TCP/IP.

I am aware of at least 19 TOPS-20 systems on the Internet today, of which
9 are operational 24/7 on the open Internet and 3 more are probably
operational but are inaccessible behind firewalls.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

fortran >> How to convert characters to number Richard Maine wrote:
...
> F77 added the BLANK= specifier to the OPEN statement and it
> defaults to BLANK='NULL'. I recall thinking this a big improvement
> for integer input. You no longer got 420 instead of 42 if you
> accidentally were off a column in your typing....or as 4200000000
> if you typed it left-justified instead of right. Of course, for
> reals, I always used an explicit decimal point, so it didn't matter.

Indeed, the F77 standard is ambiguous about whether the implied
decimal point is placed before or after the blanks are removed
and the remaining digits are right justified in the field. That
gave me fits when implementing this. I placed the implied
decimal point before compressing out the spaces. Apparently
that's not the way other implementations chose to work.

The F90, F95, and proposed F2kV standards all retain this
ambiguity, thought maybe there's an interp. I still think it
works more naturally if the implied point is placed before
the spaces are removed. It's better, of course, if the user
supplies an explicit decimal point.

--
J. Giles

fortran >> How to convert characters to number In article <Pine.WNT.4.60.0401231449080.3648@Tomobiki-Cho.CAC.Washington.EDU>,
Mark Crispin <MRC@CAC.Washington.EDU> wrote:
>On Fri, 23 Jan 2004, glen herrmannsfeldt wrote:
>> You didn't ask where Mark Crispin was running TOPS-20, though.
>
>That's because it's well known that I have a TOPS-20 system on the
>Internet 24/7.
>

Furthermore, at least in a.s.pdp10, it's common knowledge that these
days it's not terribly difficult to do such a thing.

>I am aware of at least 19 TOPS-20 systems on the Internet today, of which
>9 are operational 24/7 on the open Internet and 3 more are probably
>operational but are inaccessible behind firewalls.
>

Lame as it may seem, my "big" PC is too loud to keep running 24/7.
This means that I only have my own TOPS-20 sandbox intermittently.

--
David Evans dfevans@bbcr.uwaterloo.ca
Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/
University of Waterloo "Default is the value selected by the composer
Ontario, Canada overridden by your command." - Roland TR-707 Manual

fortran >> How to convert characters to number In article <AIgQb.107023$sv6.517374@attbi_s52>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
>Mark Crispin wrote:
>
>(snip)
>
>>>I am 100% sure that blanks count as zero, so that can't
>>>be right. Very strange.
>
>> You said that you were referring to the F66 specification. The TOPS-20
>> FORTRAN-20 compiler is F77.
>
>Well, that is mostly because I have a copy of the F66 standard
>and not the F77 standard. It may be that it changed, though
>I wouldn't expect the blanks are zeros part to change.
>
>> The UNIX f77 compiler more or less agrees with TOPS-20 FORTRAN-20; or
>> rather, it reads them as the same numeric values but the output is
>> slightly different.
>
>> I had to change the ACCEPT 10 and TYPE 10 statements to READ (5,10) and
>> WRITE (6,10) before f77 would compile it, but the results are nearly
>> identical:
>>
>> % a.out
>> 57 12
>> .005712 .000000
>> %
>
>> I can understand why TOPS-20 FORTRAN-20 deleted a space in the output of
>> the first number; it's obviously carriage control. I don't understand
why
>> UNIX f77 added two spaces.
>
>> I have long since forgotten enough of my Fortran to know whether F15.6
>> should output with a zero in front of the decimal point. After all, it
>> has been 30 years!!!!
>
>The standard, at least F66, leaves some things open. Plus signs
>are optional both for the number and the exponent. A leading
>zero might be, too. In your case, it is a leading blank that went
>to carriage control. A leading zero in F format output is also
>optional.
>
>The one I quote from F66 is that on input blanks are treated as
>zeros.

There's a difference between leading blanks and embedded blanks.

> .. With blanks treated as zeros, and the decimal point in
>the position specified, it should not come out .005712.

But, in this case, the blank input between the 57 and 12 was
treated as a null.

/BAH

Subtract a hundred and four for e-mail.