|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
RichardMay
Joined: 02 May 2006 Posts: 25
|
Posted: Thu Apr 19, 2007 5:27 pm Post subject: Input read error |
|
|
The short program below is abbreviated from a fixed format read routine from a program that was written many years ago but is still used regularly.
PROGRAM READCARD
CHARACTER*80 CARD,CODE1*1,CENDR*3,CW2*2
CHARACTER CFORM1*26,CFORM2*29
DIMENSION XP(3),XI(3)
CFORM1= '(A1,A3,A2,I4,I5,I5,6F10.0)'
CFORM2='(1X,A1,A3,A2,I4,I5,I5,6F10.3)'
OPEN(16,FILE='CARD.DAT')
OPEN(17,FILE='CARD.OUT')
C READ CARD
READ(16,1020,END=9999)CARD
1020 FORMAT(A)
C READ AS NODE
READ(CARD,CFORM1,ERR=35)CODE1,CENDR,CW2,NODE,NUMN,NODEIN,XP,XI
C CARD ECHO
WRITE(17,CFORM2)CODE1,CENDR,CW2,NODE,NUMN,NODEIN,XP,XI
GOTO 9999
35 WRITE(17,1001)
1001 FORMAT('DATA ERROR')
9999 STOP
END
When the input line is
019004 -200.975 -150.0 -300.0
The program correctly writes 'DATA ERROR'.
Note that the value -200.975 is in the ‘wrong’ columns. (How do I use a fixed width font here?)
When the value -150.0 is replaced by an integer -150, the program writes
019004 0 0 -200.970 0.000 -300.000 0.000 0.000 0.000
Not only does it read 0.000 incorrectly, it appears to set an error flag somewhere not related to this routine at all, so that we later get a Floating Point Overflow error. (I tried to paste the error message here but it doesn't work).
Richard May |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Fri Apr 20, 2007 11:36 am Post subject: |
|
|
I do not understand the problem. The result of the first input is
CODE1 = '0'
CENDR = '190'
CW2 = '04
NODE = -20
NUMN is undefined because of a data error.
It seems to me that the data should contain either extra text and/or some integers. |
|
Back to top |
|
|
RichardMay
Joined: 02 May 2006 Posts: 25
|
Posted: Fri Apr 20, 2007 12:25 pm Post subject: |
|
|
Paul,
This really needs a fixed width font; I'll use _ for spaces. The 1st input line is
____019004_____________-200.975___-150.0____-300.0
This results in
CODE1 = '_'
CENDR = '___'
CW2 = '01'
NODE = 9004
NUMN = 0
NODEIN = 0
XP = -200.97,5___-150.0,-300.0
The spaces in the 2nd element of XP lead to the error message, which is correct.
The 2nd input line is
____019004_____________-200.975_____-150____-300.0
which leads to
XP = -200.97,5___-150,-300.0
and the 2nd element is interpreted as 0.0 with a spurious error flag.
Richard May |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Apr 23, 2007 8:33 am Post subject: |
|
|
I still do not see the problem.
You need 20 columns for the characters and integers then start at column 21 with 6 real values of width 10, i.e. at positions 21, 31, 41....
Seems to work OK. |
|
Back to top |
|
|
RichardMay
Joined: 02 May 2006 Posts: 25
|
Posted: Mon Apr 23, 2007 11:47 am Post subject: |
|
|
Yes, that is what the input should be. BUT, there are errors in the input.
1. The value -200.975, which should be in columns 21-30, is actually in columns 24-31, i.e. it spills over to the next field.
2. In the 2nd input line the real value -150.0 has been truncated to an integer, -150.
When -150.0 is a real, the program give an error message as expected. When -150 is an integer it does not.
If you still can't see it then I'll have to send you my program + the two data files. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Mon Apr 23, 2007 4:20 pm Post subject: |
|
|
OK I now now understand the problem.
We will investigate the failure to give an error report. |
|
Back to top |
|
|
Martin
Joined: 09 Sep 2004 Posts: 43
|
Posted: Wed Apr 25, 2007 9:10 pm Post subject: |
|
|
Hi Richard,
The output from your program appears correct to me.
With your input of Code: | 019004 -200.975 -150 -300.0 | you have -200.97 in the first floating point field and in the second. The blanks are ignored and the -150 is treated as an exponent (as specified by the fortran standard).
This gives you a very small number (5E-150) - so small that when you try and store it in your single precision real you get a floating point underflow as the smallest positive number a floating point real can store is 1E-38. the underflow is ignored by default, but if you compile with the /underflow command line option the floating point underflow will be reported as an error. The stack trace should report the error occuring within the runtime library, with your routine further down. |
|
Back to top |
|
|
Martin
Joined: 09 Sep 2004 Posts: 43
|
Posted: Wed Apr 25, 2007 9:10 pm Post subject: |
|
|
By the way, you can display text in a fixed width font in this forum by placing it within the [code][/code] tags as I did in my previous post. |
|
Back to top |
|
|
RichardMay
Joined: 02 May 2006 Posts: 25
|
Posted: Thu Apr 26, 2007 2:04 pm Post subject: |
|
|
Thanks. I didn't know the Fortran standard treated 5 -150 as an exponent. We will have to trap this type of input error ourselves. The stack trace did not mention the routine where this data was read, it indicated a completely different part of the program. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Tue May 01, 2007 2:23 am Post subject: |
|
|
I have recently encountered this problem, where the E in the exponent is omitted. This was the first time in over 33 years of using fortran.
Values such as "1.234-05" being used as a semi compressed form of "1.234e-05" for coordinates.
I have not tried to select this format in a write statement and it can become an annoyance, as other packages, such as Excel, do not recognise the format.
I was not aware that "1.234___-05" was also allowable, which is hardly compressed.
Does anyone know the history of this compressed scientific notation in fortran ?
Shouldn't the embedded blanks be an error ? It would certainly be better if it was, as in most cases scientific notation would not be what is intended.
regards John |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7924 Location: Salford, UK
|
Posted: Tue May 01, 2007 7:50 am Post subject: |
|
|
The compressed form 1.234-05 is listed in the Fortran standard.
The possible inclusion of blanks is not mentioned so must be
considered as a FTN95 extension to the standard.
The extension is probably not trapped by using /ISO on the
FTN95 command line but I guess we could see if this might
be easy to implement. As always we have to be careful
not to break existing software. |
|
Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006 Posts: 2554 Location: Sydney
|
Posted: Thu May 03, 2007 4:22 am Post subject: |
|
|
Paul,
The valid use of blanks is a difficult one, as the following code may show.
It might be valid to include blanks to separate 000's in large integers and using either (I12) or (BN,I12) formats this does work. I've certainly never used this but it may be a valid form. It's a better alternative to the European '.' separator or the American ',', but it's a bit late to start something new.
I would doubt that strings like '1.05 -5' would be intended. It looks more like a data error to me, but there are a lot of different interpretations out there !
! test of blanks in a number
!
character number_string*12
integer*4 num, iostat
!
number_string = ' 1 000 000 '
read (number_string,fmt='(i12)', iostat=iostat) num
write (*,*) 'I12 read gives', num, iostat
!
read (number_string,fmt='(bn,i12)', iostat=iostat) num
write (*,*) 'bn,I12 read gives', num, iostat
!
read (number_string,fmt='(bz,i12)', iostat=iostat) num
write (*,*) 'bz,I12 read gives', num, iostat
!
end
This program gives:
[FTN95/Win32 Ver. 4.9.1 Copyright (c) Silverforst Ltd 1993-2006]
NO ERRORS [<main program> FTN95/Win32 v4.9.1]
Creating executable: C:\temp\test\lgotemp@.exe
Program entered
I12 read gives 1000000 0
bn,I12 read gives 1000000 0
bz,I12 read gives 1000000000 0 |
|
Back to top |
|
|
Martin
Joined: 09 Sep 2004 Posts: 43
|
Posted: Thu May 03, 2007 11:30 pm Post subject: |
|
|
I think FTN95 complies with the standard regarding the inclusion of (non-leading) blanks in a numerical input field, including when using the F edit descriptor.
The standard says there is a blank interpretation mode which can either be NULL or ZERO. When it is NULL blanks are ignored. When it is ZERO blanks are treated as 0's. The OPEN statement has a BLANK= specifier for setting this mode, which defaults to NULL if not present. Data transfer statements can also have a BLANK= specifier to override the current blank interpretation mode for that statement. The BN and BZ format edit descriptors also temporarily change the mode. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|