Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde!uunet!cs.utexas.edu!sun-barr!newstop!sun!dgh!dgh From: dgh%dgh@Sun.COM (David Hough) Newsgroups: comp.lang.fortran Subject: Re: What's a legitimate floating-point number? (somewhat long) Summary: the test suite is the standard Keywords: .e0 Message-ID: <128796@sun.Eng.Sun.COM> Date: 5 Dec 89 17:08:10 GMT References: <128706@sun.Eng.Sun.COM> Sender: news@sun.Eng.Sun.COM Lines: 167 It turns out I needn't have sweated the issue of ".e0" so much. Whether or not you want to grab some of DEC's market, you'll need to pass the FCVS to obtain significant commercial success. And it turns out to pass FCVS 110 you'll need to be able to recognize the following four 15-character fields as zero: " " "+ " "+ . D+00" " . D0" This is in the default (BLANK=NULL or BN) mode. Now is this consistent with the Fortran-77 standard? You can read about the properties of BLANK=NULL and BLANK=ZERO, or BN and BZ, in the standard. You might then take exception to the foregoing tests, but it hardly matters. You won't get a lot of satisfaction out of complaining to the Federal Software Testing Center. The last time I did that (1986, about some other matters) I got a report dated 1 April 1983 listing the things I'd complained about as "under study". Presumably they're still being studied. Anyway, I updated the test program to properly distinguish these cases and a few others and reran it. After making the required modifications to the floating-point number syntax scanner, the new results are no error input > < ZERO fmt x 0. no error input > < NULL fmt x 0. fcvs case ERROR input > < * fmt x -1.00000 no error input >+ < ZERO fmt x 0. no error input >+ < NULL fmt x 0. fcvs case ERROR input >+ < * fmt x -1.00000 ERROR input >++1 < ZERO fmt x -1.00000 ERROR input >++1 < NULL fmt x -1.00000 ERROR input >++1 < * fmt x -1.00000 no error input >+ +1 < ZERO fmt x 0. no error input >+ +1 < NULL fmt x 0. ERROR input >+ +1 < * fmt x -1.00000 ERROR input >.e0 < ZERO fmt x -1.00000 ERROR input >.e0 < NULL fmt x -1.00000 ERROR input >.e0 < * fmt x -1.00000 ERROR input >+.e0 < ZERO fmt x -1.00000 ERROR input >+.e0 < NULL fmt x -1.00000 ERROR input >+.e0 < * fmt x -1.00000 ERROR input > .e0 < ZERO fmt x -1.00000 ERROR input > .e0 < NULL fmt x -1.00000 ERROR input > .e0 < * fmt x -1.00000 no error input >+ .e0< ZERO fmt x 0. no error input >+ .e0< NULL fmt x 0. ERROR input >+ .e0< * fmt x -1.00000 no error input >. e0 < ZERO fmt x 0. no error input >. e0 < NULL fmt x 0. ERROR input >. e0 < * fmt x -1.00000 no error input >+. e0< ZERO fmt x 0. no error input >+. e0< NULL fmt x 0. ERROR input >+. e0< * fmt x -1.00000 no error input > . e0< ZERO fmt x 0. no error input > . e0< NULL fmt x 0. fcvs case ERROR input > . e0< * fmt x -1.00000 no error input >1 .0 < ZERO fmt x 10.00000 no error input >1 .0 < NULL fmt x 1.00000 no error input >1 .0 < * fmt x 1.00000 no error input >. 1 < ZERO fmt x 1.00000E-02 no error input >. 1 < NULL fmt x 1.00000E-01 ERROR input >. 1 < * fmt x -1.00000 no error input >.1 2 < ZERO fmt x 1.02000E-01 no error input >.1 2 < NULL fmt x 0.120000 no error input >.1 2 < * fmt x 1.00000E-01 diffs with the current Fortran release are just < no error input >.e0 < ZERO fmt x 0. < no error input >.e0 < NULL fmt x 0. > ERROR input >.e0 < ZERO fmt x -1.00000 > ERROR input >.e0 < NULL fmt x -1.00000 < no error input >+.e0 < ZERO fmt x 0. < no error input >+.e0 < NULL fmt x 0. > ERROR input >+.e0 < ZERO fmt x -1.00000 > ERROR input >+.e0 < NULL fmt x -1.00000 < no error input > .e0 < ZERO fmt x 0. < no error input > .e0 < NULL fmt x 0. > ERROR input > .e0 < ZERO fmt x -1.00000 > ERROR input > .e0 < NULL fmt x -1.00000 So I have succeeded in distinguishing this degenerate case from others which I know must pass. By the way, the Fortran-77 standard is quite clear that an all-blank field must be recognized as a zero under NULL mode but doesn't say so explicitly under ZERO mode. So that's one of the inferences I drew. In general, both NULL and ZERO modes are supposed to ignore leading blanks. Subsequent blanks are interpreted as zeros (ZERO mode) or ignored (NULL mode) but if you do that then "+ " won't be recognized and you'll fail FCVS 110. So in effect you discover that under NULL mode blanks don't count for anything in terms of the value of the number but any non-trailing blank legitimizes an input if a zero in the same place would have legitimized it. Revised source for my test program is subroutine test(d) real x character*10 s character*5 d s = "(BZ,f5.1)" x=-1 read (d,s, ERR = 3) x print *," no error "," input >",d,"< ZERO fmt "," x ",x goto 31 3 continue print *," ERROR "," input >",d,"< ZERO fmt "," x ",x 31 continue s = "(BN,f5.1)" x=-1 read (d,s, ERR = 2) x print *," no error "," input >",d,"< NULL fmt "," x ",x goto 21 2 continue print *," ERROR "," input >",d,"< NULL fmt "," x ",x 21 continue s = " " x=-1 read (d,*, ERR = 1) x print *," no error "," input >",d,"< * fmt "," x ",x goto 11 1 continue print *," ERROR "," input >",d,"< * fmt "," x ",x 11 continue end character*10 d d = " " call test(d) d = "+ " call test(d) d = "++1 " call test(d) d = "+ +1 " call test(d) d = ".e0 " call test(d) d = "+.e0 " call test(d) d = " .e0 " call test(d) d = "+ .e0" call test(d) d = ". e0 " call test(d) d = "+. e0" call test(d) d = " . e0" call test(d) d = "1 .0 " call test(d) d = ". 1 " call test(d) d = ".1 2 " call test(d) end David Hough na.hough@na-net.stanford.edu