From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul  7 22:18:35 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id WAA02315
	for fitsbits-spinner; Tue, 7 Jul 1998 22:18:10 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id WAA02310
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 7 Jul 1998 22:18:07 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id WAA05983
	for fitsbits at majordomo.cv.nrao.edu; Tue, 7 Jul 1998 22:18:02 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA09659
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 30 Jun 1998 16:58:48 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id QAA28358
	for <fitsbits at fits.cv.nrao.edu>; Tue, 30 Jun 1998 16:58:46 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id QAA04385;
	Tue, 30 Jun 1998 16:58:45 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 30 Jun 98 20:53:59 GMT
From: willner at cfa183.harvard.edu (Steve Willner)
Message-ID: <35995067.0 at cfanews.harvard.edu>
Organization: Smithsonian Astrophysical Observatory, Cambridge, MA,  USA
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!gatech!128.10.2.10.MISMATCH!purdue!oitnews.harvard.edu!cfanews.harvard.edu!cfa183!willner
References: <Pine.GSO.3.95.980605125836.19151C-100000 at dr21.astro.uiuc.edu> <6lb0jk$ha$1 at dei.ucolick.org>
Subject: Re: re OBJECT keyword
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

In article <6lb0jk$ha$1 at dei.ucolick.org>, sla at ucolick.borg (Steve
Allen) writes:
> We cannot envision a user interface which can overcome the human
> factors involved in the setting of OBJECT values so as to conform
> reliably to the IAU Recommendations for Nomenclature (IAU RN).

One of us has misunderstood what is being proposed.  

I don't see any effort to force users to put anything specific in the
OBJECT keyword.  As I understood it, the proposal was merely to
revise the definition to allow more characters to be used if needed.
(Isn't OBJECT now limited to some fairly modest length, or have I
misunderstood the problem?)  Whether one chooses to use those extra
characters to put in a proper designation or something else is up to
the user.

In other words, is there any good reason why OBJECT should not allow
the maximum possible number of characters (69?) in a FITS record?

-- 
Steve Willner            Phone 617-495-7123     swillner at cfa.harvard.edu
Cambridge, MA 02138 USA                 
(Please email your reply if you want to be sure I see it; include a
valid Reply-To address to receive an acknowledgement.  Commercial
email is NOT appreciated.)


From owner-fitsbits at kochab.cv.nrao.edu  Wed Jul  8 09:56:30 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA25159
	for fitsbits-spinner; Wed, 8 Jul 1998 09:56:15 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA25154
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 8 Jul 1998 09:56:11 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id JAA06709
	for fitsbits at majordomo.cv.nrao.edu; Wed, 8 Jul 1998 09:56:07 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id GAA24872
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 8 Jul 1998 06:01:17 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id GAA06525
	for <fitsbits at fits.cv.nrao.edu>; Wed, 8 Jul 1998 06:01:12 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id GAA16545
	for <fitsbits at fits.cv.nrao.edu>; Wed, 8 Jul 1998 06:01:09 -0400
Received: from jedai.unige.ch(129.194.12.7) by palantir.cv.nrao.edu via smap (V1.3)
	id sma016534; Wed Jul  8 06:00:46 1998
Received: from obs.unige.ch (isdcul1.unige.ch)
 by jedai.unige.ch (PMDF V5.1-10 #30042)
 with ESMTP id <0EVR00EGVT1KIJ at jedai.unige.ch> for fitsbits at fits.cv.nrao.edu;
 Wed,  8 Jul 1998 11:58:33 +0200 (MET)
Date: Wed, 08 Jul 1998 11:58:08 +0200
From: JENNINGS Don <Don.Jennings at obs.unige.ch>
Subject: Comments on NOST 100-1.2
To: fitsbits at fits.cv.nrao.edu
Cc: "isdc) Jennings Donald G." <Don.Jennings at obs.unige.ch>,
        pence at tetra.gsfc.nasa.gov
Message-id: <35A342B0.DC2A0F4D at obs.unige.ch>
Organization: INTEGRAL Science Data Centre
MIME-version: 1.0
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Hello all,

I have briefly reviewed the new draft FITS standard NOST
100-1.2 and have the following three comments. Since I do
not subscribe to the FITSBITS exploder or normally read
sci.astro.fits, please forgive me if my comments have
already been discussed. I ask that the NOST Technical Panel
consider my comments for inclusion into the new Standards
document.


      I. Support for 64-bit integers

I believe that this is the right time to add the 64-bit
integer data type to FITS. Reasons:

  1. Other data formats support 64 bit integers. The lack of
64-bit integers in FITS is a significant obstacle when
importing non-FITS data into FITS.

  2. 64-bit processors are now common. This implies that the
use of the "long int" data type in programs will be more
frequent. FITS must be able to store these integer values if
it is to be a usable format.

  3. 64-bit operating systems are now common. This implies
that there are quantities generated that cannot be expressed
in a 32-bit integer any longer; e.g., memory addresses, file
sizes.

  4. It is extreamly simple to do. Primary Arrays and IMAGE
extensions will accept BITPIX = 64, and BINTABLES will
accept TFORM = 'rKa'. 

  5. 64-bit integer values are at least as useful and worthy
of support as the complex data types. I personally have
never needed to store complex numbers in a FITS file, nor
known anyone with the need, but have needed 64-bit integer
support several times (.e.g., onboard spacecraft clock
times).

  6. The only reasons that I have heard agaist 64-bit
integer support essentially condense into "we can live
without it". But I claim the time has come where we cannot
live without it. I suspect that the programmers that limited
the expression of the year to two digits had a similiar "we
can live without it" argument in the 60's and 70's.
  
If the NOST Technical Panel decides not to include 64-bit
integer support in the new version of the standard, then I
ask that they at least provide their reasons for not doing
so in the new Standards document. This way history can make
them accountable for their decision.


     II. Unsigned Integer Convention

The desire for support of unsigned integers has, I believe,
been expressed before. Fortuantely, there is a way to store
unsigned integers in the current FITS standard using the
BZERO (for primary arrays and IMAGEs) and TZEROn (for
BINTABLEs) keywords. See the CFITSIO Users manual for more
details.

I request that this convention be described in one of the
appendicies of the new Standard. It could be extreamly
useful for the newer generation of FITS readers and writers
to support this convention. Note that: (1) it is already
supported by software (CFITSIO), and (2) it is already in
use within the community.


    III. Alternate Substring Array convention B.3

The array substring convention provided in appendix B3,
where substrings may be expressed as 'rA:SSTRw/nnn', should
also list the alternate convention of 'rAw' where:

r = the total length of the ASCII character field
w = the width of each substring in the character field

Note that this convention: (1) is already suported by
software (CFITSIO), (2) is already in use within the
community, and (3) is much more likely in general to be used
over the 'rA:SSTRw/nnn' convention due to its simplicity.


Thank you,

Don Jennings

-- 

                                                  
------------------------------------------------------------------
If you understand what you're doing then you're not learning 
anything

Don JENNINGS                     
INTEGRAL Science Data Centre     E-mail:
Don.Jennings at obs.unige.ch 
16, Chemin d'Ecogia              Phone:  +41 22 950-91-23
CH-1290 Versoix                  Fax:    +41 22 950-91-33

------------------------------------------------------------------



From owner-fitsbits at kochab.cv.nrao.edu  Thu Jul  9 15:52:41 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id PAA24593
	for fitsbits-spinner; Thu, 9 Jul 1998 15:51:44 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA24588
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 9 Jul 1998 15:51:41 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id PAA09396
	for fitsbits at majordomo.cv.nrao.edu; Thu, 9 Jul 1998 15:51:39 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA24490
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 9 Jul 1998 14:58:50 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id OAA09326
	for <fitsbits at fits.cv.nrao.edu>; Thu, 9 Jul 1998 14:58:47 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id OAA24927
	for <fitsbits at fits.cv.nrao.edu>; Thu, 9 Jul 1998 14:58:46 -0400
Received: from mraos.ra.phy.cam.ac.uk(131.111.48.8) by palantir.cv.nrao.edu via smap (V1.3)
	id sma024924; Thu Jul  9 14:58:30 1998
Received: from mraosb.ra.phy.cam.ac.uk by mraos.ra.phy.cam.ac.uk with smtp
	(Smail3.1.29.0 #2) id m0yuLne-0004HQC; Thu, 9 Jul 98 19:52 BST
Date: Thu, 9 Jul 1998 19:52:09 +0100 (BST)
From: Sally Hales <segh at mrao.cam.ac.uk>
X-Sender: segh at mraosb
To: fitsbits at fits.cv.nrao.edu
Subject: sexagesimal TDISPn
Message-ID: <Pine.SOL.3.91.980709185017.20018A-100000 at mraosb>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk


Display of celestial coordinates held internally in degrees in a BINTABLE

Normally, in a FITS browser for example, source coordinates are displayed
to the user in sexagesimal format, converted from the angle held internally
in degrees, since RA,Dec in decimal degrees are not useful for source
recognition etc. However, as things stand at present, there is no way for
the originator of a BINTABLE to specify what sexagesimal precision he deems
appropriate for the display of a celestial coordinate. so the user is left
to make his own arbitrary choice, possibly truncating or spuriously 
extending the meaningful precision of the original data. The obvious place
to make provision for specifying the appropriate sexagesimal precision
would be the TDISPn field - and the fact that so many BINTABLES 
contain celestial coordinates which are not recognisable to the user when
displayed in any of the existing TDISPn formats emphasises the need for
such provision. 

      There are so many respects in which the BINTABLE is superior to
compressed ASCII (which now seems to be favoured by some users, perhaps
because the lack of a standard for the problem above is a stumbling block 
for making a really versatile FITS browser which would be adopted throughout
the astronomical community) - it seems a pity if it is not fully exploited
for want of a solution to this small omission.

      Sally Hales
      MRAO Cambridge UK



From owner-fitsbits at kochab.cv.nrao.edu  Fri Jul 10 10:27:46 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA24655
	for fitsbits-spinner; Fri, 10 Jul 1998 10:27:18 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA24649
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 10 Jul 1998 10:27:15 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA10402
	for fitsbits at majordomo.cv.nrao.edu; Fri, 10 Jul 1998 10:27:11 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA22762
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 10 Jul 1998 08:09:57 -0400 (EDT)
Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id IAA10002
	for <fitsbits at fits.cv.nrao.edu>; Fri, 10 Jul 1998 08:09:48 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by cv3.cv.nrao.edu (8.8.5/8.8.5/CV-2.7) with ESMTP id EAA02780
	for <fitsbits at fits.cv.nrao.edu>; Fri, 10 Jul 1998 04:20:44 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id EAA25030
	for <fitsbits at fits.cv.nrao.edu>; Fri, 10 Jul 1998 04:15:42 -0400
Received: from web3.hq.eso.org(134.171.7.4) by palantir.cv.nrao.edu via smap (V1.3)
	id sma025027; Fri Jul 10 04:15:25 1998
Received: from dfs1.hq.eso.org by web3.hq.eso.org with ESMTP (8.8.5/ eso-5.3)	id KAA10075; Fri, 10 Jul 1998 10:08:42 +0200 (MET DST)
Message-Id: <199807100808.KAA26254 at dfs1.hq.eso.org>
Received: by dfs1.hq.eso.org (8.8.5/ eso-5.3)	id KAA26254; Fri, 10 Jul 1998 10:08:41 +0200 (MET DST)
To: fitsbits at fits.cv.nrao.edu
Subject: Comments on NOST 100-1.2 of 1998-04-06
Date: Fri, 10 Jul 1998 10:08:41 +0200
From: Preben Grosbol <pgrosbol at eso.org>
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Dear FITS exploder,
 I had unfortunately not time to read the NOST 100-1.2 document of
1998-04-06 carefully before due to other deadlines but here are
my first basic set of comments.  Due to travels, I would not
be able to discuss issues before 1998-07-21.  First a few basic
comments:

 1) In the e-mail announcing the review, it is stated that 'It will
    be submitted to IAU Commission 5 for formal acceptance ...'.
    This would not be possible with the current rules under which
    the IAU FITS Working Group only would consider proposals after
    they have been recommended by the three regional FITS groups.
    Thus, it would be natural for the NASA Technical Panel to
    submit their proposal to the North American FITS group for
    recommendation.  Having said that, I fully support that
    general comments are solicited through WWW to ensure a
    thorough review.

 2) One of the most basic rules of FITS is that not change should
    be made which would make current FITS files invalid.  As the
    proposals prohibit usage which is not explicitly illegal now, it
    is not acceptable in its current form.  One should distinguish
    two cases: a) changes which make old FITS files invalid, and
    b) modifications which make new FITS files incompatible with
    old readers.  Whereas the former changes must not be allowed,
    the latter should be avoided since they just add work for
    re-programming with little advantage.

I would like to complement the NASA FITS panel for an important
work which will benefit the FITS community greatly.  My concerns
are related to the details and not the general scope of the
document.

Below I have listed my explicit comments which are not complete
due to time pressure.

Best regards,
Preben Grosbol
ESO.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The explicit comments are given with reference to page (p) and
section (s) in the NOST 100-1.2 PostScript version of 1998-04-06:

p11,s4.3: 'The primary header may, but need not be, followed ... array.'

     A header is always followed by a data array.  The data array
     may, however, be of zero size.

p13,s4.4.3: '(or random groups records if present)'

     Formally the random groups records are special records and can
     therefore NOT be followed by an extension.

p15,s5.1.2.1: 'For indexed keywords with a single ...'

     This phrase tries to distinguish single index (e.g. NAXIS123)
     and multiple index (e.g. PC012015) keywords but as the latter
     is not clearly defined none of them are.  It must be reworded
     to make sense.

p15,s5.1.2.2: 'that field may be a null field'

     The concept of 'null field' is not trivial since multiple
     occurrence of the same keywords is not defined.  The problem
     arises since the type of the keyword is defined by its value.
     If a 'null field' is given first and the same keywords is
     later assigned a value the resulting type is unclear.
     The whole issue surrounding repeated assignment of keyword
     values should be resolved.

p16,s5.2.1: '... followed by a closing single quote ...'

     The FITS standard specifies that the closing quote first may
     occur in column 20.  Removing this restriction may cause
     significant problem for old readers without any added
     functionality.

p17,s5.2.3: 'An integer consists of a leading '+' or '-' ...'

     For positive integers there may be no leading '+'.

p17,s5.2.4: 'If only the integer part is present, the decimal point
             may be omitted'

    The FITS standard specifies that the 'decimal point' must appear.

p17,s5.2.5: 'enclosed in parentheses'

    The FITS standard does not specify the complex numbers must
    be enclosed in parentheses.

p18,s5.3: 'degrees are the required units for celestial ...'

   Although I agree in principle the wording is unclear e.g.
   some observatories are known to use keywords RA and DEC
   for the celestial coordinates and given them as strings.
   Should such files be defined invalid by this proposal?

p19,s5.4.1.1: 'SIMPLE ... is not permitted in extension headers'

   This is an additional requirement which may render existing
   FITS files invalid.

p19,s5.4.1.1: 'SIMPLE ... this standard in some significant way'

   Should be reworded as a FITS either conforms to the standard
   or not - 'some significant way' is subjective.

p19,s5.4.1.1: 'NAXISn ... and for no other values of n'

   Yes but again it is not specified in the FITS standard.  It
   would be better just to ignore such keywords.

p21,s5.4.1.1: 'XTENSION ... must not appear in the primary header'

   This restriction is not in the FITS standard and may render
   old FITS files invalid.

p29,s7: 'outside this field ... random groups format'

   Subjective statement which should be omitted.

p33,s8.1: 'TABLE '

   The string must include 8 characters i.e. 'TABLE   '

p33,s8.1.1: 'XTENSION ... 'TABLE ''

   The string must include 8 characters i.e. 'TABLE   '

p36,s8.1.5: 'ANSI FORTRAN-77'

   The reference to FORTRAN-77 should be consistent - either
   one should ANSI all places or none.

p37,s8.1.5: 'It may be stored, left justified, ... information.'

   The sentence is either trivial or should be rephrased to give
   some significant meaning.

p37,s8.1.5: 'The value of ...'

   It seems dangerous to reword the FORTRAN-77 format definition.
   Although it may be nice for a trivial implementation there may
   be slight differences in the interpretation if it is not a verbatim
   reproduction of the real standard.

p38,s8.2: 'IMAGE '

   The extension name is 'IMAGE   ' including three spaces.

p38,s8.2.1: 'XTENSION ... IMAGE'

   The string for the image extension is 'IMAGE   '.

p39,s8.2.1: 'NAXISn ... for no other values of n'

   An additional requirement which may render old FITS files invalid.

p46,s8.3.3.1: 'Array Descriptor ... of not more than one pair ...'

   As the field is 8 byte, it is exactly one pair and not zero.

p46,s8.3.4: 'Display Format'

   Again it is dangerous to rephrase the FORTRAN-90 format definition.

p46,s8.3.4: 'Integer data are encoded ...'

   It is not clear what is done with X and B type fields.

p47,s8.3.4: 'For data of type integer, logical ...'

   A reference to X and B type data should be made.

