Subject: fits ambiguities

From: davis at space.mit.edu (John E. Davis)
Date: 30 Nov 1995 20:59:36 GMT

Hi,

  In a previous article I mentioned that there are some ambiguities in the
fits definition and indicated a need for a formal grammar for fits keywords.
I believe that such problems need to be addressed before programs that
convert fits to other data formats can be constructed.

  Here is an example of one ambiguity:
  
         1         2         3         4         5         6         7
1234567890123456789012345678901234567890123456789012345678901234567890
AMBIG1  =                    10 is more common
AMBIG2  =                    1                   0 is more common
AMBIG3  =                    1                   10 is less common

As far as I can tell, these lines are permitted by the fits standard
although they are strongly discouraged.  Nevertheless, it is not clear how
they should be interpreted.  

AMBIG1 is a keyword whose value is 1 with comment `0 is more common'.  There
is no ambiguity here.
AMBIG2 is either equivalent to AMBIG1 or represents a complex integer.
AMBIG3 is equally problematic.

How should one resolve these ambiguities?  Again, issues like these have to
be dealt with before software will be able to interpret such values.

Thanks,
--John

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 4 Dec 1995 14:59:30 GMT

davis at space.mit.edu (John E. Davis) writes:

>On 1 Dec 1995 20:34:19 GMT, William Thompson <thompson at orpheus.nascom.nasa.gov>
>wrote:
> : davis at space.mit.edu (John E. Davis) writes:
> : >  Here is an example of one ambiguity:
> : >  
> : >         1         2         3         4         5         6         7
> : >1234567890123456789012345678901234567890123456789012345678901234567890
> : >AMBIG1  =                    10 is more common
> : >AMBIG2  =                    1                   0 is more common
> : >AMBIG3  =                    1                   10 is less common
> : 
> : >As far as I can tell, these lines are permitted by the fits standard
> : >although they are strongly discouraged.  Nevertheless, it is not clear how
> : >they should be interpreted.  
> : 
> : >AMBIG1 is a keyword whose value is 1 with comment `0 is more common'.  There
> : >is no ambiguity here.
> :     ^^
> : 
> : I disagree.  This is also ambiguous.  It could be interpreted as a character
> : string with the quotes left off--many poorly designed FITS writers do this.
> : The only completely non-ambiguous form would be
> : 
> : 1234567890123456789012345678901234567890123456789012345678901234567890
> : AMBIG0  =                    1 /0 is more common

>I can use your argument to argue that this is also ambiguous.  There
>should be no excuse for fits writers to omit the quotes.  If a ``fits'' file
>does not follow the syntax that the fits standard requires, then it is not a
>fits file.   Such a file should have set the boolean flag `SIMPLE' to `F'.

Yes, you could argue that if one is allowed to have strings without quotes,
then everything is ambiguous.  I can't really argue with you there.

Mainly, I was complaining about leaving the / off to mark the comment.  I
consider the / delimiter to be as essential as the quote signs.

Bill Thompson

---

From: doggett at stsci.edu (Jesse B. Doggett)
Date: 4 Dec 1995 18:22:21 GMT

> This brings up one of my "favorite" problems in the FITS definitions
> which I've read.  Suppose one wants the equivalent of:
>
>	Name:  O'Malley
>
> As I've read the standards there are two possibilities:
>
>	NAME    = 'O''Malley '
>	NAME    = 'O'Malley  '
>
> (Pardon if I misscount spaces, my point is the arrangment of "'".) 
> For me, the first is ambigious, since it could be:  Name:  O''Malley
> The second is not ambigious, since the ending quote must be at column
> 20 or beyond.  Of course, I don't know how many FITS readers would
> agree with me.

