From dwells@fits.CX.NRAO.EDU Sun Apr 1 14:06:27 1990 Received: from NRAO.EDU (cv3.cv.nrao.edu) by fits.cx.nrao.edu (4.0/SMI-DDN) id AA13784; Sun, 1 Apr 90 14:06:25 EDT Received: from fits.cx.nrao.edu by NRAO.EDU (4.0/DCW-2o ) id AA14985; Sun, 1 Apr 90 14:06:15 EDT Received: by fits.cx.nrao.edu (4.0/SMI-DDN) id AA13769; Sun, 1 Apr 90 13:59:41 EDT Return-Path: Message-Id: <9004011759.AA13762@fits.cx.nrao.edu> Status: RO From: dwells@fits.CX.NRAO.EDU (Don Wells) Sender: dishfits-request@fits.CX.NRAO.EDU To: dwells@fits.CX.NRAO.EDU, fghigo@arcturus.GB.NRAO.EDU Cc: dishfits@fits.CX.NRAO.EDU Subject: FITS-Tables-for-spectra Date: Sun, 1 Apr 90 13:59:37 EDT Dear Frank, In your message to me [Date: Mon, 26 Mar 90 11:26:14 EST, From: ( FRANK GHIGO ) fghigo@arcturus.GB.NRAO.EDU, To: dwells@fits.CX.NRAO.EDU] you ask "...the question is, aside from the column(s) that contains a matrix, can one put groups of numbers into other columns? This would be convenient in several cases, for example, the "descriptive origin" could be in a single column with a format of 3E, the LO synthsizer settings would be 6E. But is this sort of thing allowed by the single dish agreement? (If it is required that all table rows can be unpacked to classical FITS form, then a table column (except for the matrix) becomes the value of a keyword, which can, at most, be a complex item.)" I am CC-ing my reply to DISHFITS because I believe that this is a question of general interest. The basic question raised here has a long history in the FITS community, and opinions have always differed on it. At the time of the Basic FITS Agreement (March 1979) Eric and I agreed to allow for the multi-valued possibility by defining value fields to be in FTN-77 list-directed format, which defines a free-field syntax for lists of elements. The design reviewers (April-May 1979) criticized this as dangerously complicated and so the 1981 paper recommends a more rigid style in practice, with semi-fixed columns and only one value per header card, but it still permits the more powerful syntax in case we ever need it. My own perception is that nobody has made a compelling case for multi-valued fields during the past eleven years, and I won't recommend such usage myself until I hear such the case made convincingly. The question arose again during the 1-Nov-90 Green Bank meeting and was repeatedly addressed in various ways. My suggestion that *sets* of Basic-FITS files be encoded as 3-D-tables carried the implicit implication that the keyword fields will be single-valued. So, the literal answer to your question is that multiple LOs should be multiple keywords, or else that they should be encoded in a character string value for a proprietary keyword. But that cannot be the ultimate answer, because people keep raising the question year after year. It seems to me that there is not yet a consensus on the general design question you are raising, a question independent of the answer that applies to FITS as it now is. Some people, me included, believe that multi-valued keywords in this context would violate normalization rules for design of relational databases. I don't consider this claim, which I regard as still unproven even though I myself believe it, as binding on us as designers; rather I regard it as a cause for caution. I suggest that it will be best for us to try very hard to cast all problems as single-valued keywords, and add the additional layer of complexity only when we are forced into it. Regards, Don Donald C. Wells, Associate Scientist | NSFnet: dwells@nrao.edu [192.33.115.2] National Radio Astronomy Observatory | SPAN: NRAO::DWELLS [6654::] Edgemont Road | BITnet: DWELLS@NRAO Charlottesville, VA 22903-2475 USA | UUCP: ...!uunet!nrao.edu!dwells Lat: 38:02.2N Long: 78:31.1W | Tel:+1-804-296-0277 Fax:+1-804-296-0278 From dwells@fits.CX.NRAO.EDU Sat Apr 21 14:54:06 1990 Received: from cv3.cv.nrao.edu by fits.cx.nrao.edu (4.0/SMI-DDN) id AA15712; Sat, 21 Apr 90 14:54:03 EDT Received: from fits.cx.nrao.edu by cv3.cv.nrao.edu (4.0/DDN-DLB/1.9) id AA18800; Sat, 21 Apr 90 14:53:17 EDT Received: by fits.cx.nrao.edu (4.0/SMI-DDN) id AA15668; Sat, 21 Apr 90 14:45:17 EDT Return-Path: Message-Id: <9004211845.AA15662@fits.cx.nrao.edu> Status: R From: dwells@fits.CX.NRAO.EDU (Don Wells) Sender: dishfits-request@fits.CX.NRAO.EDU To: dishfits@fits.CX.NRAO.EDU Subject: Word-Alignment Question Date: Sat, 21 Apr 90 14:45:14 EDT Frank Ghigo asks [From fghigo@arcturus.GB.NRAO.EDU Wed Apr 4 13:40:04 1990 To: dwells@fits.CX.NRAO.EDU Subject: more FITS queries]: "Here is another question: are IEEE reals and doubles required to be aligned on 4-byte boundaries within a FITS binary table? or are there any alignment rules for these numbers? I am under the impression that there is no such requirement, but this point does not seem to be mentioned in any of the official FITS writeups I've seen." I am sending Frank's query and my answer to DISHFITS because it falls into the "most frequently asked questions" category. The answer is *no*, R*4 and R*8 values are not to be aligned modulo 4 or 8. Indeed, Bill Cotton specifies that the data from successive columns in a row should be one contiguous stream, and he even explicitly says (in the draft of the 3-D tables paper, which I am currently reviewing) that "NAXIS1 (integer) is the number of 8 bit bytes in each 'row'. This should correspond to the sum of the values defined in the TFORMnnn keywords." -Don