Subject: Yet another unsigned integers proposal

From: kent at steve.fnal.gov
Date: 14 Mar 1994 15:49:54 GMT

The Sloan Digital Sky Survey (SDSS) project will generate of order 10 terabytes 
of raw data and 200 gigabytes of reduced data over a period of 5 years.
As computing coordinator for the survey, one of my responsiblities is to
specify the formats for the various types of data that will be collected.
As you can imagine, it is important to do this job properly at the beginning.
These formats will be used not only for internal purposes but also for
the distribution of data to the external community.
Our project was strongly advised to use FITS wherever possible, and we have
been assidiously pursuing that track.

We will use use a combination of basic FITS images, Ascii tables, and binary
tables to store and exchange a variety of raw and processed data.
Our raw data will all be - yes - 16 bit unsigned integers.
We are therefore faced with the same dilemma as Arnold Rots described in
a recent posting, and we have come to the same conclusion - it is very
desirable that the FITS standard provide explicit support for unsigned
data types, and the place to do so is in binary tables.  In spite of the
recent thread arguing that FITS currently handles unsigned types properly
(flip the high order bit and set TSCAL=1, TZERO = 32768),
we have, in fact, found that this is not at all the case.
At present we are faced with writing all of our FITS files with SIMPLE = F
in order that we can adopt some nonstandard conventions to deal with the
inadequacies.  This is highly unsatisfactory.

The first problem we face is one of hard economics - we will be collecting
data at the rate of 7 Mbytes per second, and the current data acquisition
system will not handle the extra compute steps for even a simple bit
flip.  We are not about to spend the several thousand dollars needed
to add the extra compute muscle for this meaningless task.  At present
we will write the raw data as FITS images with the unsupported BITPIX=-16
convention and SIMPLE = F.

The second (and more serious) problem arose when we tried to write
a general purpose reader and writer for FITS images and tables that
translates the data into their most "natural" format - what is the exact
meaning to be applied to data values in the primary array or in tables?
The FITS standard, unfortunately, blurs the distinction between the physical
value that one wants to represent and the FITS table representation of that
value, particularly when scaling is involved.  The FITS standard seems to
imply that a physical value is a pure number plus
physical dimensions, with no connotation of int, float, or signed attached
nor any specific binary representation.  While this connotation might be
adequate for describing data in the primary array (which ought to be IMAGE
data), it is not necessarily appropriate for data in tables (e.g., a table
entry that contains an integer flag to represent a quality code).  Furthermore,
while the standard does define the native data types of a SIMPLE machine in
exquisite detail, it is unclear what, if any, SIMPLE machine representation
is implied when the BSCALE and BZERO (or TSCAL and TZERO for tables) keywords
are present.  The definitions of BSCALE and BZERO (Section 5.2.2.5 of
the NOST standard) imply that, if anything, after scaling, the result is to
be interpreted as a "floating point" number.  The standard does not specify
the exact bit pattern that results after scaling - presumably a FITS reader
must be prepared to deal with an infinite precision floating point number or
with floating point numbers with exponents that are beyond the range of their
IEEE representation. Although it is stated in the draft binary table extension
standard (and has been echoed many times in various supporting documentation
for FITS) that unsigned 16 bit integers may be represented by using signed 16
bit integers and setting BSCALE=1, BZERO=32768, this is not really what the main
standard says. At best, one can say that the use of BSCALE = 1 and BZERO =
32768 results in a floating point number that can, if the user desires, be
represented internally as a 16 bit unsigned integer, but one should not
assume that the scaled FITS data value has that meaning attached.