The first is not actually ambiguous.  Name:  O''Malley would be
in the header as:

        NAME    = 'O''''Malley '

The second would fail because the string might include "'" beyond
column 20, eg,

       NAME: 1234567890123456789012345678910'ABCD

would then presumably be put in the header as:

       NAME   = '123456789012345678901234567890'ABCD'

But, this would parse as the string '123456789012345678901234567890' with comment ABCD'.
It should be:

       NAME    = '123456789012345678901234567890''ABCD'

---

From: tferro at merlin.la.asu.edu (Anthony J. Ferro)
Date: 4 Dec 1995 23:45:30 GMT

Jesse B. Doggett (doggett at stsci.edu) wrote:

: The second would fail because the string might include "'" beyond
: column 20, eg,

:        NAME: 1234567890123456789012345678910'ABCD

: would then presumably be put in the header as:

  I agree that after column 20, the double-single quote, "''", is required
  as is the Fortran standard.  Between columns 11 and 20, however, it 
  is not clear what is meant.  Any quotes in this range cannot be the 
  end-of-string marker, so why should they be doubled?  The standards
  say, as I recall, that one should follow the Fortran standard.  To
  me this breaks down in the case of short strings.  All Fortrans I
  know of allow short strings but FITS doesn't.  (Some versions do 
  require that they use a full word of space, however.)

  I haven't reviewed the notes, but does "''" count as two characters
  or one?  This might be important in a case such as NAME: 1'A

			- Tony

---------
Anthony J. Ferro				aferro at as.arizona.edu
Steward Observatory, NICMOS Project		Ph:  (520) 621-8683
University of Arizona				FAX: (520) 621-1891	
Tucson, AZ 85721
---------

---

From: kkuehl at ih4gp743.ih.att.com (Kevin Kuehl)
Date: Tue, 5 Dec 1995 13:08:55 GMT

In article <49vmr9$ptb at post.gsfc.nasa.gov>,
William Thompson <thompson at achilles.nascom.nasa.gov> wrote:
>Yes, but in section 5.3.1 it states
>
>	The fixed format is required for values of mandatory keywords and
>	recommended for values of all others.
>	^^^^^^^^^^^
>
>The "recommended" is an example of the ambiguity that the FITS standard as
>written allows, and which the original author was (rightly) complaining about.
>I certainly don't condone or defend such practise--note that I said "poorly
>dessign"--but I've seen it done.

I guess I skipped over that part because I couldn't believe
that it meant what you are saying.  I am not saying you are
wrong, I just couldn't believe that the standard said that
a FITS writer did not always have to adhere to the value
definitions.  How are readers supposed to read FITS files
if writers don't have to adhere to the standard?  Yuck!
-- 
Kevin
kevin.r.kuehl at att.com

---

From: William Pence <pence at tetra.gsfc.nasa.gov>
Date: Wed, 6 Dec 1995 16:06:42 -0500

On the subject of FITS keyword 'ambiguities'  it might be of interest
to give a short explaination of how the FITSIO software package
(http://heasarc.gsfc.nasa.gov/docs/software /fitsio/fitsio.html)
interpretes header keywords.  I believe this interpretation is
consistent with  all the rules defined in the FITS standard.  While the
FITS standard could perhaps be made clearer, I don't see any
significant ambiguities in how to interpret FITS keywords (except
perhaps for complex keywords as illustrated below).

Except for the few required FITS keywords (SIMPLE, BITPIX, NAXIS, etc)
which have a fixed format integer or logical value, all other keyword
values are interpreted following the Fortran free-format rules.  First,
the keyword value field is defined to be the first 'token' in the FITS
80-byte keyword record following the '= ' characters in column 9 and
10.  (If there is no '= ' in columns 9 and 10, then by definition the
keyword has no value field).  The value token is defined to be either
the first consecutive string of non-blank ASCII text characters, or if
the first character is a single quote, then as a string of ASCII text
characters (including any spaces) enclosed within the first pair of
single quotes.  The data type and value of this token is then
determined from the following rules:

1.  If the token begins with a single quote character then the value is
a character string.  The string extends to the next single quote
character in the value token, except that 2 consecutive single quote
characters are interpreted as a literal single quote character within
the string.   The rules for a fixed format character string require
that the leading quote character be in column 11 and the closing quote
character be no earlier than column 20, but a free format string value
is not constrained by this.  Leading spaces in the quoted string are
significant, but trailing spaces are not.

2. If the token consists of a single upper case T or F character then
the value is interpreted as a true or false logical value.

3. If the token contains only digits (0 - 9) then the value is
interpreted as a decimal integer.

4. If none of the above then the token must be a floating point
numerical value, either in fixed decimal format, or exponential
format.

If the token does not conform to one of these 4 rules, then the keyword
value is invalid and it does not conform to the FITS standard.

Any remaining characters following the value token are generally
interpreted as a comment field.  If the first non-blank character
following the value token is a slash (`/`) character then this is
interpreted as a separator between the value and comment fields.

Alternatively, instead of a comment field, there may be another
numerical value field following the first numerical value token.
Keywords like this with 2 numeric tokens can be interpreted as a
complex number with the first token representing the real part and the
second token representing the imaginary part.  As I understand the FITS
standard, this interpretation is not required, so it is up to the reader
to decide whether the second number should be interpreted as the
imaginary part of the complex number, or as a comment to the real
floating point number.  The last example below illustrates this
ambiguity.  In practice I have never seen a FITS file that uses the
complex keyword format.

Finally, a few examples.  The first example in each group follows
the recommended rules for a fixed format keyword.

These are all legal FITS string keywords with identical value and comment fields:
1234567890123456789012345678901234567890
STRING1 = 'DOG     '           / It's an animal
STRING2 =     'DOG    ' / It's an animal
STRING3 =     'DOG   '       It's an animal
STRING4 = 'DOG'It's an animal

Notice in the STRING4 example, even when the / and space characters are
omitted, (which is obviously NOT recommended) there is still no
ambiguity between the value and comment fields.

These are all legal FITS integer keywords with identical value and comment fields:
1234567890123456789012345678901234567890
INTEGER1=                 -273 / absolute zero
INTEGER2= -273     / absolute zero
INTEGER3=    -273 absolute zero

These are all legal FITS logical keywords with identical value and comment fields:
1234567890123456789012345678901234567890
LOGICAL1=                    T / a true value
LOGICAL2= T /a true value
LOGICAL3=   T a true value

These are legal FITS floating point keywords with identical values and comments:
1234567890123456789012345678901234567890
FLOAT1  =       12345.67890123 / 10 times greater than expected
FLOAT2  = 1.234567890123D+04            /      10 times greater than expected
FLOAT3  = 1234.567890123       10 times greater than expected

This last example is actually ambiguous;  it can either be interpreted as
a real floating point number with the comment '10 times greater than expected'
or as a complex number with the value (1234.567890123, 10.) and a
comment 'times greater than expected'.

Bill Pence
HEASARC/GSFC/NASA

---

From: seaman at noao.edu (Rob Seaman)
Date: 5 Dec 1995 20:50:32 GMT

>   recommended for values of all others.

The two sentences before this one are:

    "Unless otherwise specified, the value field must be written in a
    notation consistent with the list-directed read operations in ANSI
    FORTRAN-77.  The structure shall be determined by the type of the
    variable."

The only explicit exceptions "otherwise specified" in section 5.3 are
complex integer and complex floating point valued keywords, which omit
the parentheses and separating comma that are required by FORTRAN-77.
Complex numbers are indeed ambiguously represented in FITS keywords -
assuming the user and the software aren't expecting to read a complex
number, and are accepting of nonsensical keyword comments.

On the other hand, FORTRAN-77 list-directed reads require that strings
be single quoted and that embedded quotes (apostrophes) be represented
by two consecutive quotes.  Therefore, non-quoted FITS keyword values
cannot legally be interpreted as strings.

To the question of whether FITS integers are required to be decimal,
I don't see any ambiguity at all.  Barry's original reply:

> In the FITS papers, reference to integer format, when unmodified, is
> generally understood to mean decimal integers.  In the original FITS
> paper, integer format is discussed in the context of FORTRAN, whose
> standard integers are decimal.  [...]

just isn't strong enough.  FITS keyword usage isn't only "discussed" in
the context of FORTRAN - it is defined in that context.  List directed
FORTRAN-77 input requires that the form of the input be acceptable for a
constant of the given type (ANSI X3.9-1978, section 13.6.1).  A FORTRAN-77
integer constant is "interpreted as a decimal number" (ANSI X3.9-1978,
section 4.3.1).  It wouldn't hurt to emphasize this in the FITS documents,
though.

FITS is certainly informally specified in computer science terms.  It
does, however, rely on the most standard scientific computing reference
that was available at the time, namely ANSI X3.9-1978 FORTRAN-77.  It
would be interesting, though, to see someone reconstruct a real grammar
for FITS - surely there's FITS software relying on a formal parser that
could be unraveled for the job.  (Anybody? It would make a good ADASS
paper for next year.)

Rob Seaman
-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B

---

From: davis at space.mit.edu (John E. Davis)
Date: 3 Dec 1995 17:32:32 GMT

I am more concerned about the informal nature of the NOST fits definition.
The descriptions should supplemented by something more formal and the
ambiguities that I described above should be resolved by the standard.

--John

---

From: "Dr. Immanuel Freedman" <immanuel at mother.com>
Date: 7 Dec 1995 02:46:27 GMT

Rob

The COBE project built an "awk"-based parser/converter to convert VAX DDL & COBE
RDL record definitions to FITS.  The 2-step process involved creating a FITS
header from the Record Definition Compiler output & using FITSIO to perform
the conversion based on that header. Almost 1000 record structures were converted.

If, interested, please contact Don West or John Mather at NASA Code 680,

Dr. Immanuel Freedman
(619) 658 0236

---

From: thompson at orpheus.nascom.nasa.gov (William Thompson)
Date: 1 Dec 1995 20:34:19 GMT

>AMBIG1 is a keyword whose value is 1 with comment `0 is more common'.  There
    ^^

I disagree.  This is also ambiguous.  It could be interpreted as a character
string with the quotes left off--many poorly designed FITS writers do this.
The only completely non-ambiguous form would be

1234567890123456789012345678901234567890123456789012345678901234567890
AMBIG0  =                    1 /0 is more common

Bill Thompson

---

From: kkuehl at ih4gp743.ih.att.com (Kevin Kuehl)
Date: Sun, 3 Dec 1995 23:29:13 GMT

In article <slrn4c3npg.n5.davis at wiwaxia.mit.edu>,
>ambiguities that I described above should be resolved by the standard.

I agree.  I am new to FITs and I expected to see some grammar
or other formalisms in the FITs definitions but I see only
English text.  Being from a CS background this gives me the
creeps. :-)
-- 
Kevin
kevin.r.kuehl at att.com

---

From: kkuehl at ih4gp743.ih.att.com (Kevin Kuehl)
Date: Sun, 3 Dec 1995 23:26:44 GMT

In article <49nosb$t5u at post.gsfc.nasa.gov>,
>string with the quotes left off--many poorly designed FITS writers do this.

I don't think it can be interpreted as a character string.  I have
"Definition of the Flexible Image Transport System (FITS)" NOST 100-1.1
dated September 29, 1995 right here in front of me.  In section
5.3.2.1 Character String, it says

	If the value is a character string, column 11 shall contain
	a single quote (hexadecimal code 27, "'"); the string shall
	follow, starting in column 12, followed by a closing single
	quote (also hexadecimal 27) that should not occur before
	column 20 and must occur in or before column 80.

From this, I don't see how it could be properly interpreted as a
string.  While I am pretty new to FITS, the definition seems pretty
clearly written.
-- 
Kevin
kevin.r.kuehl at att.com

---

From: tferro at merlin.la.asu.edu (Anthony J. Ferro)
Date: 4 Dec 1995 15:20:32 GMT

Kevin Kuehl (kkuehl at ih4gp743.ih.att.com) wrote:
: I don't think it can be interpreted as a character string.  I have
: "Definition of the Flexible Image Transport System (FITS)" NOST 100-1.1
: dated September 29, 1995 right here in front of me.  In section
: 5.3.2.1 Character String, it says

: 	If the value is a character string, column 11 shall contain
: 	a single quote (hexadecimal code 27, "'"); the string shall
: 	follow, starting in column 12, followed by a closing single
: 	quote (also hexadecimal 27) that should not occur before
: 	column 20 and must occur in or before column 80.

: From this, I don't see how it could be properly interpreted as a
: string.  While I am pretty new to FITS, the definition seems pretty
: clearly written.
: -- 

	Name:  O'Malley

	NAME    = 'O''Malley '
	NAME    = 'O'Malley  '

---------

---

From: thompson at achilles.nascom.nasa.gov (William Thompson)
Date: 4 Dec 1995 20:48:41 GMT

In section 5.1.2.3 the standard also states

	Separation of the value and comments by a slash (hexadecimal 2F, "/"),
	and a space between the value and the slash are strongly recommended.

(Another example of the ambiguity that the standard allows.)  It was this that
I was bringing into the debate.  The standard would allow

to be interpreted as either a character string or as a value and a comment,
depending on whether you believe that the quotes or the / was left out, but I
don't consider it as clear as

	AMBIG0  =                    1/ 0 is more common

If the argument is that "once FITS, always FITS" doesn't allow us to get rid of
such ambiguities, then the answer is to use the deprecation mechanism already
applied to random groups.

Bill Thompson

---

From: davis at space.mit.edu (John E. Davis)
Date: 7 Dec 1995 17:34:14 GMT

On 4 Dec 1995 15:20:32 GMT, Anthony J. Ferro <tferro at merlin.la.asu.edu>
wrote:
 :  As I've read the standards there are two possibilities:
 : 
 : 	NAME    = 'O''Malley '
 : 	NAME    = 'O'Malley  '
 : 
 :  (Pardon if I misscount spaces, my point is the arrangment of "'".) 
 :  For me, the first is ambigious, since it could be:  Name:  O''Malley
 :  The second is not ambigious, since the ending quote must be at column
 :  20 or beyond.  Of course, I don't know how many FITS readers would
 :  agree with me.
 
If you want O''Malley, you have to use O''''Malley.  I believe that the fits
definition paper is quite clear on this (Section 5.3.2.1).  However, that
paragraph confuses me with the statement:

  ``Reading data files in a fits file should not require decoding any
    more than the first eight characters of a character string value of
    a keyword.''
    