p51,sA: 'The following notation ...'

   It would be simpler if a more standard BNF was used.

p69,sE: 

   The points 8, 12, 15, 16, 18a, 19b, 29, 30d, 31b, 31c, 32, 33b, 37
   and 38 give cause to significant concern as they may yield
   incompatibilities with the FITS format.

p73,sE: 'applies applies' -> 'applies'

p76,sE: 'BIMTABLE' -> 'BINTABLE'




From owner-fitsbits at kochab.cv.nrao.edu  Fri Jul 10 10:27:46 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA24673
	for fitsbits-spinner; Fri, 10 Jul 1998 10:27:33 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA24668
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 10 Jul 1998 10:27:30 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA10407
	for fitsbits at majordomo.cv.nrao.edu; Fri, 10 Jul 1998 10:27:28 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA15273
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 10 Jul 1998 09:11:33 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id JAA10266
	for <fitsbits at fits.cv.nrao.edu>; Fri, 10 Jul 1998 09:11:28 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id JAA15646
	for <fitsbits at fits.cv.nrao.edu>; Fri, 10 Jul 1998 09:11:26 -0400
Received: from mraos.ra.phy.cam.ac.uk(131.111.48.8) by palantir.cv.nrao.edu via smap (V1.3)
	id sma015643; Fri Jul 10 09:11:20 1998
