[fitsbits] Question on angstrom and erg units in FITS standard

[Erik Bray]

On 11/04/2014 04:02 PM, Thierry.Forveille at ujf-grenoble.fr wrote:
>
> Quoting Erik Bray <embray at stsci.edu>:
>> I think the idea would be that if somebody wanted to write data to a FITS file
>> that is in some units not supported by FITS then nothing prevents them from
>> doing so--they are free to tell the FITS writer "here are some dimensionless
>> numbers" and then manually tweak the header in the appropriate place to
>> indicate to a (human) reader how they want those numbers interpreted.
>>
>> But for the sake of automatic serialization of, say, Astropy Quantity objects
>> to a FITS file then there should be no room allowed for ambiguity.
>>
>> That doesn't mean it should take some existing file and rewrite the data with
>> new units.  Instead if it gets units that it doesn't understand it should just
>> leave them alone.  But when writing *new* data to *new* FITS files I think
>> that it should at least warn when writing an object with units that are not
>> supported by FITS.
>>
> Since Astropy is (presumably) very seldom used to just copy
> the data unchanged (cp does a really good job at that ;-)) and
> will normally be used to perform one data transformation/combination
> or another, I see no reason for it to fixate on keeping the data
> bit for bit identical. For a writing library like cfitsio, the user
> can expect that the bits are preserved, but once one starts any
> kind of non-trivial arithmetic processing that's just plain
> impossible. The numerical noise from dividing by a factor of
> 10 to convert Angstroms or cgs to SI is then just one more
> contribution, and in most cases a minor one.

Perhaps more often than not, one opens a file just to update some values in a 
header, not to change the science data.  I don't want to field the bug reports 
that come up with somebody changes a comment in a header and all of the sudden 
their data is converted to nm (and then passed through pipeline software that 
isn't intelligent about units and just assumes the data is always in Angstroms).