We will have situations where greater precision of meaning is
needed - i.e., we want to make it clear that a particular item has a
specific type and value.  It would seem that binary tables ought to be able
to do this.  Although unsigned types are not native to most Fortrans,
they are native to ANSI C compilers (and indeed much of the SDSS software
is being written in C, in part because of the support for unsigned data types).
We will also have need for a variable length storage mechanism - a typical
purpose will be to store cutout images of objects detected in the survey, which
vary in size for each object, with the object parameters stored in the main
table.  The heap facility that is proposed for binary tables serves our
needs well but again with one exception - unsigned types are not supported in
heap storage (one cannot even apply TSCAL and TZERO to heap data).

Having ranted and raved for so long, I should at least make a specific
proposal.

IN THE MAIN STANDARD:

1. The definition of "physical value" should
   be clarified (is it is a pure number with dimensions attached?).
   The definition and use of "floating point" should be clarified, since
   it is used to mean both the IEEE format and the ASCII format, which are not
   uniquely related.

2. The exact meaning of scaling with BSCALE and BZERO be clarified.  Does it
   imply that an exact bit pattern should result?

3. In the definitions of BSCALE and BZERO, the statements that values of
   1. and 0. are implied if the keywords are not present should be omitted.
   [The reason for omitting them is that scaling implies a type conversion,
   which may not be the desired effect].

4. In chapter 6 of the main standard, which defines the "official" data types,
   the statement that only these types may appear in both the primary array
   and extension tables should be changed to omit the reference on extension
   tables.  (As it now stands, it would appear that the "X"
   and "L" data types in binary tables already violate this chapter).

IN THE DRAFT BINARY TABLE STANDARD:

1. The goal of binary tables is to provide for the interchange of binary data.
   Each datum has a unique binary representation and a type.  All "commonly
   used" data types are supported, including:

   (L) 8 bit Boolean T or F
   (A) 8 bit ASCII characters
   (I) 16 bit signed integers
   (U) 16 bit unsigned integers
   (J) 32 bit signed integers
   (V) 32 bit unsigned integers
   (E) 32 bit IEEE floating point numbers
   (K) 64 bit signed integers
   (W) 64 bit unsigned integers
   (D) 64 bit IEEE floating point numbers
   (X) A byte string of arbitrary length of undefined type (e.g., a bit mask).

   where the letter in parenthesis is the TFORM value (I have revised Rots'
   suggested designations for unsigned integers - sorry about that).

3. The presence of TSCAL and TZERO implies that the table data value is
   to be scaled and interpreted as a numerical value of data type float with
   no bit pattern implied.  Their use is deprecated if the desired
   result is a unique binary representation and/or type.

Are these proposals sensible? Radical?  Do we have to invent yet another
extension table type?  How "Flexible" is FITS?

Steve Kent

---

From: sla at umbra.UCSC.EDU (Steve Allen)
Date: 15 Mar 1994 17:55:35 GMT

In article <2m4pup$js7 at paperboy.gsfc.nasa.gov>,
Robert Hill <bhill at trifle.gsfc.nasa.gov> wrote:
>kent at steve.fnal.gov writes:
>Actually, this is not quite right, I think.  You don't `flip' the
>high order bit, you just treat it as a data bit.

No, you simply flip the high order bit and insert BSCALE and BZERO cards
into the header.  That is all.  If your machine can actually add or
subtract faster than it can flip a bit; good, then do that!

This same subject has occurred in the Keck data acquisition system.
The ADCs produce 16-bit unsigned numbers which are all shoved through
a DSP on their way to the permanent storage device.  With the DSP
the processing required to flip the high bit would mean one more
operation on the data while they are in the DSP.  The end result is that
the first processed bits would come out a few microseconds later, but
the overall throughput need not be affected.

The complication for Keck arises further down the software chain because
all successive software, specifically the image preview, must understand
that the data are unsigned.  This requires systems integration between
geographically distinct parallel development teams.

--  --  --  --  --  -+-   --  --  --  --  --  --  --  -+-  --  --  --  --  --
Steve Allen          | "Shameless Morris Enthusiasm"   |   sla at lick.ucsc.edu
UCO/Lick Observatory | Yep, that's me.  6 up for       |   +1 408 459 3046
Santa Cruz, CA 95064 | Orange in Bloom, Sherborne, eh? |   Seabright Morris