Received: from mraosb.ra.phy.cam.ac.uk by mraos.ra.phy.cam.ac.uk with smtp
	(Smail3.1.29.0 #2) id m0yucrC-0004MIC; Fri, 10 Jul 98 14:04 BST
Date: Fri, 10 Jul 1998 14:04:57 +0100 (BST)
From: Sally Hales <segh at mrao.cam.ac.uk>
X-Sender: segh at mraosb
To: fitsbits at fits.cv.nrao.edu
Subject: re NOST: sexagesimal TDISPn 
Message-ID: <Pine.SOL.3.91.980710140005.21206A-100000 at mraosb>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk



RE: NOST 100-1.2 Draft Standard
(a repeat of my earlier message where I forgot to mention NOST specifically!)

Display of celestial coordinates held internally in degrees in a BINTABLE

Normally, in a FITS browser for example, source coordinates are displayed
to the user in sexagesimal format, converted from the angle held internally
in degrees, since RA,Dec in decimal degrees are not useful for source
recognition etc. However, as things stand at present, there is no way for
the originator of a BINTABLE to specify what sexagesimal precision he deems
appropriate for the display of a celestial coordinate. so the user is left
to make his own arbitrary choice, possibly truncating or spuriously 
extending the meaningful precision of the original data. The obvious place
to make provision for specifying the appropriate sexagesimal precision
would be the TDISPn field - and the fact that so many BINTABLES 
contain celestial coordinates which are not recognisable to the user when
displayed in any of the existing TDISPn formats emphasises the need for
such provision. 

      There are so many respects in which the BINTABLE is superior to
compressed ASCII (which now seems to be favoured by some users, perhaps
because the lack of a standard for the problem above is a stumbling block 
for making a really versatile FITS browser which would be adopted throughout
the astronomical community) - it seems a pity if it is not fully exploited
for want of a solution to this small omission.

      Sally Hales
      MRAO Cambridge UK




From owner-fitsbits at kochab.cv.nrao.edu  Fri Jul 10 13:06:12 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA17203
	for fitsbits-spinner; Fri, 10 Jul 1998 13:05:59 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA17197
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 10 Jul 1998 13:05:56 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA10783
	for fitsbits at majordomo.cv.nrao.edu; Fri, 10 Jul 1998 13:05:53 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA10381
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 10 Jul 1998 12:22:55 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA10728
	for <fitsbits at fits.cv.nrao.edu>; Fri, 10 Jul 1998 12:22:52 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id MAA19659
	for <fitsbits at fits.cv.nrao.edu>; Fri, 10 Jul 1998 12:22:50 -0400
Received: from poseidon.ifctr.mi.cnr.it(155.253.16.87) by palantir.cv.nrao.edu via smap (V1.3)
	id sma019650; Fri Jul 10 12:22:41 1998
Received: from localhost by poseidon.ifctr.mi.cnr.it; (5.65v3.2/1.1.8.2/05Sep96-0731PM)
	id AA12296; Fri, 10 Jul 1998 18:19:13 +0200
Organization: Istituto di Fisica Cosmica e Tecnologie Relative
Date: Fri, 10 Jul 1998 18:19:13 +0200 (MET DST)
From: Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
To: fitsbits at fits.cv.nrao.edu
Subject: Re: Comments on NOST 100-1.2
In-Reply-To: <35A342B0.DC2A0F4D at obs.unige.ch>
Message-Id: <Pine.OSF.3.95.980710180000.8773P-100000 at poseidon.ifctr.mi.cnr.it>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On Wed, 8 Jul 1998, JENNINGS Don wrote:

>   2. 64-bit processors are now common. This implies that the
> use of the "long int" data type in programs will be more

  How common ? AFAIK we have DEC Alphas (will they survive Compaq ?) and
  Sun UltraSparc (but the OS does NOT use 64-bit features, or at least so
  they told me when I inquired about migration, thinking of having similar
  problems as the Ultrix-->Digital Unix transition)

  Is INTEGER*8 in Fortran now standard ? or just supported by a few vendors ?
  (and by the way, why should one need it ?)

>   3. 64-bit operating systems are now common. This implies
> that there are quantities generated that cannot be expressed
> in a 32-bit integer any longer; e.g., memory addresses, file
> sizes.

  See above for comment on how common they are. 
  The quantity you mention are not relevant talking of the CONTENT of DATA
  files.
  And I doubt they are of practical use in common conditions (I see that
  peoples in banks and similar tend to have large databases, but I ever
  doubt to need a > 2GB file  ... or to have > 2GB physical memory ... and
  since I do not have that, why should I need 64-bit addresses ? In fact
  on Alpha I compile EVERYTHING with the -taso option : Truncated Address
  Space Option, so that addresses fit into 32 bits and I have portable
  code)

>   6. The only reasons that I have heard agaist 64-bit
> integer support essentially condense into "we can live
> without it".

  I still believe we can.
  Unless you want to solve the problem of the inventor of the game of
  chess (if you put a grain of rice on the first square of the chessboard,
  two on the second, four on the third ...) why should one need to COUNT
  such large numbers with ABSOLUTE precision ?  REAL*8 should be enough.

  40- or 48-bit s/c clocks are the only things which comes to my mind,
  but s/c clocks are such a pain in the neck anyhow (also because they are
  unsigned :-( ). And in practice one never has so long elapsed periods or so
  fast timing that one cannot either round to "Unix time seconds" or MJD, or
  use full resolution in a limited interval, or convert to REAL*8 elapsed
  seconds.

I'm a supporter of Ockham's razor :

"file formats, data structures, data types non sunt multiplicanda praeter
necessitatem" 



>      II. Unsigned Integer Convention
>

Oh Yet Another Data Type !
But fortunately as you say ...

> Fortuantely, there is a way to store
> unsigned integers in the current FITS standard using the
> BZERO (for primary arrays and IMAGEs) and TZEROn (for
> BINTABLEs) keywords. 

Thus I support the specific inclusion in the documentation of the way how to
use them.

----------------------------------------------------------------------------
Lucio Chiappetti - IFCTR/CNR - via Bassini 15 - I-20133 Milano (Italy)      
Member of the Ockhamist's Club, together with 
William of Ockham, Guglielmo da Roveredo, Wilhelm von Eichdorf
----------------------------------------------------------------------------
For more info : http://www.ifctr.mi.cnr.it/~lucio/personal.html             
----------------------------------------------------------------------------



From owner-fitsbits at kochab.cv.nrao.edu  Sat Jul 11 10:01:08 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA28047
	for fitsbits-spinner; Sat, 11 Jul 1998 10:00:29 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA28036
	for <fitsbits at majordomo.cv.nrao.edu>; Sat, 11 Jul 1998 10:00:26 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA11926
	for fitsbits at majordomo.cv.nrao.edu; Sat, 11 Jul 1998 10:00:22 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id GAA28345
	for <fitsbits at majordomo.cv.nrao.edu>; Sat, 11 Jul 1998 06:45:11 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id GAA11839
	for <fitsbits at fits.cv.nrao.edu>; Sat, 11 Jul 1998 06:45:07 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id GAA15006;
	Sat, 11 Jul 1998 06:45:06 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 11 Jul 1998 10:44:58 GMT
From: davis at space.mit.edu (John E. Davis)
Message-ID: <slrn6qc2e2.rh3.davis at mygir.davis.net>
Organization: Center for Space Research
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!eecs-usenet-02.mit.edu!davis
References: <6nvtr3$amr$1 at newsfeed.cv.nrao.edu>
Subject: Re: Comments on NOST 100-1.2
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On 8 Jul 1998 09:56:51 -0400, JENNINGS Don <Don.Jennings at obs.unige.ch>
wrote:
>The desire for support of unsigned integers has, I believe,
>been expressed before. Fortuantely, there is a way to store
>unsigned integers in the current FITS standard using the
>BZERO (for primary arrays and IMAGEs) and TZEROn (for
>BINTABLEs) keywords. See the CFITSIO Users manual for more
>details.

I think that this hack should be done away with in favor of real
support for unsigned values.  About the only reason I can see for not
adding such support is that older readers may have problems reading
the files with unsigned values.  But that's life--- software must
evolve.

--John


From owner-fitsbits at kochab.cv.nrao.edu  Sat Jul 11 14:31:39 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id OAA14909
	for fitsbits-spinner; Sat, 11 Jul 1998 14:31:27 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id OAA14828
	for <fitsbits at majordomo.cv.nrao.edu>; Sat, 11 Jul 1998 14:31:22 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id OAA12133
	for fitsbits at majordomo.cv.nrao.edu; Sat, 11 Jul 1998 14:31:19 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA19441
	for <fitsbits at majordomo.cv.nrao.edu>; Sat, 11 Jul 1998 13:37:30 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id NAA12089
	for <fitsbits at fits.cv.nrao.edu>; Sat, 11 Jul 1998 13:37:27 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id NAA06767;
	Sat, 11 Jul 1998 13:37:25 -0400
To: fitsbits at fits.cv.nrao.edu
Date: Sat, 11 Jul 1998 13:26:10 -0400
From: akk <anilk at mtolympus.ari.net>
Message-ID: <Pine.BSI.3.95.980711131112.25922A-100000 at mtolympus.ari.net>
Organization: ARInternet, Corp.
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!news-peer-east.sprintlink.net!news-peer.sprintlink.net!news-backup-east.sprintlink.net!news.sprintlink.net!198.69.192.1!ari.ari.net!mtolympus.ari.net!anilk
Subject: floating illegal operand->error
Newsgroups: comp.lang.idl-pvwave,sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk


Hi all,
I've written a C program to resize an Image (i.e. resize a 2-D array).  
I then use IDL to view the resized image.  For starters I just have 
the program resize the image to the exact same dimensions as the 
original image (i.e. create an identical image).  I am able to view this 
new image and it appears identical to the original image, however in
addition, idl outputs the message "Program caused an arithmetic error:
      Floating illegal operand" 
Does anyone know what might be causing this error or what it means?
Thanks...

NOTE: I'm using the command-> fits_read, 'FILENAME', data, header to read
in the image and then use tvscl to view the image.






From owner-fitsbits at kochab.cv.nrao.edu  Sun Jul 12 10:43:30 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA03966
	for fitsbits-spinner; Sun, 12 Jul 1998 10:43:01 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA03961
	for <fitsbits at majordomo.cv.nrao.edu>; Sun, 12 Jul 1998 10:42:56 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA13461
	for fitsbits at majordomo.cv.nrao.edu; Sun, 12 Jul 1998 10:42:53 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA21721
	for <fitsbits at majordomo.cv.nrao.edu>; Sun, 12 Jul 1998 08:48:57 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id IAA13372
	for <fitsbits at fits.cv.nrao.edu>; Sun, 12 Jul 1998 08:48:48 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id IAA09598;
	Sun, 12 Jul 1998 08:48:47 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 12 Jul 1998 10:41:41 GMT
From: davis at space.mit.edu (John E. Davis)
Message-ID: <slrn6qf7t0.rkd.davis at mygir.davis.net>
Organization: Center for Space Research
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!hub.org!data.pa.vix.com!news.gnac.net!uunet!in4.uu.net!news.research.att.com!eecs-usenet-02.mit.edu!davis
References: <Pine.OSF.3.95.980710180000.8773P-100000 at poseidon.ifctr.mi.cnr.it>
Subject: Re: Comments on NOST 100-1.2
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On 10 Jul 1998 13:06:38 -0400, Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
wrote:
>  How common ? AFAIK we have DEC Alphas (will they survive Compaq ?) and
>  Sun UltraSparc (but the OS does NOT use 64-bit features, or at least so

  I heard that the `long' integer will be 64 bits in the next release
  of Solaris.  Is this true?

>  And I doubt they are of practical use in common conditions (I see that
>  peoples in banks and similar tend to have large databases, but I ever
>  doubt to need a > 2GB file  ... or to have > 2GB physical memory ... and
>  since I do not have that, why should I need 64-bit addresses ? In fact

  Less than 20 years ago, Bill Gates thought that no one would ever
  need 640K of memory.  Today, it is not that uncommon to see 100
  Megabyte data files.  How many people made statements twenty years
  ago about never needing 100 Megabyte files?

  If we have learned anything from the computer revolution, then it is
  that we cannot predict the future.  I have no idea whether or not I
  will be using a keyboard or a microphone in 10 years to communicate
  with my computer.

  The FITS file format is nearly 20 years old.  About a year ago a new
  FITS time specification was necessary to handle the year 2000
  problem. The fact is that several modern operating systems support
  64 bit integers and there are more on the horizon.  Let's not make
  the same mistake and ignore 64 bit data types as well as unsigned
  types.

--John


From owner-fitsbits at kochab.cv.nrao.edu  Sun Jul 12 10:43:46 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA03990
	for fitsbits-spinner; Sun, 12 Jul 1998 10:43:44 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA03984
	for <fitsbits at majordomo.cv.nrao.edu>; Sun, 12 Jul 1998 10:43:40 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA13467
	for fitsbits at majordomo.cv.nrao.edu; Sun, 12 Jul 1998 10:43:37 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA23382
	for <fitsbits at majordomo.cv.nrao.edu>; Sun, 12 Jul 1998 10:01:32 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id KAA13411
	for <fitsbits at fits.cv.nrao.edu>; Sun, 12 Jul 1998 10:01:29 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id KAA12098
	for <fitsbits at fits.cv.nrao.edu>; Sun, 12 Jul 1998 10:01:28 -0400
Received: from ujf.ujf-grenoble.fr(193.54.232.33) by palantir.cv.nrao.edu via smap (V1.3)
	id sma012095; Sun Jul 12 10:01:10 1998
Received: from gagax5.obs.ujf-grenoble.fr (gagax5.obs.ujf-grenoble.fr [195.220.79.15])
	by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id PAA03900;
	Sun, 12 Jul 1998 15:54:48 +0200 (MET DST)
Received: (from forveill at localhost) by gagax5.obs.ujf-grenoble.fr (8.7.6/8.6.9) id PAA45326; Sun, 12 Jul 1998 15:54:48 +0200
From: Thierry Forveille <Thierry.Forveille at obs.ujf-grenoble.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <13736.49192.5219.523617 at gagax5.obs.ujf-grenoble.fr>
Date: Sun, 12 Jul 1998 15:54:48 +0200 (DFT)
To: davis at space.mit.edu (John E. Davis)
Cc: fitsbits at fits.cv.nrao.edu
Subject: Re: Comments on NOST 100-1.2
Newsgroups: sci.astro.fits
In-Reply-To: <slrn6qc2e2.rh3.davis at mygir.davis.net>
References: <6nvtr3$amr$1 at newsfeed.cv.nrao.edu>
	<slrn6qc2e2.rh3.davis at mygir.davis.net>
X-Mailer: VM 6.49 under Emacs 19.34.9
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

John E. Davis writes:
 > On 8 Jul 1998 09:56:51 -0400, JENNINGS Don <Don.Jennings at obs.unige.ch>
 > wrote:
 > >The desire for support of unsigned integers has, I believe,
 > >been expressed before. Fortuantely, there is a way to store
 > >unsigned integers in the current FITS standard using the
 > >BZERO (for primary arrays and IMAGEs) and TZEROn (for
 > >BINTABLEs) keywords. See the CFITSIO Users manual for more
 > >details.
 > 
 > I think that this hack should be done away with in favor of real
 > support for unsigned values.  About the only reason I can see for not
 > adding such support is that older readers may have problems reading
 > the files with unsigned values.  But that's life--- software must
 > evolve.
 > 
I must say I have never seen any convincing argument for supporting
unsigned values. The present "hack" as you call it offers all the
functionalities for no cost, while adding unsigned as an additional
supported format would cost significant extra code to everybody for no
additional value. To me Occam's razor says it should stay out...

64 bit integers are a whole different story, as they bring real
improvements. The question for them is not whether, but when. We
will I think have to include them, but the present revision may or 
may not be timely.



From owner-fitsbits at kochab.cv.nrao.edu  Sun Jul 12 18:49:22 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id SAA09376
	for fitsbits-spinner; Sun, 12 Jul 1998 18:49:10 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA09371
	for <fitsbits at majordomo.cv.nrao.edu>; Sun, 12 Jul 1998 18:49:07 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id SAA13718
	for fitsbits at majordomo.cv.nrao.edu; Sun, 12 Jul 1998 18:49:04 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA03433
	for <fitsbits at majordomo.cv.nrao.edu>; Sun, 12 Jul 1998 15:39:00 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id PAA13618
	for <fitsbits at fits.cv.nrao.edu>; Sun, 12 Jul 1998 15:38:57 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id PAA15137
	for <fitsbits at fits.cv.nrao.edu>; Sun, 12 Jul 1998 15:38:56 -0400
Received: from space.mit.edu(18.75.0.10) by palantir.cv.nrao.edu via smap (V1.3)
	id sma015134; Sun Jul 12 15:38:35 1998
Received: from aluche.mit.edu by space.mit.edu AA29034; Sun, 12 Jul 98 15:36:04 EDT
Received: (from davis at localhost)
	by aluche.mit.edu (8.8.7/8.8.7) id PAA04862;
	Sun, 12 Jul 1998 15:36:03 -0400
Date: Sun, 12 Jul 1998 15:36:03 -0400
From: "John E. Davis" <davis at space.mit.edu>
Message-Id: <199807121936.PAA04862 at aluche.mit.edu>
To: Thierry.Forveille at obs.ujf-grenoble.fr
Cc: fitsbits at fits.cv.nrao.edu
Subject: Re: Comments on NOST 100-1.2
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On Sun, 12 Jul 1998 15:54:48 +0200 (DFT), Thierry Forveille <Thierry.Forveille at obs.ujf-grenoble.fr> said:
>I must say I have never seen any convincing argument for supporting
>unsigned values. The present "hack" as you call it offers all the
>functionalities for no cost, while adding unsigned as an additional
>supported format would cost significant extra code to everybody for no
>additional value. To me Occam's razor says it should stay out...

Please correct me if I am wrong, but my main objection to this
convention is inherently non-portable because the BZERO value that must
be used is outside the range of the integer data type.  For example,
to represent an unsigned 32bit integer, BZERO must be set to
2147483648 in the fits file.  Now, BZERO is an integer and this value
is outside the range of an integer.  Why is this a problem?  It is a
problem because parsing it as a 32 bit integer may result in its
truncation. Specifically, CFITSIO uses the strtol function call to
parse these values and this function will truncate 2147483648 to
2147483647.

To see this, consider:

#include <stdio.h>
#include <stdlib.h>

int main ()
{
   long i;
   char *s;

   s = "2147483648";
   i = strtol (s, NULL, 10);
   fprintf (stdout, "%s = %ld\n", s, i);

   s = "2147483647";
   i = strtol (s, NULL, 10);
   fprintf (stdout, "%s = %ld\n", s, i);
   
   return 0;
}

     
Compiled with gcc on my Linux system, this produces:

   2147483648 = 2147483647
   2147483647 = 2147483647

The man page for strtol indicates:

RETURN VALUE
       The  strtol()  function  returns the result of the conver-
       sion, unless the value would underflow or overflow.  If an
       underflow  occurs, strtol() returns LONG_MIN.  If an over-
       flow occurs, strtol() returns LONG_MAX.   In  both  cases,
       errno is set to ERANGE.

So, without real support for unsiged types, I maintain that this
convention is flawed.

Thanks,
--John



From owner-fitsbits at kochab.cv.nrao.edu  Sun Jul 12 18:51:29 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id SAA09445
	for fitsbits-spinner; Sun, 12 Jul 1998 18:51:27 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA09440
	for <fitsbits at majordomo.cv.nrao.edu>; Sun, 12 Jul 1998 18:51:24 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id SAA13727
	for fitsbits at majordomo.cv.nrao.edu; Sun, 12 Jul 1998 18:51:21 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA08930
	for <fitsbits at majordomo.cv.nrao.edu>; Sun, 12 Jul 1998 18:17:24 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id SAA13692
	for <fitsbits at fits.cv.nrao.edu>; Sun, 12 Jul 1998 18:17:22 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id SAA16814;
	Sun, 12 Jul 1998 18:17:21 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 12 Jul 1998 21:10:58 GMT
From: davis at space.mit.edu (John E. Davis)
Message-ID: <slrn6qi9iu.4p5.davis at aluche.mit.edu>
Organization: Center for Space Research
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!news.mathworks.com!uunet!in1.uu.net!news.research.att.com!eecs-usenet-02.mit.edu!davis
References: <6nvtr3$amr$1 at newsfeed.cv.nrao.edu> <slrn6qc2e2.rh3.davis at mygir.davis.net> <13736.49192.5219.523617 at gagax5.obs.ujf-grenoble.fr>
Reply-To: davis at space.mit.edu
Subject: Re: Comments on NOST 100-1.2
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On 12 Jul 1998 10:43:53 -0400, Thierry Forveille <Thierry.Forveille at obs.ujf-grenoble.fr>
wrote:
>I must say I have never seen any convincing argument for supporting
>unsigned values. The present "hack" as you call it offers all the
>functionalities for no cost, while adding unsigned as an additional
>supported format would cost significant extra code to everybody for no
>additional value. To me Occam's razor says it should stay out...

Please correct me if I am wrong, but my main objection to this
convention is that it is inherently non-portable because the BZERO
value that must be used is outside the range of the integer data type.
For example, to represent an unsigned 32bit integer, BZERO must be set
to 2147483648 in the fits file, which is outside the range of a 32 bit
signed integer.  Why is this a problem?  It is a problem because
parsing it as a 32 bit integer may result in its truncation.
Specifically, CFITSIO uses the strtol function call to parse these
values and this function will truncate 2147483648 to 2147483647.

To see this, consider:

#include <stdio.h>
#include <stdlib.h>

int main ()
{
   long i;
   char *s;

   s = "2147483648";
   i = strtol (s, NULL, 10);
   fprintf (stdout, "%s = %ld\n", s, i);

   s = "2147483647";
   i = strtol (s, NULL, 10);
   fprintf (stdout, "%s = %ld\n", s, i);
   
   return 0;
}

     
Compiled with gcc on my Linux system, this produces:

   2147483648 = 2147483647
   2147483647 = 2147483647

The man page for strtol indicates:

RETURN VALUE
       The  strtol()  function  returns the result of the conver
       sion, unless the value would underflow or overflow.  If an
       underflow  occurs, strtol() returns LONG_MIN.  If an over
       flow occurs, strtol() returns LONG_MAX.   In  both  cases,
       errno is set to ERANGE.

It is possible avoid strtol with a different function, but one would
still need to perform integer multiplications which would result in
overflow.  About the only portable alternative would be to use double
precision arithmetic but even that may not be sufficient if you want
to use this convention to represent 64 bit unsigned values.

So, without real support for unsigned types, I maintain that this
convention is flawed.

Thanks,
--John



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 13 08:30:00 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA08400
	for fitsbits-spinner; Mon, 13 Jul 1998 08:29:09 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08395
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 08:29:06 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id IAA14266
	for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 08:29:03 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id EAA05599
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 04:01:23 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id EAA14063
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 04:01:20 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id EAA10626;
	Mon, 13 Jul 1998 04:01:14 -0400
To: fitsbits at fits.cv.nrao.edu
Date: Mon, 13 Jul 1998 09:00:40 +0100
From: Peter Bunclark <psb at ast.cam.ac.uk>
Message-ID: <35A9BEA8.61BD at ast.cam.ac.uk>
Organization: Royal Greenwich Observatory
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!btnet-peer!btnet!nntp.news.xara.net!xara.net!server5.netnews.ja.net!server3.netnews.ja.net!server1.netnews.ja.net!pegasus.csx.cam.ac.uk!not-for-mail
Subject: RA, DEC and UNSIGNED
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

1. Please let's continue to allow RA and DEC in sexadecimal. One of the
most common
        quotes is ``FITS is good because when you have problems you can
just more the header'';
        the easy readability of the header is seen as a great strength. 
The RA and DEC are almost
        the most important keywords for end users, and should be in the
        format the consumer wants.

2. The lack of unsigned data type was, in my opinion, nearly the biggest
cockup in original
        FITS, right behind the EPOCH and DATE problems.  The overheads
of
        the BZERO hack are:
        a)  Compute overhead; either an extra bit of arithmetic, or,
more likely, the
            reader gives up and casts it all to float, causing lots of
extra arithmetic
            and I/O.
        b)  It *is* a hack;  I bet that some of the systems that FITS
was originally 
             designed for, eg 60-bit machines, need different code from
that on base-2
             wordlength machines (? or not?).
        c)  It brings FITS into disrepute every time you have the
embarrassment of
            introducing the system to a new astronomer or software
engineer.

Peter.


From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 13 08:30:17 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA08407
	for fitsbits-spinner; Mon, 13 Jul 1998 08:29:40 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08402
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 08:29:37 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id IAA14271
	for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 08:29:34 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id FAA08275
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 05:27:44 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id FAA14161
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 05:27:39 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id FAA16893;
	Mon, 13 Jul 1998 05:27:37 -0400
To: fitsbits at fits.cv.nrao.edu
Date: Mon, 13 Jul 1998 09:26:24 GMT
From: Skywise <skywise at spamless.internetmci.com>
Message-ID: <35A9D453.BFAA4FEB at spamless.internetmci.com>
Organization: -
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!newsfeed.internetmci.com!208.159.126.161!news.mci2000.com!not-for-mail
Subject: what is FITS?
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Sorry if this seems like a silly question, but only being an amateur
armchair astronomer of sorts, I just recently added a bunch of astronomy
related newsgroups. I've been reading this one for a couple of weeks now
and haven't quite figured out what it's all about. Could some kind soul
enlighten me to what all this FITS business is about? Or perhaps
someplace where I can find out? That way I can understand what everyone
is arguing about here. I'm always interested in learning more about
astronomy and usually have no problem grasping something just by content
but so far this group has eluded me. Thanx so kindly.

Skywise



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 13 08:36:38 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA08456
	for fitsbits-spinner; Mon, 13 Jul 1998 08:36:36 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08451
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 08:36:33 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id IAA14303
	for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 08:36:30 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08440
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 08:33:20 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id IAA14284
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 08:33:12 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id IAA14609
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 08:33:10 -0400
Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3)
	id sma014597; Mon Jul 13 08:33:06 1998
Received: from xebec by head-cfa (SMI-8.6/SMI-SVR4)
	id IAA01583; Mon, 13 Jul 1998 08:26:16 -0400
Received: by xebec (SMI-8.6/SMI-SVR4)
	id IAA25477; Mon, 13 Jul 1998 08:26:16 -0400
From: arots at xebec.harvard.edu (Arnold Rots)
Message-Id: <199807131226.IAA25477 at xebec>
Subject: Re: Comments on NOST 100-1.2
In-Reply-To: <slrn6qc2e2.rh3.davis at mygir.davis.net> from "John E. Davis" at "Jul 11, 98 10:44:58 am"
To: davis at space.mit.edu (John E. Davis)
Date: Mon, 13 Jul 1998 08:26:16 -0400 (EDT)
Cc: fitsbits at fits.cv.nrao.edu
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Hear, hear!
It's not so much a question of whether FITS will ever include unsigned
integer data types, but when.  Having been at the center of the
previous major effort to get them accepted, some five years ago, I 
would estimate that it's going to be another ten years ;-)

  - Arnold

John E. Davis wrote:
> On 8 Jul 1998 09:56:51 -0400, JENNINGS Don <Don.Jennings at obs.unige.ch>
> wrote:
> >The desire for support of unsigned integers has, I believe,
> >been expressed before. Fortuantely, there is a way to store
> >unsigned integers in the current FITS standard using the
> >BZERO (for primary arrays and IMAGEs) and TZEROn (for
> >BINTABLEs) keywords. See the CFITSIO Users manual for more
> >details.
> 
> I think that this hack should be done away with in favor of real
> support for unsigned values.  About the only reason I can see for not
> adding such support is that older readers may have problems reading
> the files with unsigned values.  But that's life--- software must
> evolve.
> 
> --John
> 

--------------------------------------------------------------------------
Arnold H. Rots                                         AXAF Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 81                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 13 12:47:21 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id MAA09009
	for fitsbits-spinner; Mon, 13 Jul 1998 12:46:32 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA09004
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 12:46:29 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id MAA00515
	for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 12:46:26 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA08978
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 12:40:28 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA00502
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 12:40:25 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id MAA22735
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 12:40:24 -0400
Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3)
	id sma022732; Mon Jul 13 12:40:22 1998
Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109])
          by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP
	  id MAA25806 for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 12:39:45 -0400 (EDT)
Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4)
	id MAA24670; Mon, 13 Jul 1998 12:39:43 -0400
Message-ID: <35AA384F.1BE21420 at tetra.gsfc.nasa.gov>
Date: Mon, 13 Jul 1998 12:39:43 -0400
From: William Pence <pence at tetra.gsfc.nasa.gov>
Organization: HEASARC
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: fitsbits at fits.cv.nrao.edu
Subject: Unsigned integer support in NOST 100-1.2
References: <199807121936.PAA04862 at aluche.mit.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

In the previous debate a few years about about adding new unsigned
integer datatypes to FITS I had argued in favor of the proposal. 
However, I have since come to appreciate that the current FITS format
already fully supports unsigned integers (16 and 32 bit at least), hence
I would now oppose any change to the Standard in this regard.  FITS is
able to store unsigned 16 and 32 bit integers in an efficient format
that is easy to read and write.  This is all that is required.  The
transformation between the internal FITS representation and the  machine
representation on a particular computer of the same unsigned integer
value is trivial: flip the value of the most significant bit (bit 32 or
16) and also swap the order of the bytes on little endian machines like
IBM PCs.  

The more important issue for programmers, I believe, is that standard
FITS software like the CFITSIO library should provide a transparent
interface for reading and writing unsigned integers in FITS files.
CFITSIO provides a whole family of routines for reading or writing data
of any supported datatype, including unsigned short, unsigned int, and
unsigned long (in the C language interface) to FITS images or tables. 
When using CFITSIO, the programmer does not need to be concerned in any
way with how the data values are internally represented in the FITS
file.  All the business with setting or reading the BZERO keyword value,
etc. is all handled internally by the interface routines.

Finally, John Davis raised the objection that the BZERO keyword =
2147483648 that is used to represent unsigned 32-bit integers in FITS is
not a valid 32-bit signed integer with some particular compilers (it is
a valid signed integer value with many other compilers, however).  This
is not a problem with the FITS format itself, but instead just
illustrates that the implementation of FITS readers and writers on any
given platform must be able to deal with the limitations of that
platform.  The similar sorts of issues have to be addressed when
reading/writing FITS files in Fortran, which doesn't even support an
unsigned integer datatype at all.

-Bill Pence



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 13 21:34:11 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA10145
	for fitsbits-spinner; Mon, 13 Jul 1998 21:33:47 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA10140
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 21:33:44 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA00961
	for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 21:33:41 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA09786
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 16:26:42 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id QAA00773
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 16:26:39 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id QAA00932
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 16:26:36 -0400
Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3)
	id sma000923; Mon Jul 13 16:26:14 1998
Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109])
          by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP
	  id QAA29849 for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 16:25:42 -0400 (EDT)
Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4)
	id QAA24946; Mon, 13 Jul 1998 16:25:33 -0400
Message-ID: <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov>
Date: Mon, 13 Jul 1998 16:25:33 -0400
From: William Pence <pence at tetra.gsfc.nasa.gov>
Organization: HEASARC
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: fitsbits at fits.cv.nrao.edu
Subject: 64-bit integers in FITS
References: <35A342B0.DC2A0F4D at obs.unige.ch>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

I basically have an open mind about the suggestion to support 64-bit
integers in FITS files, but just wanted to make a couple comments:

- it would be a fairly trivial job to modify the FITS standard to
specify the format for 64-bit integer images and binary table columns. 
Images would have BITPIX = 64, tables would have TFORM = 'K' (or
whatever), and the binary data itself would be written as
twos-complement signed binary integers containing 8 bytes.  Not much
more needs to be said.  There is no restriction on the value of integer
keywords, so they already support 64-bit integers (but most
readers/writers only support 32-bit integers).

- supporting the reading or writing of FITS files containing 64-bit
integer data on 32-bit platforms would likely require a lot of work.  If
the hardware/compiler doesn't support reading and writing 64-bit
integers then interface software like CFITSIO would have to have
software emulation routines to do datatype conversion between 32-bit int
<-> 64-bit int, 64-bit float <-> 64-bit int, etc. and also trap any
overflow conditions.  Presumably there already exist routines to do all
this, written in C, that could be used in CFITSIO.  None the less,
adding support for 64-bit integers in CFITSIO, not to mention all the
other existing FITS readers and writers, would be a big job, and would
make the interface software even more complex than it already is.

- There would still remain the problem that it is not possible in
principle to fully represent 64-bit integers on a 32-bit machines
without possible overflow (when converting to 32-bit integers) or loss
of precision (when converting to double precision floating point).  Thus
one could quite easily write FITS files on 64-bit machines that could
not be read on 32-bit machines.  This would defeat one of the main
purposes of FITS to provide a machine-independent data interchange
format.

____________________________________________________________________
Dr. William Pence                          pence at tetra.gsfc.nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 13 21:35:33 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA10167
	for fitsbits-spinner; Mon, 13 Jul 1998 21:35:31 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA10162
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 21:35:28 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA00971
	for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 21:35:25 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA09853
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 17:03:38 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA00813
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 17:03:35 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id RAA22820;
	Mon, 13 Jul 1998 17:03:34 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 13 Jul 1998 20:49:42 GMT
From: giglio at hades.gsfc.nasa.gov (Louis Giglio)
Message-ID: <6odrt6$si7 at post.gsfc.nasa.gov>
Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!newsfeed.internetmci.com!128.158.254.10!news.msfc.nasa.gov!centauri.hq.nasa.gov!newsfeed.gsfc.nasa.gov!hades.gsfc.nasa.gov!giglio
Subject: EXTNAME Keyword in Primary HDU
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

The subject pretty much sums up my question.  Is it acceptable to have
the EXTNAME keyword -- which is explicitly defined for extension HDU's --
in the primary HDU of a FITS file.  Everything I've read seems to allow
this without actually explicitly stating that it's legal.

Thanks,
Louis


From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 13 21:39:15 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA10619
	for fitsbits-spinner; Mon, 13 Jul 1998 21:39:14 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA10614
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 21:39:10 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA00980
	for fitsbits at majordomo.cv.nrao.edu; Mon, 13 Jul 1998 21:39:08 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA09953
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 13 Jul 1998 18:11:08 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id SAA00854
	for <fitsbits at fits.cv.nrao.edu>; Mon, 13 Jul 1998 18:11:05 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id SAA30153;
	Mon, 13 Jul 1998 18:11:04 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 13 Jul 1998 22:10:43 GMT
From: davis at space.mit.edu (John E. Davis)
Message-ID: <slrn6ql1em.59v.davis at aluche.mit.edu>
Organization: Center for Space Research
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!eecs-usenet-02.mit.edu!davis
References: <199807121936.PAA04862 at aluche.mit.edu> <35AA384F.1BE21420 at tetra.gsfc.nasa.gov>
Reply-To: davis at space.mit.edu
Subject: Re: Unsigned integer support in NOST 100-1.2
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On 13 Jul 1998 12:47:52 -0400, William Pence <pence at tetra.gsfc.nasa.gov>
wrote:
>However, I have since come to appreciate that the current FITS format
>already fully supports unsigned integers (16 and 32 bit at least), hence
>I would now oppose any change to the Standard in this regard.  FITS is

I understand your point that a fits can store unsigned values using
the current convention.  As long as that convention is documented, I
do not care about what bits need to be flipped.  However, I think that
there is a deeper issue that keeps nagging me.  This leads me to
believe that the fits file specification does not define a
well-defined file format that is independent of the reader.

To see what I mean, consider the BZERO and BSCALE keywords.  The NOST
document states that these keywords represent floating point values,
and if the keywords are absent, then they default to 0.0 and 1.0,
respectively.  Then the value of a pixel pixel is given by:

   Physical_Value = BZERO + BSCALE * Array_Value

Does this mean that all images are floating point images?  If so, are
they 64 bit floating point values or 32 bit floating point values?
The file specification does not spell this out which means that the
interpretation is left to the fits reader.  In my opinion, the
document should state that the result of

   Physical_Value = BZERO + BSCALE * Array_Value

depends upon the range of the resulting values, and upon the data types
specified by the syntax used to specify the BZERO and BSCALE keywords.
In this respect, the default values should be the *integers*, 0 and 1,
and not floating point values.

At this point, I have concluded that a fits file simply stores any
numeric value as a 64 bit floating point value in various floating
point and signed integer representations, using the BZERO/BSCALE
values (or their equivalents) to perform the appropriate conversions.
Please try to understand that I am not implying that everything gets
written out to the fits files as 8 byte floating point double
precision numbers.

I feel that the only consistent way to view the current specification
is that all data types are implicitly converted to the largest
available data type capable of representing them, namely 64 bit
floats, and then written out in a user specified representation, e.g.,
as signed 16 bit integers, with the appropriate values of BZERO and
BSCALE.  I can live with this interpretation as long as I can store
all the numeric data types that I work with with no loss of precision.
However, this will present a problem when the file format gets
enlarged to handle 64 bit integer quantities.  Then,

   Physical_Value = BZERO + BSCALE * Array_Value

will result in a loss of precision for 64 bit integers.

Some may find this whole debate pointless, but if you want to define a
fits file whose contents have a well defined meaning that is
independent of the software that reads it, then these seemingly
trivial points matter.

--John


From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul 14 09:50:49 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA25449
	for fitsbits-spinner; Tue, 14 Jul 1998 09:50:26 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA25444
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 09:50:23 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id JAA01673
	for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 09:50:20 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id DAA21549
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 03:29:38 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id DAA01240
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 03:29:26 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id DAA30214;
	Tue, 14 Jul 1998 03:29:25 -0400
To: fitsbits at fits.cv.nrao.edu
Date: Tue, 14 Jul 1998 08:27:20 +0100
From: Peter Bunclark <psb at ast.cam.ac.uk>
Message-ID: <35AB0858.24BE at ast.cam.ac.uk>
Organization: Royal Greenwich Observatory
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!btnet-peer!btnet!dispose.news.demon.net!demon!delos!server1.netnews.ja.net!pegasus.csx.cam.ac.uk!not-for-mail
References: <35A342B0.DC2A0F4D at obs.unige.ch> <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov>
Subject: Re: 64-bit integers in FITS
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Isn't the fundamental point that FITS is a data-interchange medium?
Hence, if someone happens to have 64-bit data, they will have a need
to move it between machines and would probably prefer to have used
FITS.  It's certainly not in FITS's remit to declare to
instrumentatation
groups that they are not allowed to invent 64-bit detectors.

Such a hypothetical group would have to invent a cooked-up data 
format of their own;  if it was me I'd put BITPIX=64 in the knowledge
that everyone would know exactly what I meant.  Why not enshrine it
in the standard, perhaps with the advice to use it only when the
data genuinely requires such a precision?

Peter. 


William Pence wrote:
> 
> I basically have an open mind about the suggestion to support 64-bit
> integers in FITS files, but just wanted to make a couple comments:
> 
> - it would be a fairly trivial job to modify the FITS standard to
> specify the format for 64-bit integer images and binary table columns.
> Images would have BITPIX = 64, tables would have TFORM = 'K' (or
> whatever), and the binary data itself would be written as
> twos-complement signed binary integers containing 8 bytes.  Not much
> more needs to be said.  There is no restriction on the value of integer
> keywords, so they already support 64-bit integers (but most
> readers/writers only support 32-bit integers).
> 
> - supporting the reading or writing of FITS files containing 64-bit
> integer data on 32-bit platforms would likely require a lot of work.  If
> the hardware/compiler doesn't support reading and writing 64-bit
> integers then interface software like CFITSIO would have to have
> software emulation routines to do datatype conversion between 32-bit int
> <-> 64-bit int, 64-bit float <-> 64-bit int, etc. and also trap any
> overflow conditions.  Presumably there already exist routines to do all
> this, written in C, that could be used in CFITSIO.  None the less,
> adding support for 64-bit integers in CFITSIO, not to mention all the
> other existing FITS readers and writers, would be a big job, and would
> make the interface software even more complex than it already is.
> 
> - There would still remain the problem that it is not possible in
> principle to fully represent 64-bit integers on a 32-bit machines
> without possible overflow (when converting to 32-bit integers) or loss
> of precision (when converting to double precision floating point).  Thus
> one could quite easily write FITS files on 64-bit machines that could
> not be read on 32-bit machines.  This would defeat one of the main
> purposes of FITS to provide a machine-independent data interchange
> format.
> 
> ____________________________________________________________________
> Dr. William Pence                          pence at tetra.gsfc.nasa.gov
> NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)
> Greenbelt MD 20771                         +1-301-286-1684 (fax)


From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul 14 09:50:49 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id JAA25442
	for fitsbits-spinner; Tue, 14 Jul 1998 09:49:53 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id JAA25437
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 09:49:50 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id JAA01668
	for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 09:49:46 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id AAA00453
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 00:37:36 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id AAA01098
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 00:37:34 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id AAA17275
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 00:37:32 -0400
Received: from phobos.caltech.edu(131.215.240.1) by palantir.cv.nrao.edu via smap (V1.3)
	id sma017272; Tue Jul 14 00:37:11 1998
Received: from bottom (bottom.caltech.edu) by phobos
	(4.1/DEI:4.43) id AA20057; Mon, 13 Jul 98 21:34:31 PDT
Received: from localhost by bottom with SMTP 
	(SMI-8.6/DEI:4.43) id VAA18830; Mon, 13 Jul 1998 21:34:30 -0700
Date: Mon, 13 Jul 1998 21:34:30 -0700 (PDT)
From: Tim Pearson <tjp at astro.caltech.edu>
X-Sender: tjp at bottom
Reply-To: Tim Pearson <tjp at astro.caltech.edu>
To: fitsbits at fits.cv.nrao.edu
Subject: Re: 64-bit integers in FITS
In-Reply-To: <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov>
Message-Id: <Pine.GSO.3.94.980713205840.18817A-100000 at bottom>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Like William Pence, "I basically have an open mind about the
suggestion to support 64-bit integers in FITS files."

But I would like to remind people that the reason for doing so should
not be because 64-bit integers are convenient to use on some computer
systems, but because there is a need to interchange data that cannot
be represented in any of the current data types (BITPIX=8, 16, 32,
-32, or -64). I can't think of any astronomical data that require such
precision, but perhaps that just reflects the poverty of my
imagination.

If we do add BITPIX=64, perhaps we should also consider intermediate
types like BITPIX=40, 48, etc. which could also be accommodated in the
standard FITS structure and which would save space in the file when
full 64-bit precision is not required.

I am surprised that many people appear to think that FITS is designed
for interchanging computer bit patterns. It is not: it is for
interchanging images (and now tabular data), using as few different
conventions as possible.

This misunderstanding perhaps explains why someone might think that
"BSCALE = 2.0" means something different from "BSCALE = 2". BSCALE
specifies a mathematical operation to be performed on the data array
to construct the image pixel values; how it is done, and with what
precision, is up to the reader. There is certainly no implication that
32-bit (say) floating-point arithmetic should be used if that might
lose precision.

My interpretation of the NOST draft standard (Sec. 5.2.4) is that both
"BSCALE = 2" and "BSCALE = 2.0" are allowed, even though BSCALE is
specified to have a "floating point" value (5.4.2.5). They should be
interpreted identically.


Tim Pearson
Astronomy Dept, California Institute of Technology




From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul 14 10:32:46 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA25641
	for fitsbits-spinner; Tue, 14 Jul 1998 10:32:39 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA25636
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 10:32:36 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA01747
	for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 10:32:33 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA25626
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 10:31:52 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id KAA01736
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 10:31:49 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id KAA11280
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 10:31:48 -0400
Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3)
	id sma011277; Tue Jul 14 10:31:23 1998
Received: from xebec by head-cfa (SMI-8.6/SMI-SVR4)
	id KAA19972; Tue, 14 Jul 1998 10:24:34 -0400
Received: by xebec (SMI-8.6/SMI-SVR4)
	id KAA10763; Tue, 14 Jul 1998 10:24:33 -0400
From: arots at xebec.harvard.edu (Arnold Rots)
Message-Id: <199807141424.KAA10763 at xebec>
Subject: Re: EXTNAME Keyword in Primary HDU
In-Reply-To: <6odrt6$si7 at post.gsfc.nasa.gov> from Louis Giglio at "Jul 13, 98 08:49:42 pm"
To: giglio at hades.gsfc.nasa.gov (Louis Giglio)
Date: Tue, 14 Jul 1998 10:24:33 -0400 (EDT)
Cc: fitsbits at fits.cv.nrao.edu
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Just to be on the safe side, the ASC adopted a convention to use the
keyword HDUNAME: identical to EXTNAME in extensions, and playing the
same role in primary HDUs.

  - Arnold Rots

Louis Giglio wrote:
> The subject pretty much sums up my question.  Is it acceptable to have
> the EXTNAME keyword -- which is explicitly defined for extension HDU's --
> in the primary HDU of a FITS file.  Everything I've read seems to allow
> this without actually explicitly stating that it's legal.
> 
> Thanks,
> Louis
> 

--------------------------------------------------------------------------
Arnold H. Rots                                         AXAF Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 81                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------



From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul 14 11:24:05 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id LAA27110
	for fitsbits-spinner; Tue, 14 Jul 1998 11:23:23 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA27105
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 11:23:20 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id LAA01803
	for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 11:23:18 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA26940
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 11:13:12 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id LAA01784
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 11:13:09 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id LAA23751;
	Tue, 14 Jul 1998 11:13:09 -0400
To: fitsbits at fits.cv.nrao.edu
Date: Tue, 14 Jul 1998 15:12:23 GMT
From: jgadeva at jet.uk (Juan Jose Garcia Adeva)
Message-ID: <35ab7550.114139353 at internet>
Organization: JET Joint Undertaking
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!btnet-peer!btnet!dispose.news.demon.net!demon!newsfeed.nacamar.de!rill.news.pipex.net!pipex!bore.news.pipex.net!pipex!not-for-mail
Subject: I am looking for FITS files where BITPIX = 32 and NAXIS = 2
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Hello,

I am using the FITS format in a project, but I only need to support
files with BITPIX = 32 and NAXIS = 2. I have written some software to
manage this range of files, but I cannot find any example in
http://www.cv.nrao.edu/fits/data/samples. So please, if you have some
FITS files which match this criteria, send them to me, or send me the
address where I can get them. Thanks a lot,

Juanjo


+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| Juan Jose Garcia Adeva      | mailto:jgadeva at jet.uk                |
| Experimental Division II    | Personal Home Page:                  |
| JET Joint Undertaking       |  http://www.wavenet.co.uk/users/jjga |
| Abingdon                    | Company Web Site:                    |
| Oxfordshire OX14 3EA        |  http://www.jet.uk                   |
| United Kingdom              | Phone: +44-1235-464490               |
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+


From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul 14 12:06:11 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id MAA27489
	for fitsbits-spinner; Tue, 14 Jul 1998 12:06:02 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA27484
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 12:05:59 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id MAA01917
	for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 12:05:56 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA27474
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 12:05:20 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA01907
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 12:05:16 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id MAA30186;
	Tue, 14 Jul 1998 12:05:15 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 14 Jul 1998 12:05:04 -0400
From: Don Wells <dwells at nrao.edu>
Message-ID: <x1zpec1kr3.fsf at fits.cv.nrao.edu>
Organization: nrao
Path: newsfeed.cv.nrao.edu!not-for-mail
References: <35ab7550.114139353 at internet>
Reply-To: dwells at nrao.edu
Subject: Re: I am looking for FITS files where BITPIX = 32 and NAXIS = 2
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

>>>>> "Juan" == Juan Jose Garcia Adeva <jgadeva at jet.uk> writes:
    Juan> Hello, I am using the FITS format in a project, but I only
    Juan> need to support files with BITPIX = 32 and NAXIS = 2. .. I
    Juan> cannot find any example in
    Juan> http://www.cv.nrao.edu/fits/data/samples. ..

Try your code on this 262_KB file:

    http://www.cv.nrao.edu/fits/data/tests/incunabula/m87-32.fits

Examine the two text files m87-32.list and m87-32.vf in the same
directory. Note that ORIGIN='KPNO' and DATE='13/09/79': this is the
oldest FITS file with BITPIX=32. The 'vf' file is the output of a FITS
file verifier when reading this file. It asserts that the '/' in the
keyword 'IPPS-B/P' is illegal, however this file is readable by modern
software (Cotton's FITSview code displays the file properly). The
'IPPS' refers to KPNO's Interactive Picture Processing System, the
predecessor of IRAF and 'B/P' is bits per pixel; the IPPS executed on
a CDC 60-bit computer, and floating point pixels were carried in half
words, probably with 20-bit mantissas but I can no longer remember
that detail. The number system of this FITS test file was specially
contrived: BSCALE=1.00000E-06 was used in order to make the
significant bits be spread across the second and third bytes to expose
byte-flip bugs.  Furthermore, the file asserts that BLANK=-2147483648,
so this header is sensitive to differences in implementations of number
conversion routines, the situation discussed by John Davis and Bill
Pence in the unsigned-integer thread in the past few days.

-Don
-- 
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
		    http://www.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA


From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul 14 13:28:51 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA28346
	for fitsbits-spinner; Tue, 14 Jul 1998 13:28:30 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA28341
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 13:28:27 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA02019
	for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 13:28:25 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA28235
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 13:27:22 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id NAA02009
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 13:27:19 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id NAA28560
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 13:27:18 -0400
Received: from silk.gsfc.nasa.gov(128.183.127.210) by palantir.cv.nrao.edu via smap (V1.3)
	id sma028548; Tue Jul 14 13:26:59 1998
Received: by silk.gsfc.nasa.gov id AA02230; Tue, 14 Jul 1998 13:27:23 -0400
Message-Id: <35AB94A8.190BF9E7 at silk.gsfc.nasa.gov>
Date: Tue, 14 Jul 1998 13:26:00 -0400
From: Tom McGlynn <tam at silk.gsfc.nasa.gov>
Organization: NASA/GSFC
X-Mailer: Mozilla 4.04 [en] (WinNT; I)
Mime-Version: 1.0
To: fitsbits at fits.cv.nrao.edu
Cc: Tim Pearson <tjp at astro.caltech.edu>
Subject: Re: 64-bit integers in FITS
References: <Pine.GSO.3.94.980713205840.18817A-100000 at bottom>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

When I wrote a Java FITS reader last year I was considering whether I should
support 64 bit integers and I asked whether there was any need for it.  The response
was underwhelming, but I went ahead and did it anyway.
    (See http://members.home.net/mcglynn/java/nom/tam/fits).

A few points:

   It's very clear how the standard should support this data type, e.g., BITPIX=64
for image data, and TFORM='K' for binary tables.  (16 byte integers will be
a little harder since 'L' is already taken)  This makes adopting it a lot easier.

   I have thought of a few things that people might want to store in 8 byte integers
today or soon.  Presumably this number will increase with time.
For some double precision numbers are not an acceptable alternative.
Note that while we do have ways to indicate that real data is being
encoded as integers  (BZERO/BSCALE, ...) we do not have the inverse: that
value encoded in a double is really an integer.  That's an important thing
to know about an item.

Some things that might need 8 byte integers:
  - As mentioned previously clock times frequently require more than 32 bits.
  - File sizes
  - Verification/encryption keys, e.g., an 8 byte checksum.   Possible rouding errors
     mean that these cannot be stored as doubles.
  - Catalog IDs (e.g., the Monet catalog already has 270 million entries).  Its very useful
     to integer ID's for catalogs but some of the next generations of catalogs will have more than
     4 billion entries.
  - System data (e.g., the one suggestion I had last year was that databases often use
    8 byte quantities).

With regard to Tim Pearson's question of whether we should implement intermediate sizes, the
historical precedent seems to be no:  FITS does not support 24 bit ints.  I think there
are some other problems:  What granularity to support?  What's the format code
in binary tables?    More importantly FITS seems to have evolved such that its
internal formats are compatible with those found on typical hardware.  It would
be a lot more painful to support these intermediate types (e.g., to hande the sign
extension, packing and overflow issues).

There is the question of how to support i*8's on machines which don't have that.
It should be very straightfoward to convert from i*8 to r*8 (not too much worse
than the signed to unsigned conversions) but that won't always be good enough.
This is the one issue that I'd like to understand better before going ahead and
recommending adopting i*8.  What fraction of the community cannot read i*8's?
E.g., do gcc and g77 support it?

            Tom McGlynn



From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul 14 21:30:10 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA00832
	for fitsbits-spinner; Tue, 14 Jul 1998 21:30:00 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA00827
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 21:29:57 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA02421
	for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 21:29:55 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA00194
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 17:30:15 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA02283
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 17:30:12 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id RAA17785;
	Tue, 14 Jul 1998 17:30:11 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 14 Jul 1998 11:00:06 -0700
From: sla at ucolick.borg (Steve Allen)
Message-ID: <6og6b6$oaj$1 at dei.ucolick.org>
Organization: UCO/Lick Observatory
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!logbridge.uoregon.edu!agate!news.ucsc.edu!not-for-mail
References: <35A342B0.DC2A0F4D at obs.unige.ch> <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov>
Subject: Re: 64-bit integers in FITS
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

The performance increase for, e.g., database applications experienced
with Dec Alpha processors is rapidly driving Sun, Intel, HP, and
others to produce hardware and software with 64-bit capabilities.

In article <35AA6D3D.44297AB4 at tetra.gsfc.nasa.gov>,
William Pence  <pence at tetra.gsfc.nasa.gov> wrote:
>- it would be a fairly trivial job to modify the FITS standard to
>specify the format for 64-bit integer images and binary table columns.

It should be noted that introduction of 64-bit integers will probably
create demand for enhancement of the TFORMn = 'P' (Array Descriptor)
data type.  The Appendix for BINTABLE currently suggests this for a
length and offset into a heap following a table.  It's easy to imagine
heaps of more than 2**32 bytes.

Perhaps something as simple as a new TFORMn = 'Q' (64-bit Array Descriptor)
which consists of two 64-bit integers would do the job.

-- 
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.borg     Voice: +1 831 459 3046     FAX (don't): +1 831 459 5244
WWW: http://www.ucolick.borg/~sla               PGP public keys:  see WWW
Junk mail is irrelevant -- my return address has been assimilated.


From owner-fitsbits at kochab.cv.nrao.edu  Tue Jul 14 21:35:57 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id VAA00858
	for fitsbits-spinner; Tue, 14 Jul 1998 21:35:44 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id VAA00853
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 21:35:41 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id VAA02430
	for fitsbits at majordomo.cv.nrao.edu; Tue, 14 Jul 1998 21:35:38 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA00411
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 14 Jul 1998 18:14:16 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id SAA02312
	for <fitsbits at fits.cv.nrao.edu>; Tue, 14 Jul 1998 18:14:14 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id SAA19841;
	Tue, 14 Jul 1998 18:14:13 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 14 Jul 1998 22:10:06 GMT
From: seaman at noao.edu (Rob Seaman)
Message-ID: <6ogkvu$bqj$1 at noao.tuc.noao.edu>
Organization: National Optical Astronomy Observatories
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!newsfeed.internetmci.com!192.52.106.6!ncar!noao!noao.edu!seaman
References: <Pine.GSO.3.94.980713205840.18817A-100000 at bottom> <35AB94A8.190BF9E7 at silk.gsfc.nasa.gov>
Subject: Re: 64-bit integers in FITS
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Tom McGlynn <tam at silk.gsfc.nasa.gov> writes:

> Note that while we do have ways to indicate that real data is being
> encoded as integers  (BZERO/BSCALE, ...) we do not have the inverse: that
> value encoded in a double is really an integer.  That's an important thing
> to know about an item.

Well, BSCALE and BZERO were originally designed for packing reals into
integer pixels before the floating point convention, but they now can
also mean that 16 bit integers are unsigned, so FITS has no reliable
way to indicate that the original datatype was different than the FITS
datatype in either direction.  This seems like a pretty esoteric thing
to rely on knowing in any event.

> Some things that might need 8 byte integers:
>   - As mentioned previously clock times  [...]
>   - File sizes
>   - Verification/encryption keys, e.g., an 8 byte checksum.  [...]
>   - Catalog IDs  [...]
>   - System data  [...]

However, can anybody suggest a current need for images with 64 bit
pixels?  ...and do tables and images have to support the same set of
datatypes?  "Exotic" image data arrays are likely to be written as
binary tables anyway.

On the other hand, 64 bits may not be enough for some of the applications
listed above.  Encryption keys and digital signatures, for instance, can
require hundreds or thousands of bits (and a proportionately large number
of ASCII digits or characters).  A character string may be the only thing
that suffices for table fields (or header keywords) that require extended
precision.

> With regard to Tim Pearson's question of whether we should implement
> intermediate sizes, the historical precedent seems to be no:  FITS does
> not support 24 bit ints.

Note that the hubbub about unsigned integers is also something of a
historical artifact.  If a signed integer datatype is large enough to
contain the entire range of the unsigned integers being generated (e.g.,
packing 15 bit unsigned data into 16 bit signed pixels), then there is
no problem - other than some slight overhead that may perhaps be involved
in this easy type conversion.  And if the signed datatype is not large
enough (trying to fit 18 bits into a short integer), then some higher
precision datatype is needed entirely.

The main reason for worrying about unsigned integers is that the
affordable state of the art for A/D converters is 16 bits and we don't
want to waste the high order bit.  Folks building instruments with
18 bit A/D's won't be concerned with packing them into short integers
using BZERO.

Perhaps rather than worrying about unsigned integers (or 24 bit ints or
whatever), we should get back to devising a speedy FITS compression scheme
that would allow using 32 (or even 64) bit integer pixels for intermediate
precision data in a space-efficient manner.

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 owner-fitsbits at kochab.cv.nrao.edu  Wed Jul 15 12:23:42 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id MAA18258
	for fitsbits-spinner; Wed, 15 Jul 1998 12:23:11 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA18253
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 15 Jul 1998 12:23:06 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id MAA03276
	for fitsbits at majordomo.cv.nrao.edu; Wed, 15 Jul 1998 12:23:03 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA18232
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 15 Jul 1998 12:21:43 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA03266
	for <fitsbits at fits.cv.nrao.edu>; Wed, 15 Jul 1998 12:21:40 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id MAA12338;
	Wed, 15 Jul 1998 12:21:39 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 15 Jul 1998 16:01:58 GMT
From: hodge at bowline.stsci.edu (Phil Hodge)
Message-ID: <6oijpm$4um$1 at tnm.stsci.edu>
Organization: Space Telescope Science Institute
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!howland.erols.net!cs.utexas.edu!ennfs.eas.asu.edu!noao!stsci.edu!not-for-mail
References: <199807121936.PAA04862 at aluche.mit.edu> <35AA384F.1BE21420 at tetra.gsfc.nasa.gov>
Subject: Re: Unsigned integer support in NOST 100-1.2
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Bill Pence wrote:

> In the previous debate a few years about about adding new unsigned
> integer datatypes to FITS I had argued in favor of the proposal. 
> However, I have since come to appreciate that the current FITS format
> already fully supports unsigned integers (16 and 32 bit at least), hence
> I would now oppose any change to the Standard in this regard.  FITS is
> able to store unsigned 16 and 32 bit integers in an efficient format
> that is easy to read and write.  This is all that is required.  The
> transformation between the internal FITS representation and the  machine
> representation on a particular computer of the same unsigned integer
> value is trivial: flip the value of the most significant bit (bit 32 or
> 16) and also swap the order of the bytes on little endian machines like
> IBM PCs.  

This is trivial to implement, yes, but it's not transparent to many
people who would read the header.  It's rather esoteric, in fact.
I think that FITS should support unsigned 16-bit and 32-bit integers
using notation (e.g. a DATATYPE keyword) that would be clear to an
intelligent person who is not necessarily an expert on FITS.

Rob Seaman wrote:

> Perhaps rather than worrying about unsigned integers (or 24 bit ints or
> whatever), we should get back to devising a speedy FITS compression scheme
> that would allow using 32 (or even 64) bit integer pixels for intermediate
> precision data in a space-efficient manner.

Would that be 32-bit unsigned pixels?

						Phil


From owner-fitsbits at kochab.cv.nrao.edu  Wed Jul 15 13:43:29 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA18801
	for fitsbits-spinner; Wed, 15 Jul 1998 13:42:59 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA18795
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 15 Jul 1998 13:42:56 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA03380
	for fitsbits at majordomo.cv.nrao.edu; Wed, 15 Jul 1998 13:42:51 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA18720
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 15 Jul 1998 13:39:59 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id NAA03368
	for <fitsbits at fits.cv.nrao.edu>; Wed, 15 Jul 1998 13:39:56 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id NAA18830;
	Wed, 15 Jul 1998 13:39:55 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 15 Jul 1998 17:39:40 GMT
From: davis at space.mit.edu (John E. Davis)
Message-ID: <slrn6qplrd.u0o.davis at mygir.davis.net>
Organization: Center for Space Research
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!eecs-usenet-02.mit.edu!davis
References: <Pine.GSO.3.94.980713205840.18817A-100000 at bottom>
Subject: Re: 64-bit integers in FITS
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On 14 Jul 1998 09:51:10 -0400, Tim Pearson <tjp at astro.caltech.edu>
wrote:
>I am surprised that many people appear to think that FITS is designed
>for interchanging computer bit patterns. It is not: it is for
>interchanging images (and now tabular data), using as few different
>conventions as possible.

   My main concern is that FITS is not being used to simply exchange
images between systems (which it does well), but is used as a general
purpose data archive format.  I have no problems with this concept as
long as the file format is well defined in the absence of a reader.  I
remain unconvinced that this requirement is fulfilled.

   If FITS should not be used as a general purpose archive format,
then it would be nice if the scope of the file format was spelled out
in the NOST document.  Some people believe that all programs used for
processing astrophysical data should read and write FITS files and
communicate with each other using such files.  I believe that this
practice goes beyond the original scope of the FITS file format.

--John


From owner-fitsbits at kochab.cv.nrao.edu  Wed Jul 15 17:17:29 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id RAA03981
	for fitsbits-spinner; Wed, 15 Jul 1998 17:17:14 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA03976
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 15 Jul 1998 17:17:11 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id RAA03791
	for fitsbits at majordomo.cv.nrao.edu; Wed, 15 Jul 1998 17:17:08 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA03904
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 15 Jul 1998 16:52:21 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id QAA03760
	for <fitsbits at fits.cv.nrao.edu>; Wed, 15 Jul 1998 16:52:18 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id QAA04453
	for <fitsbits at fits.cv.nrao.edu>; Wed, 15 Jul 1998 16:52:16 -0400
Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3)
	id sma004444; Wed Jul 15 16:52:03 1998
Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109])
          by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP
	  id QAA26229 for <fitsbits at fits.cv.nrao.edu>; Wed, 15 Jul 1998 16:51:33 -0400 (EDT)
Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4)
	id QAA27106; Wed, 15 Jul 1998 16:51:31 -0400
Message-ID: <35AD1651.945E6380 at tetra.gsfc.nasa.gov>
Date: Wed, 15 Jul 1998 16:51:29 -0400
From: William Pence <pence at tetra.gsfc.nasa.gov>
Organization: HEASARC
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: fitsbits at fits.cv.nrao.edu
Subject: Re: 64-bit integers in FITS
References: <Pine.GSO.3.94.980713205840.18817A-100000 at bottom> <35AB94A8.190BF9E7 at silk.gsfc.nasa.gov> <6ogkvu$bqj$1 at noao.tuc.noao.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Rob Seaman wrote:

> However, can anybody suggest a current need for images with 64 bit
> pixels?  ...and do tables and images have to support the same set of
> datatypes?  "Exotic" image data arrays are likely to be written as
> binary tables anyway.

>From the implementation point of view, a FITS image is just a special
case of a table with 1 row and 1 vector column.  So if one is going to
support 64-bit integer table columns, then very little else needs to be
added to support 64-bit images.

____________________________________________________________________
Dr. William Pence                          pence at tetra.gsfc.nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)



From owner-fitsbits at kochab.cv.nrao.edu  Wed Jul 15 17:18:04 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id RAA03997
	for fitsbits-spinner; Wed, 15 Jul 1998 17:18:02 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA03992
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 15 Jul 1998 17:17:59 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id RAA03796
	for fitsbits at majordomo.cv.nrao.edu; Wed, 15 Jul 1998 17:17:56 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA03941
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 15 Jul 1998 17:06:54 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA03778
	for <fitsbits at fits.cv.nrao.edu>; Wed, 15 Jul 1998 17:06:52 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id RAA04591
	for <fitsbits at fits.cv.nrao.edu>; Wed, 15 Jul 1998 17:06:50 -0400
Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3)
	id sma004588; Wed Jul 15 17:06:37 1998
Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109])
          by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP
	  id RAA26473 for <fitsbits at fits.cv.nrao.edu>; Wed, 15 Jul 1998 17:06:06 -0400 (EDT)
Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4)
	id RAA27121; Wed, 15 Jul 1998 17:06:05 -0400
Message-ID: <35AD19BD.6CDD6A9C at tetra.gsfc.nasa.gov>
Date: Wed, 15 Jul 1998 17:06:05 -0400
From: William Pence <pence at tetra.gsfc.nasa.gov>
Organization: HEASARC
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: fitsbits at fits.cv.nrao.edu
Subject: Re: Unsigned integer support in NOST 100-1.2
References: <199807121936.PAA04862 at aluche.mit.edu> <35AA384F.1BE21420 at tetra.gsfc.nasa.gov> <6oijpm$4um$1 at tnm.stsci.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Phil Hodge wrote:

> This is trivial to implement, yes, but it's not transparent to many
> people who would read the header.  It's rather esoteric, in fact.
> I think that FITS should support unsigned 16-bit and 32-bit integers
> using notation (e.g. a DATATYPE keyword) that would be clear to an
> intelligent person who is not necessarily an expert on FITS.

The FITS standard allows optional characters following the datatype
character in the TFORMn keyword, so one could adopt a convention
something like:

TFORM1  = '1IU'               / datatype is unsigned 16-bit integer
TZERO1  =               32768

or

TFORM1  = '1I(unsigned)'      / datatype is unsigned 16-bit integer
TZERO1  =               32768

This doesn't require any change to the FITS standard, and the TZEROn
keyword is still required, but at least it would be clearer to  people
reading the header that this is an unsigned integer column. 

____________________________________________________________________
Dr. William Pence                          pence at tetra.gsfc.nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)



From owner-fitsbits at kochab.cv.nrao.edu  Thu Jul 16 10:15:58 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA29260
	for fitsbits-spinner; Thu, 16 Jul 1998 10:14:07 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA29255
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 16 Jul 1998 10:14:03 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA04851
	for fitsbits at majordomo.cv.nrao.edu; Thu, 16 Jul 1998 10:14:00 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id EAA23103
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 16 Jul 1998 04:02:52 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id EAA04356
	for <fitsbits at fits.cv.nrao.edu>; Thu, 16 Jul 1998 04:02:48 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id EAA14378
	for <fitsbits at fits.cv.nrao.edu>; Thu, 16 Jul 1998 04:02:44 -0400
Received: from ujf.ujf-grenoble.fr(193.54.232.33) by palantir.cv.nrao.edu via smap (V1.3)
	id sma014372; Thu Jul 16 04:02:29 1998
Received: from gagax5.obs.ujf-grenoble.fr (gagax5.obs.ujf-grenoble.fr [195.220.79.15])
	by ujf.ujf-grenoble.fr (8.8.5/8.8.5) with ESMTP id JAA05863;
	Thu, 16 Jul 1998 09:56:08 +0200 (MET DST)
Received: (from forveill at localhost) by gagax5.obs.ujf-grenoble.fr (8.7.6/8.6.9) id JAA78136; Thu, 16 Jul 1998 09:56:08 +0200
From: Thierry Forveille <Thierry.Forveille at obs.ujf-grenoble.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <13741.45592.173971.583641 at gagax5.obs.ujf-grenoble.fr>
Date: Thu, 16 Jul 1998 09:56:08 +0200 (DFT)
To: William Pence <pence at tetra.gsfc.nasa.gov>
Cc: fitsbits at fits.cv.nrao.edu
Subject: Re: Unsigned integer support in NOST 100-1.2
In-Reply-To: <35AD19BD.6CDD6A9C at tetra.gsfc.nasa.gov>
References: <199807121936.PAA04862 at aluche.mit.edu>
	<35AA384F.1BE21420 at tetra.gsfc.nasa.gov>
	<6oijpm$4um$1 at tnm.stsci.edu>
	<35AD19BD.6CDD6A9C at tetra.gsfc.nasa.gov>
X-Mailer: VM 6.49 under Emacs 19.34.9
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

William Pence writes:
 > The FITS standard allows optional characters following the datatype
 > character in the TFORMn keyword, so one could adopt a convention
 > something like:
 > 
 > TFORM1  = '1IU'               / datatype is unsigned 16-bit integer
 > TZERO1  =               32768
 > 
 > or
 > 
 > TFORM1  = '1I(unsigned)'      / datatype is unsigned 16-bit integer
 > TZERO1  =               32768
 > 
 > This doesn't require any change to the FITS standard, and the TZEROn
 > keyword is still required, but at least it would be clearer to  people
 > reading the header that this is an unsigned integer column. 
 > 
Really I don't see the point of keeping track of the unsigned origin of
a datum. As mentioned earlier in this discussion, the purpose of FITS is
to transfer numerical information, not bit patterns. Whether a column
originates from unsigned IEEE 16 bits integers or 30 bits one from a CDC
mainframe is irrelevant for the receiving program, as long as it fits
in its specified format. Most modern image processing systems will
convert it to 32 bits integers anyway (if not to floats) for the sake
of efficiency.

Actually, all people I have heard arguing for an unsigned 16 bit format
(nobody seems to demand 32 bits unsigneds) really want to use it to store
floating point data affected by quantisation noise ;)



From owner-fitsbits at kochab.cv.nrao.edu  Thu Jul 16 10:15:58 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id KAA29267
	for fitsbits-spinner; Thu, 16 Jul 1998 10:14:39 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA29262
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 16 Jul 1998 10:14:36 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id KAA04856
	for fitsbits at majordomo.cv.nrao.edu; Thu, 16 Jul 1998 10:14:34 -0400 (EDT)
Received: from cv3.cv.nrao.edu (root at cv3.cv.nrao.edu [192.33.115.2])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id HAA28899
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 16 Jul 1998 07:24:27 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by cv3.cv.nrao.edu (8.8.5/8.8.5/CV-2.7) with ESMTP id HAA26055
	for <fitsbits at nrao.edu>; Thu, 16 Jul 1998 07:24:24 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id HAA16775
	for <fitsbits at nrao.edu>; Thu, 16 Jul 1998 07:24:23 -0400
Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3)
	id sma016772; Thu Jul 16 07:24:21 1998
Received: from bynars by head-cfa (SMI-8.6/SMI-SVR4)
	id HAA15299; Thu, 16 Jul 1998 07:20:57 -0400
Message-Id: <199807161120.HAA15299 at head-cfa>
To: fitsbits at nrao.edu
Subject: release of saord 1.8
cc: eric at head-cfa.harvard.edu
Date: Thu, 16 Jul 1998 07:20:57 -0400
From: Eric Mandel <eric at head-cfa.harvard.edu>
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk


*******************************************************************************

		     The SAO R&D Software Suite
			 Public Release 1.8
		            16 July 1998

			   containing:

		SAOimage: The Next Generation (SAOtng)
		The X Public Access mechanism (XPA)

			   as well as:

	      	The ASSIST Graphical User Interface	
		The XDir directory browser
		The IRAF ncl with tcsh line editing

	    Contributors to this software include:

	  Eric Mandel		Smithsonian Astrophysical Observatory
	  William Joye		Smithsonian Astrophysical Observatory
	  Saleem Mukhtar	Jet Propulsion Laboratory
	  Doug Tody		National Optical Astronomy Observatories

	    with important assistance from:

	  Alberto Accomazzi	Smithsonian Astrophysical Observatory
	  Mark S. Ackerman	University of California, Irvine
	  Doug Mink		Smithsonian Astrophysical Observatory
	  John Roll		Smithsonian Astrophysical Observatory
	  Dennis Schmidt	Smithsonian Astrophysical Observatory
	  Ralph Swick		The Web Consortium


What's New and Significant in this release?
-------------------------------------------
This release of the SAO R&D package contains support for new types of
FITS data.  SAOtng 1.8 can display FITS image extensions, FITS binary
tables, n-D FITS images, compressed FITS data, and FITS files that are
found on the Web. In addition, SAOtng can display raw event lists (i.e.,
binary files containing events with a known record structure) -- useful
for X-ray lab data.

For X-ray astronomers, the ability to image FITS binary tables is
particularly significant. Our new support for FITS binary tables includes
a technique for filtering photon events in FITS tables.  This filtering
scheme is several times faster than previous schemes (such as IRAF QPOE
filtering) and also supports full C-syntax in the filter specification.
In addition to standard filtering using QPOE-style range lists, you
now can filter one attribute against another (e.g., "pi==pha+1") or
use arithmetic functions (e.g., "pha%2==1" to get odd pha values).
Full boolean algebra is supported, as is spatial region filtering
(e.g., "circle(400,450,50) && pie(400,450,90)").

New support for manipulating region marker attributes has been added.
It now is possible to fix attributes such as position, size, etc. on
one or more markers to prevent accidental resize or movement.  This
is especially useful when performing catalog marking.

Finally, a number of bug fixes and other relatively minor improvements
have been made, most notably to the internal memory management scheme.

Introduction
------------ 
We are pleased to announce the availability of a new public release
(version 1.8) of the SAO R&D software tree containing, among other
things, a new and improved version of SAOtng. We invite you to
retrieve the software and use it for your astronomical analysis (and
other?) needs.

[Historic Note: this is "the release formerly known as 1.7.2", which was
available from 4 June 1998 to 5 June 1998. Oops! We had to withdraw this
release because of a bug that was unacceptable to our quality control.]

SAOimage: The Next Generation (SAOtng)
--------------------------------------
SAOtng is a new version of the popular SAOimage display program.  It
is a superset of the ximtool program developed at NOAO for IRAF and as
such, utilizes the NOAO widget server (included in this package).  It
also incorporates the X Public Access mechanism to allow external
processes to access and control its data, GUI functions, and
algorithms.  SAOtng supports direct display of IRAF images and FITS
images (and easily can support other file formats), multiple frame
buffers, region/cursor manipulation, several scale algorithms, many
colormaps, and easy communication with external analysis tasks.  It is
highly configurable and extensible to meet the evolving needs of the
astronomical community.

The X Public Access Mechanism
----------------------------
To add 'open software' functionality to programs such as SAOtng, we
have developed the 'X Public Access' mechanism (XPA).  Built on top of
the existing Xt selection interface, XPA allows an Xt program to
define points of public access through which data and commands can be
exchanged with external programs.  Its simple programming and
command-line interface is designed so that arbitrarily large amounts
of data can be transferred to and from Xt programs using XPA.  Also,
the data associated with a given access point can be read and written
simultaneously.  XPA is the precursor to a more generalized message
bus system that will be built as collaboration between SAO and NOAO.

Platforms
---------
The SAO R&D software has been built on the following platforms:

	Sun Sparc	Solaris 2.5, 2.6	OpenWindows 3.x
	Sun Sparc	SunOs 4.1.3, 4.1.4	X11R5/R6.3
	HP9000/735	HP/UX A.09.01		X11R5
	SGI		IRIX 5.2, 5.3, 6.2	X11R5/R6
	DEC Alpha	OSF1 4.0		X11R6
	Gateway P5-90	Slackware 2.2.5		X11R6
			RedHat 5.0		X11R6

We develop and run the software mainly on Suns, but time has been
spent with the other (borrowed) platforms, especially 64-bit Alphas.
Ports to other systems should be relatively easy at this stage.
If you do a port (or try to and have problems), please let us know.

Information and Availability
---------------------------
Please visit the SAO R&D Group Home Page for news, updates, and downloads:

	http://hea-www.harvard.edu/RD/

Our home page will help you to download the source code distribution
and/or binary distributions for various platforms.

Alternatively, the SAO R&D software suite can be retrieved directly
via anonymous ftp from sao-ftp.harvard.edu in the pub/rd directory.
The source tree is contained in a compressed tar file called
saord.tar.Z. The binary distributions also are available at this site.
We recommend using the binary distributions where possible.

The unpacked tar file requires approximately 20 Mb of disk space.
The build will require approximately double that amount, depending
on the platform.

SAOtng Mailing List
-------------------
An saord mailing list (saord-announce) have been set up using Brent
Chapman's "Majordomo" mailing list manager.  Subscribers to this list
will receive periodic status reports, release notices, and other
useful information concerning SAORD software.  If you wish to become a
subscriber, please send an e-mail message to:

	majordomo at head-cfa.harvard.edu	

The mail should contain the following command in the body of the
message:

	subscribe saord-announce

If either you or your mailer add a signature to your mail message,
please add the following command after the "subscribe" command(s):

	end

(Note that we have combined the old saotng-announce and assist-announce
lists into this saord-announce list, so it is not necessary to join the
new list if you subscribed to one of the old lists.)

Acknowledgments
----------------
Much of this software was developed at SAO by the HEAD Software R&D
group with the significant help of collaborators across the country.
The work at SAO was performed in large part under a grant from NASA's
Applied Information System Research Program (NAG5-3996), with support
from the AXAF Science Center (NAS8-39073).  SAOtng, ASSIST, and XPA
are embodiments of an evolving software cooperation philosophy and
practice we hope to bring to astronomy and other disciplines.  They
reflect our efforts to understand how software systems (and people)
can act in concert without sacrificing their independence.

For more information (or to complain or encourage!)
---------------------------------------------------
Please send mail to: saord at cfa.harvard.edu.  We respond to questions,
bug reports, suggestions, gripes ...


						Eric Mandel
						eric at cfa.harvard.edu



From owner-fitsbits at kochab.cv.nrao.edu  Thu Jul 16 11:51:11 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id LAA00822
	for fitsbits-spinner; Thu, 16 Jul 1998 11:50:47 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA00817
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 16 Jul 1998 11:50:44 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id LAA05029
	for fitsbits at majordomo.cv.nrao.edu; Thu, 16 Jul 1998 11:50:41 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA00804
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 16 Jul 1998 11:49:15 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id LAA05013
	for <fitsbits at fits.cv.nrao.edu>; Thu, 16 Jul 1998 11:49:12 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id LAA08949;
	Thu, 16 Jul 1998 11:49:11 -0400
To: fitsbits at fits.cv.nrao.edu
Date: Thu, 16 Jul 1998 11:39:11 -0400
From: "William F. Wyatt" <REMOVEwyattTHIS at cfa.harvard.edu>
Message-ID: <35AE1E9F.6021 at cfa.harvard.edu>
Organization: Harvard-Smithsonian Center for Astrophysics
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!gatech!128.10.2.10.MISMATCH!purdue!oitnews.harvard.edu!cfanews.harvard.edu!131.142.10.146
References: <Pine.OSF.3.95.980710180000.8773P-100000 at poseidon.ifctr.mi.cnr.it> <slrn6qf7t0.rkd.davis at mygir.davis.net>
Subject: Re: Comments on NOST 100-1.2
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On 10 Jul 1998 13:06:38 -0400, Lucio Chiappetti <lucio at ifctr.mi.cnr.it>
wrote:
[...]
>  And I doubt they are of practical use in common conditions (I see that
>  peoples in banks and similar tend to have large databases, but I ever
>  doubt to need a > 2GB file  ... or to have > 2GB physical memory ... and
>  since I do not have that, why should I need 64-bit addresses ? In fact
[...]

And I used to think 64 kilobytes of DG Nova memory was fantastic.

Here at SAO, we're working on a CCD mosaic that, if used at full
resolution, will generate about 680 MBytes per image. Thats about 340
megapixels (16-bit). If you want to mosaic several of these images into
a single file (should that seem useful at the time), it'll easily
exceed 2 GB. And that's without floating it.

-- 
Bill Wyatt (REMOVEwyattTHIS at cfa0.harvard.edu) "remove this" for email
   Smithsonian Astrophysical Observatory  (Cambridge, MA, USA)


From owner-fitsbits at kochab.cv.nrao.edu  Thu Jul 16 13:04:59 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA01017
	for fitsbits-spinner; Thu, 16 Jul 1998 13:04:51 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA01012
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 16 Jul 1998 13:04:48 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA05153
	for fitsbits at majordomo.cv.nrao.edu; Thu, 16 Jul 1998 13:04:45 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id MAA00988
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 16 Jul 1998 12:53:12 -0400 (EDT)
Received: from zia.aoc.NRAO.EDU (zia.aoc.nrao.edu [146.88.1.4])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id MAA05124
	for <fitsbits at fits.cv.nrao.edu>; Thu, 16 Jul 1998 12:53:09 -0400 (EDT)
Received: from nrao.edu (bglenden [146.88.10.81])
	by zia.aoc.NRAO.EDU (8.8.7/8.8.7) with ESMTP id KAA00335;
	Thu, 16 Jul 1998 10:53:04 -0600 (MDT)
Message-ID: <35AE30C9.FE6BD59 at nrao.edu>
Date: Thu, 16 Jul 1998 10:56:41 -0600
From: Brian Glendenning <bglenden at cv3.cv.nrao.edu>
Organization: National Radio Astronomy Observatory
X-Mailer: Mozilla 4.05 [en] (Win95; U)
MIME-Version: 1.0
To: "William F. Wyatt" <REMOVEwyattTHIS at cfa.harvard.edu>
CC: fitsbits at fits.cv.nrao.edu
Subject: Re: Comments on NOST 100-1.2
References: <Pine.OSF.3.95.980710180000.8773P-100000 at poseidon.ifctr.mi.cnr.it> <slrn6qf7t0.rkd.davis at mygir.davis.net> <35AE1E9F.6021 at cfa.harvard.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

In radio astronomy, multi-gigabyte visibility (raw interferometer) are
not uncommon for the VLBA. Large images are also not unheard of, for
example a VLA image of M33 in HI which has been created is 4096x4096x256
(16GB), and it might be reimaged at 8192x8192x256 (64GB).

Of course these examples can be represented in FITS now without a 64-bit
type.

Brian


From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 20 11:24:43 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id LAA10702
	for fitsbits-spinner; Mon, 20 Jul 1998 11:23:42 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA10697
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 11:23:39 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id LAA09350
	for fitsbits at majordomo.cv.nrao.edu; Mon, 20 Jul 1998 11:23:36 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id KAA10388
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 10:46:25 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id KAA09304
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 10:46:22 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id KAA24213
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 10:46:21 -0400
Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3)
	id sma024210; Mon Jul 20 10:46:17 1998
Received: from xebec by head-cfa (SMI-8.6/SMI-SVR4)
	id KAA02696; Mon, 20 Jul 1998 10:39:32 -0400
Received: by xebec (SMI-8.6/SMI-SVR4)
	id KAA11962; Mon, 20 Jul 1998 10:39:32 -0400
From: arots at xebec.harvard.edu (Arnold Rots)
Message-Id: <199807201439.KAA11962 at xebec>
Subject: Re: Comments on NOST 100-1.2
In-Reply-To: <slrn6qi9iu.4p5.davis at aluche.mit.edu> from "John E. Davis" at "Jul 12, 98 09:10:58 pm"
To: davis at space.mit.edu, pence at tetra.gsfc.nasa.gov
Date: Mon, 20 Jul 1998 10:39:31 -0400 (EDT)
Cc: fitsbits at fits.cv.nrao.edu
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=UNKNOWN-8BIT
Content-Transfer-Encoding: 8bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Unless I am unusually dense (which always remains a possibility o
Monday mornings), the attached two paragraphs from Bill Pence's
message seem to be at odds with each other and do not really address
the issue John Davis was raising.

If John is right in his interpretation of what cfitsio does, things
are far from transparent to the programmer and we have a serious
problem - a problem that cannot be dismissed with "it's your
compiler's fault".  I tried his little test on a Sparc, using gcc
and, not surprisingly, it failed in the same way.  Hence, using gcc on
a 32-bit machine (hardly an uncommon combination) will get one into
trouble.

It means that anybody using the unsigned integer facilities in cfitsio
is at risk: all purportedly unsigned longs will come out one too small
on a common platform-compiler combination.  The fact that we have not
heard any complaints probably has to do with the rather recent
introduction of this feature which undoubtedly has not made it into a
lot of application code.

It would seem prudent, though less elegant, to test whether
BZERO/TZERO represents the signed/unsigned hack (yes, it _is_ a hack)
and then simply flip the most significant bit.

Could Bill comment onm this?  Do we have a serious problem or do we
misunderstand the way things are handled in cfitsio?

Thanks,

  - Arnold Rots


William Pence wrote:
> The more important issue for programmers, I believe, is that standard
> FITS software like the CFITSIO library should provide a transparent
> interface for reading and writing unsigned integers in FITS files.
> CFITSIO provides a whole family of routines for reading or writing data
> of any supported datatype, including unsigned short, unsigned int, and
> unsigned long (in the C language interface) to FITS images or tables. 
> When using CFITSIO, the programmer does not need to be concerned in any
> way with how the data values are internally represented in the FITS
> file.  All the business with setting or reading the BZERO keyword value,
> etc. is all handled internally by the interface routines.
> 
> Finally, John Davis raised the objection that the BZERO keyword =
> 2147483648 that is used to represent unsigned 32-bit integers in FITS is
> not a valid 32-bit signed integer with some particular compilers (it is
> a valid signed integer value with many other compilers, however).  This
> is not a problem with the FITS format itself, but instead just
> illustrates that the implementation of FITS readers and writers on any
> given platform must be able to deal with the limitations of that
> platform.  The similar sorts of issues have to be addressed when
> reading/writing FITS files in Fortran, which doesn't even support an
> unsigned integer datatype at all.


John E. Davis wrote:
> On 12 Jul 1998 10:43:53 -0400, Thierry Forveille <Thierry.Forveille at obs.ujf-grenoble.fr>
> wrote:
> >I must say I have never seen any convincing argument for supporting
> >unsigned values. The present "hack" as you call it offers all the
> >functionalities for no cost, while adding unsigned as an additional
> >supported format would cost significant extra code to everybody for no
> >additional value. To me Occam's razor says it should stay out...
> 
> Please correct me if I am wrong, but my main objection to this
> convention is that it is inherently non-portable because the BZERO
> value that must be used is outside the range of the integer data type.
> For example, to represent an unsigned 32bit integer, BZERO must be set
> to 2147483648 in the fits file, which is outside the range of a 32 bit
> signed integer.  Why is this a problem?  It is a problem because
> parsing it as a 32 bit integer may result in its truncation.
> Specifically, CFITSIO uses the strtol function call to parse these
> values and this function will truncate 2147483648 to 2147483647.
> 
> To see this, consider:
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> int main ()
> {
>    long i;
>    char *s;
> 
>    s = "2147483648";
>    i = strtol (s, NULL, 10);
>    fprintf (stdout, "%s = %ld\n", s, i);
> 
>    s = "2147483647";
>    i = strtol (s, NULL, 10);
>    fprintf (stdout, "%s = %ld\n", s, i);
>    
>    return 0;
> }
> 
>      
> Compiled with gcc on my Linux system, this produces:
> 
>    2147483648 = 2147483647
>    2147483647 = 2147483647
> 
> The man page for strtol indicates:
> 
> RETURN VALUE
>        The  strtol()  function  returns the result of the conver
>        sion, unless the value would underflow or overflow.  If an
>        underflow  occurs, strtol() returns LONG_MIN.  If an over
>        flow occurs, strtol() returns LONG_MAX.   In  both  cases,
>        errno is set to ERANGE.
> 
> It is possible avoid strtol with a different function, but one would
> still need to perform integer multiplications which would result in
> overflow.  About the only portable alternative would be to use double
> precision arithmetic but even that may not be sufficient if you want
> to use this convention to represent 64 bit unsigned values.
> 
> So, without real support for unsigned types, I maintain that this
> convention is flawed.
> 
> Thanks,
> --John
> 
> 

--------------------------------------------------------------------------
Arnold H. Rots                                         AXAF Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 81                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 20 16:01:19 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id QAA15994
	for fitsbits-spinner; Mon, 20 Jul 1998 16:01:03 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id QAA15988
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 16:01:00 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id QAA09699
	for fitsbits at majordomo.cv.nrao.edu; Mon, 20 Jul 1998 16:00:56 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id PAA15824
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 15:56:18 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id PAA09680
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 15:56:15 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id PAA18319
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 15:56:14 -0400
Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3)
	id sma018313; Mon Jul 20 15:55:52 1998
Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109])
          by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP
	  id PAA14411; Mon, 20 Jul 1998 15:55:21 -0400 (EDT)
Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4)
	id PAA03045; Mon, 20 Jul 1998 15:55:18 -0400
Message-ID: <35B3A0A6.46CC9854 at tetra.gsfc.nasa.gov>
Date: Mon, 20 Jul 1998 15:55:18 -0400
From: William Pence <pence at tetra.gsfc.nasa.gov>
Organization: HEASARC
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Arnold Rots <arots at xebec.harvard.edu>
CC: fitsbits at fits.cv.nrao.edu
Subject: Re: Comments on NOST 100-1.2
References: <199807201439.KAA11962 at xebec>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Regarding Arnold's questions, I have checked the CFITSIO code and run some
test programs to verify that CFITSIO does read and write unsigned integers
correctly.  Internally, CFITSIO reads and writes the TZEROn or BZERO keyword
as a double, not as an integer, so CFITSIO is unaffected by the supported
range of the integer datatype in this case.  Also, as Arnold suggested,
CFITSIO does test for the special values of BZERO or TZEROn that represent
unsigned integers, and then just flips the sign bit, instead of adding
BZERO, for better reading or writing efficiency. In summary, then, there is
no problem using CFITSIO to read or write unsigned integers in FITS file.

John Davis' example, does however show that CFITSIO currently does not check
for overflows when reading keyword values (for both integers or reals). 
Thus, for example, when reading the BZERO = 2147483648 keyword as a signed
4-byte integer, the value may be silently truncated to the maximum value of
a signed integer (this behaviour is compiler dependent).  Similarly, trying
to read a real keyword with a value = 1.5E+32 as an integer, could also
return a value = 2147483647 without any errors.  This behavior is not what
most users would want or expect, so the next release of CFITSIO will contain
more range checking code that will return an error status whenever an
overflow occurs while reading keywords.

-Bill Pence

Arnold Rots wrote:
> 
> Unless I am unusually dense (which always remains a possibility o
> Monday mornings), the attached two paragraphs from Bill Pence's
> message seem to be at odds with each other and do not really address
> the issue John Davis was raising.
> 
> If John is right in his interpretation of what cfitsio does, things
> are far from transparent to the programmer and we have a serious
> problem - a problem that cannot be dismissed with "it's your
> compiler's fault".  I tried his little test on a Sparc, using gcc
> and, not surprisingly, it failed in the same way.  Hence, using gcc on
> a 32-bit machine (hardly an uncommon combination) will get one into
> trouble.
> 
> It means that anybody using the unsigned integer facilities in cfitsio
> is at risk: all purportedly unsigned longs will come out one too small
> on a common platform-compiler combination.  The fact that we have not
> heard any complaints probably has to do with the rather recent
> introduction of this feature which undoubtedly has not made it into a
> lot of application code.
> 
> It would seem prudent, though less elegant, to test whether
> BZERO/TZERO represents the signed/unsigned hack (yes, it _is_ a hack)
> and then simply flip the most significant bit.
> 
> Could Bill comment onm this?  Do we have a serious problem or do we
> misunderstand the way things are handled in cfitsio?
> 
> Thanks,

____________________________________________________________________
Dr. William Pence                          pence at tetra.gsfc.nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 20 17:04:44 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id RAA16242
	for fitsbits-spinner; Mon, 20 Jul 1998 17:04:37 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA16237
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 17:04:34 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id RAA09807
	for fitsbits at majordomo.cv.nrao.edu; Mon, 20 Jul 1998 17:04:31 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA16223
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 17:01:01 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA09788
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 17:00:58 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id RAA19955
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 17:00:56 -0400
Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3)
	id sma019947; Mon Jul 20 17:00:35 1998
Received: from xebec by head-cfa (SMI-8.6/SMI-SVR4)
	id QAA03254; Mon, 20 Jul 1998 16:53:50 -0400
Received: by xebec (SMI-8.6/SMI-SVR4)
	id QAA13508; Mon, 20 Jul 1998 16:53:50 -0400
From: arots at xebec.harvard.edu (Arnold Rots)
Message-Id: <199807202053.QAA13508 at xebec>
Subject: Indexed Keywords
To: fitsbits at fits.cv.nrao.edu
Date: Mon, 20 Jul 1998 16:53:50 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

I have a recollection that indexed keywords have to start at 1, i.e.,
Q1, Q2, Q3, Q4 - not Q0, Q1, Q2, Q3.

I couldn't find the explicit reference in NOST 100-1.2, but I'm sure
some recipient of this list server remembers ;-)

Am I right?

Thanks,

  - Arnold

--------------------------------------------------------------------------
Arnold H. Rots                                         AXAF Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 81                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 20 17:27:51 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id RAA16310
	for fitsbits-spinner; Mon, 20 Jul 1998 17:27:47 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA16305
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 17:27:43 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id RAA09886
	for fitsbits at majordomo.cv.nrao.edu; Mon, 20 Jul 1998 17:27:41 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA16295
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 17:24:41 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA09875
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 17:24:39 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id RAA20252
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 17:24:37 -0400
Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3)
	id sma020249; Mon Jul 20 17:24:33 1998
Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109])
          by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP
	  id RAA15787; Mon, 20 Jul 1998 17:24:03 -0400 (EDT)
Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4)
	id RAA03112; Mon, 20 Jul 1998 17:23:53 -0400
Message-ID: <35B3B568.DBA419D0 at tetra.gsfc.nasa.gov>
Date: Mon, 20 Jul 1998 17:23:52 -0400
From: William Pence <pence at tetra.gsfc.nasa.gov>
Organization: HEASARC
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Arnold Rots <arots at xebec.harvard.edu>
CC: fitsbits at fits.cv.nrao.edu
Subject: Re: Indexed Keywords
References: <199807202053.QAA13508 at xebec>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

On page 9 of the draft NOST 100-1.2, an Indexed keyword is defined to have
an appended *positive* integer count, which rules out starting the sequence
with zero.

-Bill Pence

Arnold Rots wrote:
> 
> I have a recollection that indexed keywords have to start at 1, i.e.,
> Q1, Q2, Q3, Q4 - not Q0, Q1, Q2, Q3.
> 
> I couldn't find the explicit reference in NOST 100-1.2, but I'm sure
> some recipient of this list server remembers ;-)



From owner-fitsbits at kochab.cv.nrao.edu  Mon Jul 20 18:22:13 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id SAA16417
	for fitsbits-spinner; Mon, 20 Jul 1998 18:22:08 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id SAA16412
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 18:22:05 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id SAA09965
	for fitsbits at majordomo.cv.nrao.edu; Mon, 20 Jul 1998 18:22:02 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id RAA16385
	for <fitsbits at majordomo.cv.nrao.edu>; Mon, 20 Jul 1998 17:49:55 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id RAA09929
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 17:49:52 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id RAA20554
	for <fitsbits at fits.cv.nrao.edu>; Mon, 20 Jul 1998 17:49:51 -0400
Received: from head-cfa.harvard.edu(131.142.41.8) by palantir.cv.nrao.edu via smap (V1.3)
	id sma020551; Mon Jul 20 17:49:41 1998
Received: from xebec by head-cfa (SMI-8.6/SMI-SVR4)
	id RAA05311; Mon, 20 Jul 1998 17:42:58 -0400
Received: by xebec (SMI-8.6/SMI-SVR4)
	id RAA13738; Mon, 20 Jul 1998 17:42:57 -0400
From: arots at xebec.harvard.edu (Arnold Rots)
Message-Id: <199807202142.RAA13738 at xebec>
Subject: Re: Indexed Keywords
In-Reply-To: <35B3B568.DBA419D0 at tetra.gsfc.nasa.gov> from William Pence at "Jul 20, 98 05:23:52 pm"
To: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Mon, 20 Jul 1998 17:42:57 -0400 (EDT)
Cc: arots at xebec.harvard.edu, fitsbits at fits.cv.nrao.edu
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Thanks, Bill.

Silly me - I went to the index, looked up "indexed, keywords", found
the definition of a keyword in section 5.1.2.1, and discovered that
this definition is mute on the subject.  Had I looked up "keywords,
indexed", then I would have found what I was looking for :-)

  - Arnold

William Pence wrote:
> On page 9 of the draft NOST 100-1.2, an Indexed keyword is defined to have
> an appended *positive* integer count, which rules out starting the sequence
> with zero.
> 
> -Bill Pence
> 
> Arnold Rots wrote:
> > 
> > I have a recollection that indexed keywords have to start at 1, i.e.,
> > Q1, Q2, Q3, Q4 - not Q0, Q1, Q2, Q3.
> > 
> > I couldn't find the explicit reference in NOST 100-1.2, but I'm sure
> > some recipient of this list server remembers ;-)

--------------------------------------------------------------------------
Arnold H. Rots                                         AXAF Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 81                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------



From owner-fitsbits at kochab.cv.nrao.edu  Wed Jul 22 08:40:21 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA08998
	for fitsbits-spinner; Wed, 22 Jul 1998 08:39:40 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA08993
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 22 Jul 1998 08:39:37 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id IAA11904
	for fitsbits at majordomo.cv.nrao.edu; Wed, 22 Jul 1998 08:39:33 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id TAA19165
	for <fitsbits at majordomo.cv.nrao.edu>; Tue, 21 Jul 1998 19:20:54 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id TAA11359
	for <fitsbits at fits.cv.nrao.edu>; Tue, 21 Jul 1998 19:20:48 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id TAA18796;
	Tue, 21 Jul 1998 19:20:46 -0400
To: fitsbits at fits.cv.nrao.edu
Date: Tue, 21 Jul 1998 16:23:16 GMT
From: Askar.Ibragimov at ksu.ru (Askar Ibragimov)
Message-ID: <6p1q3t$onc$1 at glory.ksu.ru>
Organization: Dept. of Astronomy, Kazan University
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!news.maxwell.syr.edu!bignews.mediaways.net!jupiter.NIC.DTAG.DE!news.free.net!news.ksu.ru!not-for-mail
Reply-To: Askar.Ibragimov at ksu.ru
Subject: Table specta to FITS for Xspec?
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Is anyone of this conference is user of XSPEC ?

Now I need to fit spectral data with my own model. I have a group of text files,
produced by my program, with theoretical spectra, printed as "Energy, eV ---
Flux, ergs cm-2 s-1 keV-1" (of course, I can make Flux in photons). I'm beginner
in XSPEC and using FITS, can anyone describe me what (as I understood,
procedures on Fortran found in XSPEC distribution) should I do to make file with
compilation of my models, which can be read from XSPEC ?

Askar



From owner-fitsbits at kochab.cv.nrao.edu  Wed Jul 22 08:41:00 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id IAA09014
	for fitsbits-spinner; Wed, 22 Jul 1998 08:40:59 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id IAA09009
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 22 Jul 1998 08:40:56 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id IAA11909
	for fitsbits at majordomo.cv.nrao.edu; Wed, 22 Jul 1998 08:40:53 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id AAA17235
	for <fitsbits at majordomo.cv.nrao.edu>; Wed, 22 Jul 1998 00:50:12 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id AAA11585
	for <fitsbits at fits.cv.nrao.edu>; Wed, 22 Jul 1998 00:50:10 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.5/8.8.5) id AAA09394;
	Wed, 22 Jul 1998 00:50:08 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 21 Jul 1998 11:53:26 -0400
From: Randall Smith <rsmith at kracko.harvard.edu>
Message-ID: <own2a319qh.fsf at kracko.harvard.edu>
Organization: Harvard University University Information Systems
Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!gatech!128.10.2.10.MISMATCH!purdue!oitnews.harvard.edu!cfanews.harvard.edu!131.142.52.109
Subject: Re: Table specta to FITS for Xspec?
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk



>Is anyone of this conference is user of XSPEC ?

>Now I need to fit spectral data with my own model. I have a group of
>text files, produced by my program, with theoretical spectra, printed
>as "Energy, eV --- Flux, ergs cm-2 s-1 keV-1" (of course, I can make
>Flux in photons). I'm beginner in XSPEC and using FITS, can anyone
>describe me what (as I understood, procedures on Fortran found in
>XSPEC distribution) should I do to make file with compilation of my
>models, which can be read from XSPEC ? 

You're in luck--I've dealt with this problem both in C and Fortran.
One solution I can send you is a C program that will read a single
model spectrum (E(i), F(i)) and output it as an XSPEC table model.
This program won't allow you to _fit_ to the model, as it only works
with a single spectrum.  If you would like a copy, please email me.
It's not long.

I have also worked out how to compile a collection of models into a
table model that can then be used to fit data using XSPEC.  (In my
case, I created models of SNR emission as a function of time, and then
fit to the SNR age.)  To do this, you need to use the wftbmd.f routine
that is in the XSPEC distribution.  (If you'd prefer to use C, I've got
a version of this routine that has been converted to C.)  You also
need to have either the fitsio or the cfitsio library compiled.  Then
you can use the following subroutine (included below) to output the
file.  This subroutine requires the name of the output file
(filename), the name of the model that will be used inside of XSPEC
(modelname), the number of different parameters in the model (npar),
and the energy binning.  I use a constant energy spacing, and so just
have it give the minimum energy (binmin) and the size of the bins
(binsyz), but obviously that's easily changed.  Two common blocks are
used, one which contains all the parameters that describe the model
(xspecparms) and one which contains the spectral data itself
(xspecvals).  

Please let me know if you have any questions about how to make this
work.  Good luck with your models!

Yours,
Randall Smith
rsmith at cfa.harvard.edu

------------------------------------------------------------------------

      subroutine output_v9_xspec(filename,modelname,npar,binmin,binsyz)
      
      implicit none
c
c
c   Author: Randall Smith, Smithsonian Astrophysical Observatory
c   Email : rsmith at cfa.harvard.edu
c   Date Released: July 21, 1998
c 
c

ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
c     MAXNPVALS = Maximum # of parameter values for a given parameter.c
c     MAXPARMS = Maximum # of different parameters; XSPEC sets limit. c
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
      integer MAXNPVALS,MAXPARMS,MAXBINS
      parameter(MAXNPVALS=20,MAXPARMS=2,MAXBINS=3000)
      
      character*12 parmname(MAXPARMS)
      real*4 initval(MAXPARMS), minval(MAXPARMS), lowval(MAXPARMS)
      real*4 highval(MAXPARMS),maxval(MAXPARMS),deltaval(MAXPARMS)
      integer*2 numpvals(MAXPARMS), interp(MAXPARMS)
      real*4 parvalues(MAXPARMS,MAXNPVALS)

      common/xspecparms/parmname, initval, minval, lowval, highval,
     $     maxval,deltaval, numpvals, interp, parvalues
      
      real channels(MAXNPVALS**MAXPARMS, MAXBINS)  ! Here is the data
      integer nbin
      common/xspecvals/channels,nbin  ! Note: huge...Beware...
ccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

      integer MAXNADDPM
      parameter(MAXNADDPM=1)    ! max addl parameters 
      integer*2 NPERBIN
      parameter(NPERBIN=4) ! defined by XSPEC

      character*128 filename,contxt
      character*12 modelname, modunt, infile
      character*12 addnam(MAXNADDPM), intnam(MAXPARMS)
      integer npar, j
      real binmin, binsyz, energy(MAXBINS), data(MAXBINS)
      
      integer nintpm, naddpm, maxtab, nenerg
      integer intntb(MAXPARMS), intmth(MAXPARMS)
      real addivl(6, MAXNADDPM), intivl(6, MAXPARMS)
      real inttab(MAXNPVALS, 1)
      real paramdata(MAXPARMS)
      logical qrdshf, qaddtv
c     output parameters 
      integer ounit, ierr, status
      integer nelements
      integer row, i
      
      nintpm = npar     ! only one parameter, time, currently
      naddpm = 0        ! no additional parameters
      modunt = 'Years'  ! Model units 
      qrdshf = .FALSE.  ! No redshifting
      qaddtv = .TRUE.   ! Additive model
      addnam(1) = ''    ! No additional parameter names
      intnam(1) = 'Time' ! Time is the unit.
      infile = 'spectrum'
      nenerg = nbin + 1
      do i=1,nenerg
         energy(i) = (binmin + i*binsyz)/1000.  ! Energy bins
      end do

      maxtab = MAXNPVALS

      do i=1,MAXPARMS
         intmth(i) = interp(i) ! 1 = log, 0 = linear interpolation
         intivl(1,i) = initval(i)  ! initial value to use
         intivl(2,i) = deltaval(i) ! inital delta step to take when fitting
         intivl(3,i) = minval(i)   ! hard minimum (can't go under this)
         intivl(4,i) = lowval(i)   ! soft minimum (mininum fitted #)
         intivl(5,i) = maxval(i)   ! hard maximum (can't go over this)
         intivl(6,i) = highval(i)  ! soft maximum (maximum fitted #)
         intntb(i) = numpvals(i)   ! # of diff. parm. vals (spectra) avail.

         do j=1,numpvals(i)               ! Set the actual values of the 
            inttab(j,i) = parvalues(i,j)  ! parameters...ie, t=10^5 yrs,
         end do                           ! n = 10^11 cm^-3, T=10^6 K etc.
      end do

      ounit = 89        ! output unit to use.
c
c  This call writes all the necessary header information.
c
      call wftbmd(filename, infile, modelname, modunt,
     $     nintpm, naddpm, qrdshf, qaddtv, addnam, addivl,
     $     parmname, intivl, intntb, intmth, maxtab,
     $     inttab, nenerg, energy, ounit, ierr, status, contxt)

c
c  Now write the model data
c
      do row=1,numpvals(1)
         nelements = 1
         paramdata(1) = parvalues(1,row)
         call ftpcle(ounit, 1, row, 1, nelements, paramdata, status)
         
         nelements = nbin
         do i=1,nbin 
            data(i) = channels(row,i)
         end do
         call ftpcle(ounit, 2, row, 1, nelements, data, status)
      end do
c
c  Now close the file
c
      call ftclos(ounit, status)
      
      return
      end


From owner-fitsbits at kochab.cv.nrao.edu  Fri Jul 24 13:40:36 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA04517
	for fitsbits-spinner; Fri, 24 Jul 1998 13:39:57 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA04512
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 24 Jul 1998 13:39:54 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA14936
	for fitsbits at majordomo.cv.nrao.edu; Fri, 24 Jul 1998 13:39:51 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA04496
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 24 Jul 1998 13:30:15 -0400 (EDT)
Received: from palantir.cv.nrao.edu (tismail at palantir.cv.nrao.edu [192.33.115.254])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id NAA14923
	for <fitsbits at fits.cv.nrao.edu>; Fri, 24 Jul 1998 13:30:11 -0400 (EDT)
Received: (from tismail at localhost)
	by palantir.cv.nrao.edu (8.8.5/8.8.5) id NAA25462
	for <fitsbits at fits.cv.nrao.edu>; Fri, 24 Jul 1998 13:30:08 -0400
Received: from wheelo.gsfc.nasa.gov(128.183.50.20) by palantir.cv.nrao.edu via smap (V1.3)
	id sma025456; Fri Jul 24 13:30:03 1998
Received: from tetra.gsfc.nasa.gov (tetra.gsfc.nasa.gov [128.183.127.109])
          by wheelo.gsfc.nasa.gov (8.8.5/8.8.4) with SMTP
	  id NAA06353 for <fitsbits at fits.cv.nrao.edu>; Fri, 24 Jul 1998 13:29:29 -0400 (EDT)
Received: from tetra.gsfc.nasa.gov by tetra.gsfc.nasa.gov (SMI-8.6/SMI-SVR4)
	id NAA08858; Fri, 24 Jul 1998 13:29:27 -0400
Message-ID: <35B8C477.1E698D96 at tetra.gsfc.nasa.gov>
Date: Fri, 24 Jul 1998 13:29:27 -0400
From: William Pence <pence at tetra.gsfc.nasa.gov>
Organization: HEASARC
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: FITSBITS <fitsbits at fits.cv.nrao.edu>
Subject: CFITSIO 2.0 beta
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

CFITSIO 2.0 (Beta) Release

This is to announce the first public beta release of CFITSIO 2.0, the
interface library for reading and writing FITS files from C or Fortran
programs.  This new release is backward compatible with the previous
v1.42 release, but contains many new features, including:

 - FITS files can be directly accessed over the internet by
   providing the full FTP or HTTP URL to CFITSIO's open_file routine.

 - FITS files may be accessed in Shared Memory instead of on magnetic
   disk, to improve data processing speeds.

 - Input FITS files can be filtered or modified at run-time based on
   a user-supplied expression that is appended to the name of
   the input file.  This filtering operation is transparent to the
   application program that opens the file.

 - New routines are provided to help deal with large sets of
   hierarchically grouped FITS files.

 - Fortran-callable wrappers are provided, so the CFITSIO routines
   may be called just as easily from Fortran as well as from C.


The ability to filter an input FITS file on the fly at run-time is
perhaps the most significant new feature, and provides sophisticated
data preprocessing capabilities to every application that uses CFITSIO
to read FITS files.  For example, if one has a program that opens an
input file whose name is supplied by the user, then the file as seen by
the program may be modified by appending various qualifiers to the file
name.

Example 1: 'myfile.fits.gz[EVENTS][TIME > 4000]'

  CFITSIO will open and uncompress the gzipped file, move to the table
  extension which has EXTNAME = 'EVENTS', and then filter out any rows
  which have a TIME column value less than or equal to 4000.  So instead
  of opening the original file, the application program actually opens a
  copy of the file that contains only the selected rows in the EVENTS
  extension. (The original file is not modified).

Example 2: 'myfile.fits.gz[EVENTS][col PI = PHA * 1.1 + .3][TIME > 4000]'

  Similar to the first example, except it also creates on the fly a new
  table column called 'PI' which is a function of the existing column
  'PHA'.

Example 3: 'myfile.fits.gz[EVENTS][bin (x,y)]

  In this case, CFITSIO creates a 2-D image by binning (histogramming)
  the values in the X and Y columns in the EVENTS table extension.  The
  application program then opens this temporary 2-D image FITS file that
  has been created on the fly, rather than the original FITS table.

These are only very simple examples of the allowed filtering syntax,
which essentially supports arbitrarily complex expressions using a C or
Fortran-like syntax.  These filtering operations are also extremely
fast, and in many cases the CPU overhead to do the filtering is
insignificant compared to the time required to simply read the file on
disk (with typically I/O rates of 5 MB/s or greater).

This beta version of CFITSIO is available via a link on the FITSIO Home
Page at:

     http://heasarc.gsfc.nasa.gov/fitsio

A html version of the new CFITSIO 2.0 User's Guide may be viewed on
line from that site.  The Chapter entitled "Detailed Filename Syntax"
in particular describes the available file filtering and preprocessing
commands in CFITSIO.

Since this is a beta release, it is expected that new updates will be
released at approximately 2-week intervals, until the full release in
September 1998.

Acknowledgements:

Many people have contributed to the new capabilities in CFITSIO 2.0.
Jurek Borkowski, Bruce O'Neel, and Don Jennings from the Integral
Science Data Center, Switzerland, provided the initial design for the
plug-in I/O drivers that are now used by CFITSIO.  This `driver'
concept greatly simplified  the low-level I/O, which in turn made many
of the other new features in CFITSIO much easier to implement.  Jurek
Borkowski then wrote the Shared Memory driver, and Bruce O'Neel wrote
the drivers for accessing FITS files over the network using the FTP,
HTTP, and ROOT protocols.  Don Jennings also designed and wrote the
Hierarchical Grouping routines.

Uwe Lamers (XMM project at ESTEC, The Netherlands) designed the
high-performance lexical parsing algorithm that is used to do
on-the-fly filtering of FITS tables.  This algorithm essentially
pre-compiles the user-supplied expression into a form that can be
efficiently evaluated for each row.  Peter Wilson (RSTX, NASA/GSFC)
then combined this design with the CFITSIO iterator routine to further
enhance the data processing throughput.

Peter Wilson also wrote the set of Fortran-callable wrappers for all
the CFITSIO routines, which rely on the CFORTRAN macro developed by
Burkhard Burow.

____________________________________________________________________
Dr. William Pence                          pence at tetra.gsfc.nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)     
Greenbelt MD 20771                         +1-301-286-1684 (fax)



From owner-fitsbits at kochab.cv.nrao.edu  Thu Jul 30 11:41:28 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id LAA24321
	for fitsbits-spinner; Thu, 30 Jul 1998 11:40:50 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA24316
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 30 Jul 1998 11:40:47 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id LAA04092
	for fitsbits at majordomo.cv.nrao.edu; Thu, 30 Jul 1998 11:40:44 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id LAA24130
	for <fitsbits at majordomo.cv.nrao.edu>; Thu, 30 Jul 1998 11:36:12 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id LAA04070;
	Thu, 30 Jul 1998 11:36:09 -0400 (EDT)
Date: Thu, 30 Jul 1998 11:36:09 -0400 (EDT)
Message-Id: <199807301536.LAA04070 at fits.cv.nrao.edu>
From: Don Wells <dwells at nrao.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: fitsbits at fits.cv.nrao.edu
Subject: fitsbits<==>sci.astro.fits gateway down
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Dear fitsbits subscribers,

The NRAO-Charlottesville Usesnet news server died one week ago.  It
was a CPU hardware failure which could not be repaired. The CPU has
been stripped of parts and the motherboard has been discarded. The
information on the disks survived. The computing staff of
NRAO-Charlottesville are in the process of restoring news service with
a new CPU. The current estimate is that the news server may be
restored in about 12 hours if all goes well.  Until then,
NRAO-Charlottesville cannot gate news traffic from anywhere to
anywhere; in particular, sci.astro.fits traffic is not being gated to
the fitsbits exploder. When service is restored, it is likely that
some news messages will have been lost due to the news feed being down
for so long. If so, the sci.astro.fits/fitsbits traffic archive which
I maintain may be incomplete. I expect to try to recover such traffic.

Regards,
Don Wells [owner and moderator of the fitsbits Email exploder]
-- 
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
		    http://www.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA


From owner-fitsbits at kochab.cv.nrao.edu  Fri Jul 31 13:17:40 1998
Received: (from majordom at localhost)
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) id NAA27579
	for fitsbits-spinner; Fri, 31 Jul 1998 13:17:12 -0400 (EDT)
Received: from fits.cv.nrao.edu (dwells at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA27574
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 31 Jul 1998 13:17:09 -0400 (EDT)
Received: (from dwells at localhost)
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) id NAA05648
	for fitsbits at majordomo.cv.nrao.edu; Fri, 31 Jul 1998 13:17:06 -0400 (EDT)
Received: from fits.cv.nrao.edu (root at fits.cv.nrao.edu [192.33.115.8])
	by kochab.cv.nrao.edu (8.8.8/8.8.8/CV-2.2) with ESMTP id NAA27564
	for <fitsbits at majordomo.cv.nrao.edu>; Fri, 31 Jul 1998 13:15:49 -0400 (EDT)
Received: from newsfeed.cv.nrao.edu (newsfeed.cv.nrao.edu [192.33.115.17])
	by fits.cv.nrao.edu (8.8.5/8.8.5/CV-2.3) with ESMTP id NAA05638
	for <fitsbits at fits.cv.nrao.edu>; Fri, 31 Jul 1998 13:15:46 -0400 (EDT)
Received: (from news at localhost)
	by newsfeed.cv.nrao.edu (8.8.7/8.8.8/CV-2.2) id NAA32535;
	Fri, 31 Jul 1998 13:15:40 -0400
To: fitsbits at fits.cv.nrao.edu
Date: 31 Jul 1998 13:12:17 -0400
From: Don Wells <dwells at nrao.edu>
Message-ID: <x1g1fi6j2m.fsf at fits.cv.nrao.edu>
Organization: nrao
Path: newsfeed.cv.nrao.edu!not-for-mail
Reply-To: dwells at nrao.edu
Subject: sci.astro.fits<===>fitsbits gateway is up again
Newsgroups: sci.astro.fits
Sender: owner-fitsbits at majordomo.cv.nrao.edu
Precedence: bulk

Dear fitsbits subscribers,

The NRAO-Charlottesville Usenet news server is operating again, using
its new CPU. Traffic arriving from sci.astro.fits, such as this
posting, will be gated to fitsbits, and postings to fitsbits will be
gated to sci.astro.fits. I expect that sci.astro.fits traffic from the
past eight days will be forwarded to fitsbits sometime during the next
few days, probably on Monday 08-03.

-Don
-- 
  Donald C. Wells         Associate Scientist         dwells at nrao.edu
		    http://www.cv.nrao.edu/~dwells
  National Radio Astronomy Observatory                +1-804-296-0277
  520 Edgemont Road,   Charlottesville, Virginia       22903-2475 USA