What exactly does this mean?  My interpretation is that it implies that only
the first eight characters are meaningful.  I hope I am wrong about this
because with my interpretation this fits card:

RQFIL1  = './sisdata/s0c3p40e0/gau.s0.c3.g?.ecd' / 1st file  -- branching ratio

is worthless.

I suspect that the statement ``once fits, always fits'' really means ``once
a fits reader, always a fits reader''.

-- 
John E. Davis                   Center for Space Research/AXAF Science Center
617-258-8119                    MIT 37-662c, Cambridge, MA 02139

---

From: bschlesinger at nssdca.gsfc.nasa.gov (Barry M. Schlesinger)
Date: 5 Dec 1995 09:22 EDT

In article <49v3k0$edm at news.ccit.arizona.edu>, tferro at merlin.la.asu.edu (Anthony J. Ferro) writes...
> 20 or beyond.  Of course, I don't know how many FITS readers would

From the Definition of FITS (NOST), section 5.3.2.1 (Character String)

# A single quote is represented within a string as two successive 
# single quotes, e. g., O'HARA = {\tt 'O''HARA'}.

				Barry Schlesinger
				FITS Support Office
				GSFC/ADF

---

From: davis at space.mit.edu (John E. Davis)
Date: 7 Dec 1995 03:44:20 GMT