---

From: bhill at trifle.gsfc.nasa.gov (Robert Hill)
Date: 15 Mar 1994 17:06:33 GMT

>of raw data and 200 gigabytes of reduced data over a period of 5 years.
[...]

Actually, this is not quite right, I think.  You don't `flip' the
high order bit, you just treat it as a data bit.  A typical easy
way to do this upon writing is to stuff the two bytes into the
low-order locations within a zeroed-out four-byte word.  Then you
subtract 32768 (in four-byte arithmetic) and write out the
low-order two bytes.  The range 0..65535 is mapped directly into
the range -32768..32767.

[...]
>flip.

Are you using off-the-shelf hardware interfaces with canned
software, or do you have custom hardware interfaces with at least
the inner acquisition routines written by your project in
assembler?  Your comments made me idly curious about your
situation.  In any case, with a conservative hardware scenario,
e.g. a 25 MHz PC massaging the incoming data, I can see the
conversion costing from 1/2 to 1 second per 7 Mbyte chunk, so yes,
you might have a problem trying to do the conversion at that
stage.

[...]
>value, particularly when scaling is involved.
[...]

Actually, I interpret your question in a less philosophical way.
What you want is for your project internal data files to also be
exportable.  That's fine, we do that too, and many projects these
days seem to take the same approach.  You can assure bit-by-bit
recoverability for internal uses by forcing your own reading
software to do the conversion y=1*x+32768 in integer arithmetic.
The question is whether you really need to assure bit-by-bit
recoverability for the export user -- in effect, whether you 
really need the capability of forcing the user to read the files
in the same way you would.  E.g., for most people, what's wrong
with reading 16 bits into a 32-bit f.p. number with a 24-bit
mantissa?  Eight extra bits!

I'm open minded about this proposal, not convinced either way as
yet, and would like to see more discussion.  Instrumentally
oriented people (I'm one of them) have a tendency to say, `These
are the bits we got, so they are the bits you're going to get.'
If your instrumental format happens to be the same as one of the
FITS representations, you get to have things both ways -- you can
supply a physical calibration in BSCALE and BZERO.  Many FITS
readers allow the user, as an option, to read the FITS data array
into a memory array of exactly the same type with no conversion.
Thus bit-by-bit recoverability is a _de facto_ feature of FITS for
many of us already, for certain data types.  (Leaving aside the
fact that it is an implicit feature of ASCII and of X-type bit
fields in BINTABLEs.)  Should this capability be given some kind
of official status?  If so, then the FITS community is pretty much
obligated to try to support the most common instrumental formats
as FITS data representations.

Bob Hill

--
Robert.S.Hill at gsfc.nasa.gov
Not speaking for any of the following:
Hughes STX Corp., Code 681, NASA/GSFC, Greenbelt, MD 20771
"Don't agree with me until I'm finished talking!" -- Darryl F. Zanuck

---

From: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Tue, 15 Mar 94 19:29:54 EST

To follow up on Steve Kent's (14 March 1994) proposals for
adding support for additional data types within FITS, I would make
the following specific proposals:

1. Use BITPIX = -16 to represent unsigned 16-bit integers in primary
   arrays and IMAGE extensions.   The SIMPLE keyword would need to
   be set = F until this convention is officially recognized. 
   I think various groups have suggested and used this convention in the
   past, so approving this will simply legalize what is already common practice. 

2. In binary tables, add the following new data types:

    (H)  8 bit signed integers
    (U) 16 bit unsigned integers
    (V) 32 bit unsigned integers

    Existing FITS readers will of course not understand these data types,
    and thus will be unable to parse the binary table at all until 
    they are rewritten because they will not know how many bytes wide
    these columns are.  To ease the transition, the following
    interium convention should be used until such time as these (H,U and V)
    data types are officially approved by the FITS committies.

3.  As an interium solution, the following convention should be used
    to represent the new types of integers in binary tables:

    TFORMn = 'B:SIGNED'     / this is a signed byte column
    TFORMn = 'I:UNSIGNED'   / this is an 16 bit unsigned integer column
    TFORMn = 'J:UNSIGNED'   / this is an 32-bit unsigned integer column

    The use of this convention should be deprecated once the H, U and V
    datatypes are approved.

    Note that this convention is entirely consistent with the current
    binary table definition document which allows any additional characters
    to follow the main datatype character (B, I or J in this case).  The
    use of the ':' is consistent with usage in the 'Substring Array' 
    convention in Appendix C of the Binary Table definition document.  Unlike
    the case with the previous proposal (for using H, U and V to represent
    these datatypes) existing FITS readers will still be able to
    read the data in the table, although the reader may incorrectly
    interpret the values.  FITS files using this convention would need
    to have SIMPLE = F
 
Steve Kent also proposed supporting 64 bit signed and unsigned integers
but I would hesitate to support this simply on the grounds that I don't
know how to generate or read 64 bit integers on machines that don't
support this as a native datatype.  If someone could provide a robust
set of routines for converting between 64-bit integers and other
data types (e.g., 64-bit floats) then I might reconsider this.

These proposals do not allow for 32-bit unsigned or 8-bit signed primary
arrays, but I don't think the current need for these formats is very great.  

-Bill Pence

---

From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER)
Date: 16 Mar 1994 10:54 EDT

