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 ; 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 ; 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 ; 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: <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 ; 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 ; 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 ; 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 ; 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 Subject: Comments on NOST 100-1.2 To: fitsbits at fits.cv.nrao.edu Cc: "isdc) Jennings Donald G." , 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 ; 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 ; 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 ; 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 ; 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 X-Sender: segh at mraosb To: fitsbits at fits.cv.nrao.edu Subject: sexagesimal TDISPn Message-ID: 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 ; 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 X-Sender: segh at mraosb To: fitsbits at fits.cv.nrao.edu Subject: re NOST: sexagesimal TDISPn Message-ID: 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 ; 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 ; 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 ; 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 ; 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 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: 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 ; 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 ; 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 ; 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: 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 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 ; 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 ; 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 ; 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 Message-ID: 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 ; 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 ; 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 ; 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: 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: 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 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 ; 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 ; 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 ; 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 ; 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 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: References: <6nvtr3$amr$1 at newsfeed.cv.nrao.edu> 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 > 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 ; 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 ; 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 ; 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 ; 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" 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 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 #include 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 ; 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 ; 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 ; 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: 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> <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 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 #include 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 ; 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: 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 > 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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: 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 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 ; 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 X-Sender: tjp at bottom Reply-To: Tim Pearson 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: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 Message-ID: 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 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 ; 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 ; 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 ; 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 ; 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 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 Subject: Re: 64-bit integers in FITS References: 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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: <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 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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: Organization: Center for Space Research Path: newsfeed.cv.nrao.edu!newsgate.duke.edu!nntprelay.mathworks.com!eecs-usenet-02.mit.edu!davis References: 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 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 ; 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 ; 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 ; 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 ; 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 ; 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 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: <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 ; 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 ; 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 ; 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 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 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 ; 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 ; 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 ; 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 ; 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 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 ; 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 ; 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 ; 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" 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: 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 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 ; 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 ; 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 ; 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 Organization: National Radio Astronomy Observatory X-Mailer: Mozilla 4.05 [en] (Win95; U) MIME-Version: 1.0 To: "William F. Wyatt" CC: fitsbits at fits.cv.nrao.edu Subject: Re: Comments on NOST 100-1.2 References: <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 ; 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 ; 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 ; 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 ; 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: 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 > 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 > #include > > 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 ; 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 ; 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 ; 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 ; 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 Organization: HEASARC X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Arnold Rots 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 Organization: HEASARC X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Arnold Rots 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 Message-ID: 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 ; 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 ; 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 ; 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 ; 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 ; 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 Organization: HEASARC X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: FITSBITS 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 ; 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 ; 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 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 ; 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 ; 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 ; 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 Message-ID: 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