On Tue, 5 Dec 1995 13:08:55 GMT, Kevin Kuehl <kkuehl at ih4gp743.ih.att.com>
wrote:
 : >Yes, but in section 5.3.1 it states
 : >
 : >	The fixed format is required for values of mandatory keywords and
 : >	recommended for values of all others.
 : >	^^^^^^^^^^^
 [...]
 : I guess I skipped over that part because I couldn't believe
 : that it meant what you are saying.  I am not saying you are
 : wrong, I just couldn't believe that the standard said that
 : a FITS writer did not always have to adhere to the value
 : definitions.  How are readers supposed to read FITS files
 : if writers don't have to adhere to the standard?  Yuck!

I honestly believe that many people treat fits files as glorified binary
files where one already ``knows'' the format, e.g., 

   skip_header ();
   skip_header ();
   while (NOT END OF FILE)
     {
        skip_32_bytes ();
        read_4_bytes ();
	skip_32_bytes ();
	read_4_bytes ();
     }
     
Of course the ``reader'' needs modified when the format changes.
For this reason fits files that do not follow standard conventions for all
keywords are not uncommon.

To paraphrase Forest Gump,

 ``Fits is is like a box of chocolates-- 
    you never know what you're gonna get.''

---

From: kkuehl at ih4gp743.ih.att.com (Kevin Kuehl)
Date: Thu, 7 Dec 1995 15:34:20 GMT