In article <2m2132$k78 at fnnews.fnal.gov>, kent at steve.fnal.gov writes...

> ... 
> Our project was strongly advised to use FITS wherever possible...
> Our raw data will all be - yes - 16 bit unsigned integers...

> ... the current data acquisition

Translating data from a form immediately readable only at the
originating location to a standard form easily read elsewhere is not
meaningless. 

In the original FITS paper, Wells, Greisen and Harten (1981, Astron. 
Astrophys. Suppl. 44,363) write

"The usage of SIMPLE=F may be used for data storage or interchange 
 within an institution or between users with similar interests and 
 computers in those cases in which convenience overwhelms the need for 
 standardization, but in which the outward form of this standard is 
 still convenient to implement.  We do not want to encourage any such 
 departures from the basic FITS standard...."

I interpret the intent to be that if a data set is going to be part of 
a general distributional archive, it should not include data with 
SIMPLE=F; that usage is for individual institutions or a relatively
small common interest group.  Discouraging SIMPLE=F arises from the
fundamental purpose of standardization -- avoiding the need to develop
new software each time a data set is received from a different
location.  While writing with a local format may cut costs at the
originating installation, the requirement for receiving locations to
write their own software will result in a greater total cost to the
community.  

One approach that might be proposed would be to incorporate the
proposed new format in some way in a new extension type, with a
registered name, and distribute a detailed proposal. Those aspects of
the data that do not use unsigned integers can be isolated and read by
a standard FITS reader.  And the new effort can be restricted to
development of routines to read the new extensions, which could be
distributed. But the purpose would not be to develop a special format 
for this one data set, but to start the process of extending the FITS 
standard.

