bugGNU Astronomy Utilities - Bugs: bug #63346, Astarithmetic_multioperand:...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #63346: Astarithmetic_multioperand: problem in type of some numbers

Submitter:  Elham Saremi <elham>
Submitted:  Fri 11 Nov 2022 06:58:54 PM UTC
   
 
Category:  Arithmetic Severity:  3 - Normal
Item Group:  Crash Status:  Invalid
Privacy:  Public Assigned to:  makhlaghi
Open/Closed:  Closed

Sun 13 Nov 2022 04:48:58 AM UTC, comment #1: 

Thanks a lot for the nice bug report Elham.

After some investigation, I noticed that this isn't a bug. Let me explain:

Your commands can be reproduced with any image that has a 32-bit floating point data type (for the sake of mere reproduction of the error, we can even run it like this (where 'image.fits' is repeated two times instead of 'image1.fits' and 'image2.fits').


$ astarithmetic image.fits 56087.500000 / image.fits 56874.144531 / 2 -g1 3 0.2 sigclip-mean -oout.fits


To understand the problem, we should consider the two points below:

  • When reading raw floating point numbers from the command-line, Gnuastro looks at the number of significant digits they have. If they have 7 or less significant digits, they are stored as 32-bit floating points, otherwise they are read as 64-bit floating point numbers. The number 7 comes from the IEEE 754 floating point standard.
  • When an operator is given two different numeric data types, its output is the larger of the two.


The number '56087.500000' only has 6 significant/decimal digits, so Gnuastro reads it as 32-bit floating point. But the number '56874.144531' has 11 decimal digits, so it is read as a 64-bit floating point (Gnuastro doesn't want to loose any meaningful precision you may have given!).

Therefore the output of 'image.fits 56087.500000 /' is a 32-bit floating point image and the output of 'image.fits 56874.144531 /' is a 64-bit floating point image. Hence why this happens.

To avoid such cases, you can simply use the Numerical type conversion operators like below (after each place where numbers may cause such issues):


$ astarithmetic image.fits 56087.500000 / float32 image.fits 56874.144531 / float32 2 -g1 3 0.2 sigclip-mean -oout.fits


To better help explain these types of issues with floating points, in commit f4bb1ff599, I made the following two changes in Gnuastro:

  • All floating point numbers are now printed as exponential/scientific mode, and by default the precision is 7 for 32-bit floats.
  • A whole new sub-section titled "Printing floating point numbers" has been added under the "Table" program's section that describes the issue and solutions.


So hopefully if you update to the latest version, the two numbers '56087.500000' and '56874.144531' (which I assume you got from a previous call to a Gnuastro program), will be printed in exponential format and with the same number of digits after the decimal point. So things should be more predictable ;-).

Thanks again for reporting this issue that lead to that newly added section, I recommend reading it when you have the chance ;-).

Mohammad Akhlaghi <makhlaghi>
Group administrator
Fri 11 Nov 2022 06:58:54 PM UTC, original submission:  

For using the 'astarithmetic' in my pipeline, I had an error. After more concentration, I understood the bug is related to decimal digits.

For example, you can see a similar command and error below:

"astarithmetic image1.fits 56087.500000 / image2.fits 56874.144531 / 2 -g1 3 0.2 sigclip-mean -oimage.fits"

astarithmetic: arithmetic_multioperand: the types of all operands to the 'sigclip-mean' operator must be same

If we have decimal digits, with more than 5 to zero, this problem occurs.

Thanks.

Elham Saremi <elham>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by makhlaghi (Posted a comment)
  • -email is unavailable- added by elham (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-11-13 makhlaghi StatusNone Invalid
        Assigned toNone makhlaghi
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code