[AstroPy] Type changing (float to int) of header fields in astropy.wcs.to_header ?

[Eric L. N. Jensen]

Hi Mike,

Thanks for your quick and helpful response - I really appreciate it. 

First, let me say that I completely agree with this:

> Honestly, and I don't mean to sound unhelpful, this sounds like a bug in CASA.  It should cast to a float before performing floating-point operations.


I wasn't sure if that was the case before because I hadn't found the part of the FITS standard you reference (thanks!) about the decimal point being optional for floats in FITS.   And for what it's worth, I'm not sure if it's an issue with floating-point operations, or just with interpreting the field as an int and trying to store it as such.  (In fact the value in my particular case, ~3.45E9, is too long to store even as a long int in C.  So I guess the key issue is whether the FITS reader knows which fields to interpret as floats even if they have no non-integer part.)

Still, there's something unsatisfying to me about this happening within astropy:

>> From WCS object:
>> 
>> CRVAL3 is type <type 'numpy.float64'> with value:
>> 345797143190.0
>> 
>> After to_header conversion:
>> 
>> CRVAL3 is type <type 'int'> with value:
>> 345797143190

All that is within Python, i.e. the stated datatype *in Python* changes after the call to 'to_header'.   Could this be a problem if, e.g., a user decides to divide by that value (reasoning that it should be a float, since the input was float) and gets the result of integer division rather than floating-point division?  (I admit that this is a contrived example, since it would require that the numerator be an integer as well, but I'm still a little puzzled by the type change.) 

I guess I still don't see how this conversion happens.  I see in the code where you pointed out that wcslib will drop the decimal in making the number into a string, but to_header doesn't return a string-representation FITS header; it returns a FITS header object (which seems dictionary-like) that definitely doesn't have only string values.  Do these fields get converted to strings and then back to numbers during the to_header call?

At some level this won't matter for my particular problem if the final output file is written with that wcsutil_double2str 
function, but I am curious on your thoughts about the above, i.e. what is happening within Python itself. 

Thanks again,

Eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/astropy/attachments/20140122/1f9b588a/attachment.html>