> ... what is the exact
> The FITS standard seems to
> nor any specific binary representation.... 
> The definitions of BSCALE and BZERO (Section 5.2.2.5 of
> the exact bit pattern that results after scaling 

FITS specifies the bit pattern for data transport.  It provides
information to the reader to determine whether the data before scaling
are to be interpreted as integers (countable, discrete values), real
(uncountable, continuous values), or text.  There is no specification
as to the bit pattern the reading software uses to store the data from
the FITS file in its home machine *even before scaling*. That will
depend on such issues as to whether the machine is most significant
bit first or last,  ones- or twos-complement, ASCII or EBCDIC. 

A physical value is a number plus its units.  The units tell whether
the value is inherently integer (number of counts), or real (Hertz).
(The NOST document uses the term "floating point" rather than "real"
because of possible confusion between real vs. imaginary and real vs.
integer.) The interpretation is independent of whether or not the
value is stored in a computer somewhere. 

> - presumably a FITS reader
> IEEE representation. 

Using scaling with IEEE floating point is not recommended, precisely 
because of the danger of overflows.  The User's Guide discusses the 
overflow problem specifically.  Use of scaling does not rule out the 
possibility that the physical value is to be interpreted as an 
integer.

Now, one potential problem here is in scaling from one number intended 
as an integer to another intended as an integer using a scale factor 
defined as floating point; round-off may introduce an error.  This 
question needs to be discussed.

> Although it is stated in the draft binary table extension

That's because this particular method of representing unsigned 16-bit 
integers is the one that is most widely recommended in the community 
consistent with the rules of FITS.  It is not required; therefore, it 
is not part of the current standard. 

> to do this.  

The TDISPn keywords of binary tables can be used to signify whether a 
table entry is to be considered an integer or a real number, and, if 
real, the number of significant digits.

> ...We will also have need for a variable length storage mechanism - a typical
> heap storage (one cannot even apply TSCAL and TZERO to heap data)....

Not being able to scale heap values is a problem and probably an 
oversight.  One possible proposal would be to change the rule to allow 
the use of TSCALn and TZEROn in fields with P data types, with the 
understanding that the scaling is to be applied to the heap data.

>    it is used to mean both the IEEE format and the ASCII format, which are not

The definitions should probably be discussed by the technical panel 
that revises the NOST standard to incorporate BINTABLE, IMAGE, and 
blocking. 

>    imply that an exact bit pattern should result?

No. See above.  FITS does not specify the bit patterns resulting from 
scaling.

>    which may not be the desired effect].

Scaling does not imply conversion.

>    and "L" data types in binary tables already violate this chapter).

The requirement originated in the paper on generalized extensions.  
But the above question about X and L data types makes a good point.

> 1. ....  All "commonly
>		...
>		...	
>		... 

The community must reach consensus on whether these new types are 
desirable. 

>    result is a unique binary representation and/or type.

Scaling does not imply that the data value is to be interpreted as 
real.  FITS does not specify the binary representation of data once it 
leaves the FITS file. It specifies the way the data are to be 
interpreted, but scaling does not imply a floating point 
interpretation of the scaled values. 

				Barry Schlesinger
				NOST FITS Support Office

---

From: bhill at trifle.gsfc.nasa.gov (Robert Hill)
Date: 16 Mar 1994 16:23:20 GMT

sla at umbra.UCSC.EDU (Steve Allen) writes:
>into the header.  That is all.

By golly, you're right.  Thanks for the lesson.

Bob Hill

---

From: Tom McGlynn <MCGLYNN at grovx1.gsfc.nasa.gov>
Date: Wed, 16 Mar 94 14:06:03 EST

Forwarded from the fitsbits-request alias. -Don
------- start of forwarded message (RFC 934) -------
Message-Id: <940316134907.29200784 at grovx1.gsfc.nasa.gov>
From: Tom McGlynn <MCGLYNN at grovx1.gsfc.nasa.gov>
To: fitsbits-request at fits.CV.NRAO.EDU
Subject: Re: Yet another unsigned integers proposal
Date: Wed, 16 Mar 1994 13:49:07 -0500 (EST)

With regard to the unsigned int/scaling controversy, I've just done a
few simple benchmarks on my DEC 5000/200.  On my machine (and I would
suspect on many others), the scaling is a simple subtraction, underflows
just wrap around.

****************************************************
	Rate of scaling unsigned I*2's in megabytes/s.

Using IDL:		1.8
Unoptimized C:		1.6
Optimized C (-O4):     10.2

I put a few checks in the loops and generally converted blocks of 10K-20K 
bytes.  I also looked at the assembly code to ensure that the basic
loops didn't get optimized out in the optimized C version.