In article <199512062106.QAA18781 at tetra.gsfc.nasa.gov>,
>perhaps for complex keywords as illustrated below).

Thanks for posting this.  You cleared up a lot of things that
were confusing me (it doesn't sound like I was the only one
either).  Here is the root of my confusion:

	Unless otherwise specified, the value field
	must be written in a notation consistent with the
	list-directed read operations in ANSI FORTRAN-77.
	The structure shall be determined by the type of
	the variable.  The fixed format is required for
	values of mandatory keywords and recommended for
	values of all others.  This standard imposes no
	requirements on case sensitivity of character
	strings other than those explicitly specified.

I understand now that "list-directed read operations" is
something different from the fixed format.  Part of the
problem may be is that you are now getting a whole generation
of people (of which I am part of) in this area who know
nothing about FORTRAN-77.  Saying it follows FORTRAN standards
means as much to me as saying the fields must be in EBCDIC.
The only thing I know about either is that they are part
of the history of computing. :-)

Luckily your post tells me what "list-directed read operations"
means so that I can understand it.  I still think a formal
grammar in the definition would help FITS' younger users
(as well as others it sounds like from the posts).
-- 
Kevin
kevin.r.kuehl at att.com

---

From: gene_heskett at wvlink.mpl.com (Gene Heskett)
Date: 11 Dec 1995 04:05:07 GMT

