Re: [Iaufec] 64-bit vote reminder
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: <mcalabre_at_email.protected>
Date: Wed, 14 Sep 2005 11:34:38 +1000
<pre id="body">
<a name="start" accesskey="j" id="start"></a>On Wed 2005/09/07 15:46:34 -0400, William Pence wrote
in a message to: IAU-FITS Exec Committee <iaufec_at_nrao.<!--nospam-->edu>
>This is a reminder to the 3 remaining regional committee chairmen to please
>try to complete the votes on the 4 64-bit integer issues by the end of next
>week (Sept 16) so that we will have ample time to consider the results prior
I am pleased to report that the Australasian regional committee has now
completed voting on the 64-bit integer proposals:
Part 1 Part 2 Part 3 Part 4
BITPIX=64 'Q' desc. TFORMn='K' uint 'P'
---------- ---------- ---------- ----------
Yes: 6 6 6 4
No: 0 0 0 1
Abstain: 0 0 0 1
No vote: 1 1 1 1
---------- ---------- ---------- ----------
Total: 7 7 7 7
The committee member who did not vote did respond but said that he is on
extended leave and wishes to suspend involvement for now. Therefore the
effective number of members should be considered to be six, not seven.
The following comments were received (excluding my own comments sent to
the mailing lists):
All parts (yes votes):
I'm going to vote YES to all 4. I think the changes will make it
easier to store precision pulsar timing data and since the pulsar
group develops in C and C++ these days I see no (selfish) reason to
be held back by the limitations of FORTRAN.
Part 1 (yes vote):
Should keep the symmetry in all cases. Anyway, limiting ranges
'because it is not necessary' have always turned out to be an error.
Part 4 (no vote):
The whole FITS standard only knows 2-complement integers of n (>1)
bytes and unsigned integers of 1 byte. All other 'unsigned' values
are represented by a signed value and an offset.
Introducing real unsigned ints does not seem to me to add anything
at this stage. It can be argued that lengths are always positive,
and hence a change in definition somewhere does not really hurt.
However, negative values could be used in places for special purposes
already and legacy code could suffer.
The factor 2 gained here shrinks into insignificance beside the s^32
factor gained in this proposal, and would, in any case, only be a
stop-gap in special cases.
Mark Calabretta
ATNF
Received on 2005-09-14 11:35:06
Date: Wed, 14 Sep 2005 11:34:38 +1000
<pre id="body">
<a name="start" accesskey="j" id="start"></a>On Wed 2005/09/07 15:46:34 -0400, William Pence wrote
in a message to: IAU-FITS Exec Committee <iaufec_at_nrao.<!--nospam-->edu>
>This is a reminder to the 3 remaining regional committee chairmen to please
>try to complete the votes on the 4 64-bit integer issues by the end of next
>week (Sept 16) so that we will have ample time to consider the results prior
I am pleased to report that the Australasian regional committee has now
completed voting on the 64-bit integer proposals:
Part 1 Part 2 Part 3 Part 4
BITPIX=64 'Q' desc. TFORMn='K' uint 'P'
---------- ---------- ---------- ----------
Yes: 6 6 6 4
No: 0 0 0 1
Abstain: 0 0 0 1
No vote: 1 1 1 1
---------- ---------- ---------- ----------
Total: 7 7 7 7
The committee member who did not vote did respond but said that he is on
extended leave and wishes to suspend involvement for now. Therefore the
effective number of members should be considered to be six, not seven.
The following comments were received (excluding my own comments sent to
the mailing lists):
All parts (yes votes):
I'm going to vote YES to all 4. I think the changes will make it
easier to store precision pulsar timing data and since the pulsar
group develops in C and C++ these days I see no (selfish) reason to
be held back by the limitations of FORTRAN.
Part 1 (yes vote):
Should keep the symmetry in all cases. Anyway, limiting ranges
'because it is not necessary' have always turned out to be an error.
Part 4 (no vote):
The whole FITS standard only knows 2-complement integers of n (>1)
bytes and unsigned integers of 1 byte. All other 'unsigned' values
are represented by a signed value and an offset.
Introducing real unsigned ints does not seem to me to add anything
at this stage. It can be argued that lengths are always positive,
and hence a change in definition somewhere does not really hurt.
However, negative values could be used in places for special purposes
already and legacy code could suffer.
The factor 2 gained here shrinks into insignificance beside the s^32
factor gained in this proposal, and would, in any case, only be a
stop-gap in special cases.
Mark Calabretta
ATNF
Received on 2005-09-14 11:35:06