GNU 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: |
Mohammad Akhlaghi <makhlaghi> |
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.
|
Elham Saremi <elham> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 | Status | None | Invalid | |
Assigned to | None | makhlaghi | |||
Open/Closed | Open | Closed |
Powered by Savane 3.13-d3ae.
Corresponding source code
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').
To understand the problem, we should consider the two points below:
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):
To better help explain these types of issues with floating points, in commit f4bb1ff599, I made the following two changes in Gnuastro:
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 ;-).