KK> In article <slrn4c3npg.n5.davis at wiwaxia.mit.edu>,
 KK> John E. Davis <davis at space.mit.edu> wrote:
>>I am more concerned about the informal nature of the NOST fits
>>definition. The descriptions should supplemented by something more formal
>>and the ambiguities that I described above should be resolved by the
>>standard.

 KK> I agree.  I am new to FITs and I expected to see some grammar
 KK> or other formalisms in the FITs definitions but I see only
 KK> English text.  Being from a CS background this gives me the
 KK> creeps. :-)
 KK> -- 
 KK> Kevin
 KK> kevin.r.kuehl at att.com

Have I not saw this name before, on a FalSoft Publishing (Rainbow) article?
We won't discuss how many years back up the log that was though.

/*            Gene Heskett          |  These opinions are NOT to be  */
/*  CE  at  WDTV Weston/Clarksburg WV  |  confused with the official    */
/*  <gene_heskett at wvlink.mpl.com>   |  WDTV managment views          */
#include <std.disclaimer>

---

From: davis at space.mit.edu (John E. Davis)
Date: 11 Dec 1995 19:25:57 GMT

On Thu, 7 Dec 1995 15:34:20 GMT, Kevin Kuehl <kkuehl at ih4gp743.ih.att.com>
wrote:
 : In article <199512062106.QAA18781 at tetra.gsfc.nasa.gov>,
 : William Pence  <pence at tetra.gsfc.nasa.gov> wrote:
 : >On the subject of FITS keyword 'ambiguities'  it might be of interest
 : >to give a short explaination of how the FITSIO software package
[...]
 : Thanks for posting this.  You cleared up a lot of things that
 
   I also appreciate William's explanation of how fitsio handles parsing
   keywords.
   
 : were confusing me (it doesn't sound like I was the only one
 : either).  Here is the root of my confusion:
 : 
 : 	Unless otherwise specified, the value field
 : 	must be written in a notation consistent with the
 : 	list-directed read operations in ANSI FORTRAN-77.
 : 	The structure shall be determined by the type of
 : 	the variable.  The fixed format is required for
 : 	values of mandatory keywords and recommended for
 : 	values of all others.  This standard imposes no
 : 	requirements on case sensitivity of character
 : 	strings other than those explicitly specified.

   On the one hand, I would like to see the NOST fits definition document
   present discussion of FITS cards that are consistent with FORTRAN
   list-directed read operations.  However, a large part of me does not want
   to see the discussion at all because it might encourage fits writers to
   use a format other than the fixed one.  It is probably too late but I
   would like to have the standard only endorse the fixed format for ALL
   keywords and change all occurances of ``strongly suggested'' to
   ``required''.

   The problem with the wording above is that I have come across several
   people who believe that the value-format of non-mandatory keywords is
   arbitrary.  This is why I originally posted the question about HEX values
   in the integer field-- the person who created such fits files believed it
   was fine because the HEX value was used with a non-mandatory keyword.
   None of the tools that he used complained about it (iraf) until
   some tool using my fitsio library encountered it.  While my library is
   forgiving with poorly formatted cards (generates warnings), it
   interpreted the HEX value as a boolean (the value was F0F0-- interpreted
   as FALSE with comment 0F0).

---

From: William Pence <pence at tetra.gsfc.nasa.gov>
Date: Fri, 15 Dec 1995 13:14:32 -0500

On 11 Dec 1995 19:25:57 GMT davis at space.mit.edu (John E. Davis) wrote:

>    (...)  This is why I originally posted the question about HEX values

There are only 2 possibilities for the interpretation of a FITS keyword like:

KEYNAME =                 F0F0

It is either an boolean false value, or it is a completely invalid FITS
keyword.  Personally, I believe it is correct to interpret this as a
boolean FALSE because list directed FORTRAN reads will interprete any
value beginning with the letter 'T' as a boolean true, and any value
beginning with the letter 'F' as a boolean false.  Other characters may
follow the initial T or F, but they do not take part in determining the
logical value.

Fortran also allows an optional decimal point to preceed the T or F,
and allows lower case t or f logical values, but I don't think this
added generality should be allowed in FITS keywords.  The FITS standard
is explicit about requiring an uppercase T or F for fixed format
logical values, so it seems resonable to also require this for free
format logical values.  The FITS Standard should be made clearer on
this point.

-Bill Pence