I don't believe this represents the best one can do if one is really
pressed but already it seems clear that the time required to perform
the conversions will be small compared to do I/O.  I've never gotten
more than 500K bytes/sec I/O rates in real applications.  In practice
we'd be converting smaller chunks which would take longer but this will
be balanced by the fact that not everything is getting converted and
one can probably use tricks to speed things up.

At the 10 Mb/s rate it will take only 200 s per day to handle XTE
data assuming that all data is transformed -- and this is by no
means on state of the art computers.

I think Bill's argument that it's hard to know which data to convert
is specious.  If we know enough to write out the FITS header with
appropriate keyword values to describe which words are going to be
unsigned, then obviously we know which words are going to be unsigned.
Just as FITSIO uses similar information to handle host to IEEE conversions
when writing FITS files, software can use user supplied keywords to
automagically perform the byte scaling.   I would be surprised if we
could not add such a capability within FITSIO itself without violating
the current FITS standards. 

All this puts me in the camp of those who feel that the case for 
incorporating unsigned int's is not demonstrated.

		Tom McGlynn
		Compton Observatory Science Support Center
------- end -------

---

From: dwells at nrao.edu (Don Wells)
Date: Wed, 16 Mar 1994 20:46:46 GMT

In article <2m7bpo$a4v at paperboy.gsfc.nasa.gov>
    bhill at trifle.gsfc.nasa.gov (Robert Hill) writes: ...
 RH> In article <2m4pup$js7 at paperboy.gsfc.nasa.gov>,
         sla at umbra.UCSC.EDU (Steve Allen) writes:
         SA> No, you simply flip the high order bit and insert BSCALE and
         SA> BZERO cards into the header.  That is all.
 RH> By golly, you're right.  Thanks for the lesson.

The bit pattern to be used is 8000-hex. 
In 16-bit unsigned it is 32768 (8*4096). 
In 16-bit 2-s complement it is both +32768 *and* -32768. 
The conversion can be produced by *three* different machine opcodes:

XOR 8000   (exclusive-OR to flip the high bit)
SUB 8000   (subtract +32768)
ADD 8000   (add      -32768)

Tutorial for newcomers: 

In 2-s complement arithmetic you negate a number by complementing the
bit pattern and adding one; the complement of 8000 is 7fff and adding
1 generates a carry and you are back to 8000.  In 2-s complement
arithmetic you throw away carries on addition.  If your unsigned
number is 32769=8001, and you use the SUB (subtract) opcode, the
hardware subtracts 8000=32768 by complementing to get 7fff, adding 1
to get 8000, and then adding that to 8001 to get 0001 (the value to
put in the FITS file), after the carry (10000) is discarded. The ADD
and XOR opcodes produce the same result as the SUB opcode. Another
example is 0001 unsigned, which becomes 8001=-32767 (+32767=7fff,
negation is 8000+1) after conversion.

Note that the exact same set of three operators are used to perform
the reverse conversion from 2-s complement 16-bit signed to 16-bit
unsigned. The two examples cited in the previous paragraph were chosen
to demonstrate this invertibility property of the conversion operation.

Historical note about arithmetic:

The first FITS tape passed in interchange in May 1979 was processed by
a CDC 6400, a 60-bit *ONES-COMPLEMENT* computer. In the 1-s complement
arithmetic system you negate by complementing the bits, and when
adding you add carries from the most significant bit back into the
least significant bit (often called "end-around" carry). During the
early days of FITS a major challenge for people writing and reading
FITS files on various machines was to understand how to interchange
between 1-s complement and 2-s complement architectures. Mercifully,
almost all of the 1-s complement machines have gone off to computer
Valhalla.  FITS itself was carefully defined to use 2-s complement.

