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

[Mohammad Akhlaghi]

Update of bug #63346 (project gnuastro):

                  Status:                    None => Invalid                
             Assigned to:                    None => makhlaghi              
             Open/Closed:                    Open => Closed                 

    _______________________________________________________

Follow-up 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 <https://en.wikipedia.org/wiki/IEEE_754>. 
* 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
<https://www.gnu.org/software//gnuastro/manual/html_node/Numerical-type-conversion-operators.html>
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
<https://git.savannah.gnu.org/cgit/gnuastro.git/commit/?id=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 ;-).


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63346>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/