Subject: Blanks in ASCII columns

From: pence at heawk1.gsfc.nasa.gov ( William Pence)
Date: Thu, 2 Apr 1992 19:30:30 GMT

How should a FITS reader interpret trailing blanks in a numeric ASCII
table field?  For instance, if the TFORM keyword for the field is 'I4'
and the 4 characters in the field are '12  '  (that is, the characters
1 and 2 followed by 2 blanks) then should this be read as the integer 12
or the integer 1200?  This is analogous to the BN or BZ format options
in a Fortran read, which either cause blanks to be ignored or to be
interpreted as zeros.  I looked in the NOST Implementation of FITS document
but it provided no guidance on this question.  It turns out that different
compilers don't all have the same default interpretation, so I will need
to force the FITSIO subroutines to be consistent, one way or the other.
My own preference is to treat trailing blanks in the field as zeros
(e.g., would read 1200 in the above example).   Any other opinions?

-Bill Pence, HEASARC
pence at tetra.gsfc.nasa.gov  or HEASRC::PENCE

---

From: cflatter at nrao.edu (Chris Flatters)
Date: Thu, 2 Apr 1992 20:48:18 GMT

>(e.g., would read 1200 in the above example).   Any other opinions?

I do not have the FORTRAN 77 standard handy but in Fortran 90 non-leading
blank characters in numeric fields are treated according to the value
of the BLANK= Specifier in the OPEN statement.  The chapter and verse
for the BLANK= specifier is

	9.3.4.6 BLANK= Specifier in the OPEN Statement.  The scalar-default-char-expr
	must evaluate to NULL or ZERO.  The BLANK= specifier is permitted only for
	a file being connected for formatted input/output.  If NULL is specified,
	all blank characters in numeric formatted input fields on the specified
	unit are ignored, except that a field of all blanks has a value of zero.
	If ZERO is specified, all blanks other than leading blanks are treated
	as zeros.  If this specifier is omitted, the default value is NULL.

In Fortran 90, the default behaviour is to read '12  ' as 12 using an I4
descriptor.  I believe that the same is true of FORTRAN 77 (& the only text
book I have handy concurs).

I think that the NOST document should be revised to make the interpretations
of the edit descriptors used to describe ASCII tables much more precise and
to remove the necessity to make paper subroutine calls to the FORTRAN standard.
As written the standard for ASCII tables makes life very difficult for people
working in languages other than FORTRAN.

	Chris Flatters
	cflatter at nrao.edu

---

From: bschlesinger at nssdca.gsfc.nasa.gov (Barry Schlesinger)
Date: Thu, 2 Apr 1992 22:25:00 GMT

In article <pence.702243030 at heawk1>, pence at heawk1.gsfc.nasa.gov ( William Pence) writes...
 > or the integer 1200? 

The relevant discussions appear in the FITS Tables paper (A&A Suppl. 
73,365 for those not familiar with it):

"To prevent trailing blanks from defaulting to trailing zeroes, the 
decoding of table extension data should be done as though the 
FORTRAN-77 OPEN statement specifier BLANK is set to NULL (i. e., blank 
characters should be ignored)."

and in the NOST Standard, the last sentence of 8.1.5:

"Blanks within the fields are not to be interpreted as zeroes; zeroes 
must be given explicitly."

By these two prescriptions, the field would be read as 12.
	The ASCII Tables paper urges that "integers and floating point
numbers should be right justified to prevent the problem of how
trailing blanks are treated in different computers."  So, FITS writers
should not create fields like the one described above.  Unfortunately,
FITS readers have to be prepared to deal with issues like this that
can arise from deficiencies in design elsewhere. 

				Barry Schlesinger
				FITS Support Office

---

From: pence at heawk1.gsfc.nasa.gov ( William Pence)
Date: 3 Apr 92 19:26:21 GMT

>must be given explicitly."

Thanks, Barry.  That is pretty unambiguous, so I'll modify FITSIO accordingly.

-Bill Pence