I am intrigued by the fact that each number system has a number whose
negation is arithmetically equal to itself. In the 1-s complement
system the number is zero ((+0)==(-0) in C-speak), while in 2-s
complement it is 32768 ((+32768)==(-32768)).
--
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
                    http://fits.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA

---

From: nicinski at fncasefnal.fnal.gov (Tom Nicinski)
Date: 18 Mar 1994 15:50:01 GMT

I am also a big supporter of a richer environment -- in particular, supporting
additional primitive data types that are quite "natural" and common.  In this,
thread, that means unsigned integers and signed 8-bit integers.  Thus, I agree
with Steve Kent's proposal.  I also have some comments on William Pence's post.

pence at tetra.gsfc.nasa.gov (William Pence) writes:

[deleted ...]

|> 1. Use BITPIX = -16 to represent unsigned 16-bit integers in primary
|>    arrays and IMAGE extensions.   The SIMPLE keyword would need to
|>    be set = F until this convention is officially recognized. 
|>    I think various groups have suggested and used this convention in the
|>    past, so approving this will simply legalize what is already common practice. 

	Although I do not have any suggestions, this convention will only confuse
	the standard.  There are two problems: 1) negative BITPIX values indicate
	floating point values and 2) how do you handle 32-bit or 64-bit or n-bit
	integers.

|> 2. In binary tables, add the following new data types:
|> 
|>     (H)  8 bit signed integers

	I chose W for 8-bit signed integers for my Binary Table reader.

[deleted ...]

|> 3.  As an interium solution, the following convention should be used
|>     to represent the new types of integers in binary tables:
|> 
|>     TFORMn = 'B:SIGNED'     / this is a signed byte column
|>     TFORMn = 'I:UNSIGNED'   / this is an 16 bit unsigned integer column
|>     TFORMn = 'J:UNSIGNED'   / this is an 32-bit unsigned integer column
!> 
|>     The use of this convention should be deprecated once the H, U and V
|>     datatypes are approved.

	I have an aversion to interim proposals, since they kind of become
	standard.  If you're willing to use SIMPLE=F, then using proposal
	point 2. (above) might as well be used from the start.

[deleted ...]

|> Steve Kent also proposed supporting 64 bit signed and unsigned integers
|> but I would hesitate to support this simply on the grounds that I don't
|> know how to generate or read 64 bit integers on machines that don't
|> support this as a native datatype.  If someone could provide a robust
|> set of routines for converting between 64-bit integers and other
|> data types (e.g., 64-bit floats) then I might reconsider this.
|> 
|> These proposals do not allow for 32-bit unsigned or 8-bit signed primary
|> arrays, but I don't think the current need for these formats is very great.

	These last two paragraphs highlight what I see as a severe problem with
	the how people think about FITS.  Rather than trying to provide a richer
	and consistent environment, peoples' own needs are applied to the stan-
	dard.  Why don't people forsee the need for 8-bit signed primary arrays?
	Maybe your application doesn't need them, but someone else's might.

	Why argue against 64-bit integers?  If your platform doesn't like them,
	that should not preclude their inclusion in the standard.  You might
	argue then that the Binary Table complex numbers should be removed.
	I never use FORTRAN and none of the ANSI C compilers and libraries I
	use recognize complex numbers as a primitive data type.  Now, here's
	a significant part of the computing world that cannot handle complex
	numbers naturally; so, why are they in the proposed standard?

	I'm new to the FITS world, but it certainly seems that the 'F' in
	Flexible certainly does not apply.  This standard is not evolving
	to take into account real world problems and needs.

+--- . .' ----+--------------------------------+----------------------------+
|   /| | |  | | Tom Nicinski / MS 234          | nicinski at fnal.fnal.gov     |
|    +-+-+\ | | Fermi National Accelerator Lab |                         _  |
| .  | | | \| | P.O. Box 500                   |                        [o] |
| `--' | |  | | Batavia, IL 60510-0500         |                        /|\ |
+---- -' -----+--------------------------------+----------------------------+