|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[fitsbits] Blank strings in FITS keywords.
Here's a little FITS lawyer nit.
Section 5.2.1 of the FITS standards document notes that KEYWORD1= '' is distinct from KEYWORD1= ' ' However I am unclear as to whether either of these are distinct from KEYWORD1= ' ' (where there are at least 8 blanks between the quotes). The first two examples clearly use the free format for the headers, but the third example could be in the fixed format. Since a fixed format line cannot have fewer than 8 characters in a character string header value, a sequence of 8 blanks is the only way to specify these strings in the format that that standard recommends people use. Since one is allowed to intermix free and fixed format cards in the header there is no context that can tell you which format the card is in. So it looks like Example 1 EQV example 3 Example 2 EQV example 3 but Example 1 NOT EQV example 2. Is this true? If so I think this may be the only example where this is the case and seems a little inelegant to me. Probably too late to change but it might have been better to have the first two examples equivalent too. Not a big issue, but it actually has come up in practice! Regards, Tom McGlynn |
#2
|
|||
|
|||
Tom McGlynn wrote:
Here's a little FITS lawyer nit. Section 5.2.1 of the FITS standards document notes that KEYWORD1= '' is distinct from KEYWORD1= ' ' However I am unclear as to whether either of these are distinct from KEYWORD1= ' ' (where there are at least 8 blanks between the quotes). The first two examples clearly use the free format for the headers, but the third example could be in the fixed format. Since a fixed format line cannot have fewer than 8 characters in a character string header value, a sequence of 8 blanks is the only way to specify these strings in the format that that standard recommends people use. Since one is allowed to intermix free and fixed format cards in the header there is no context that can tell you which format the card is in. So it looks like Example 1 EQV example 3 Example 2 EQV example 3 but Example 1 NOT EQV example 2. Is this true? If so I think this may be the only example where this is the case and seems a little inelegant to me. Probably too late to change but it might have been better to have the first two examples equivalent too. Not a big issue, but it actually has come up in practice! Regards, Tom McGlynn Trailing blanks are not significant: KEYWORD1= '' / null string KEYWORD1= ' ' / value is a single blank KEYWORD1= ' ' / value is a single blank KEYWORD1= ' ' /value is a single blank Pete. |
#3
|
|||
|
|||
Peter Bunclark wrote:
Tom McGlynn wrote: Here's a little FITS lawyer nit. Section 5.2.1 of the FITS standards document notes that KEYWORD1= '' is distinct from KEYWORD1= ' ' However I am unclear as to whether either of these are distinct from KEYWORD1= ' ' (where there are at least 8 blanks between the quotes). The first two examples clearly use the free format for the headers, but the third example could be in the fixed format. Since a fixed format line cannot have fewer than 8 characters in a character string header value, a sequence of 8 blanks is the only way to specify these strings in the format that that standard recommends people use. Since one is allowed to intermix free and fixed format cards in the header there is no context that can tell you which format the card is in. So it looks like Example 1 EQV example 3 Example 2 EQV example 3 but Example 1 NOT EQV example 2. Is this true? If so I think this may be the only example where this is the case and seems a little inelegant to me. Probably too late to change but it might have been better to have the first two examples equivalent too. Not a big issue, but it actually has come up in practice! Regards, Tom McGlynn Trailing blanks are not significant: KEYWORD1= '' / null string KEYWORD1= ' ' / value is a single blank KEYWORD1= ' ' / value is a single blank KEYWORD1= ' ' /value is a single blank Pete. The problem is that since the first FITS paper (and still in the standard), the fixed format is recommended for header cards. In the fixed format there must be at least 8 characters in a character value. Reading that paper if I wished to specify a string with the value of '' in the fixed format I believe I would have written it as ABCDEFGH= ' ' and felt that I was following the recommendations of the standard. If that is not the case, then I'd regard this as a minor violation of the once FITS, always FITS rule. If we were to follow that rule strictly, then imho a header value of at least 8 blanks is indeterminate as to whether it represents a single blank or a zero length string. In either case an explicit statement in the of this would be appropriate if the standard is ever revised. Either there is a value that cannot be represented in the recommended format (which implies that a null string value cannot ever be used for a mandatory keyword) or there is a peculiar ambiguity in the meaning of blank strings. Regards, Tom P.S., my own feeling is that the ability to represent a single blank but not, say, two blanks is not really such a big deal, and it might have been better for all four of the examples above to be the same, but that's not a feasible outcome today. |
#4
|
|||
|
|||
Thomas McGlynn wrote:
The problem is that since the first FITS paper (and still in the standard), the fixed format is recommended for header cards. In the fixed format there must be at least 8 characters in a character value. Reading that paper if I wished to specify a string with the value of '' in the fixed format I believe I would have written it as ABCDEFGH= ' ' and felt that I was following the recommendations of the standard. I second this statement. In fact, the FITS-writing software that I use enforces the fixed format, so that it would be impossible to write a null string separate from a blank string, e.g. IDL fxhmake,h IDL fxaddpar,h,'abcdefg','' IDL hprint,h SIMPLE = T /Written by IDL: Tue Mar 1 11:10:43 2005 BITPIX = 8 / NAXIS = 0 / ABCDEFG = ' ' / END William Thompson |
#5
|
|||
|
|||
William Thompson wrote:
Thomas McGlynn wrote: The problem is that since the first FITS paper (and still in the standard), the fixed format is recommended for header cards. In the fixed format there must be at least 8 characters in a character value. Reading that paper if I wished to specify a string with the value of '' in the fixed format I believe I would have written it as ABCDEFGH= ' ' and felt that I was following the recommendations of the standard. I second this statement. In fact, the FITS-writing software that I use enforces the fixed format, so that it would be impossible to write a null string separate from a blank string, e.g. yes, but ... I think that's an entirely different question. Some of our older data reduction software takes offense to character strings containing nulls, but I consider that beside the point here as well. I thought the question was whether '' _is_ a null string or a blank string and I also think that '' should be a null string, independent of whether we (can) write it or read it, not blank. We have one case where we would have liked to write a null string, found that we couldn't do that, and settled on 'none ' (probably for the better of everybody who reads our data). IDL fxhmake,h IDL fxaddpar,h,'abcdefg','' IDL hprint,h SIMPLE = T /Written by IDL: Tue Mar 1 11:10:43 2005 BITPIX = 8 / NAXIS = 0 / ABCDEFG = ' ' / END Aloha, Maren Purves, UKIRT. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Life and The Universe | lifehealer | History | 8 | February 2nd 04 08:36 PM |
[fitsbits] BLANK keyword misinterpretation | Steve Allen | FITS | 4 | November 21st 03 04:42 PM |