GNU Astronomy Utilities - Bugs: bug #61969, Incorrect output for integer...
You are not allowed to post comments on this tracker with your current authentication level.
bug #61969: Incorrect output for integer calculations
Submitter: | Pedram Ashofteh-Ardakani <pedram> | ||
Submitted: | Tue 01 Feb 2022 05:42:43 AM UTC | ||
Category: | Arithmetic | Severity: | 3 - Normal |
Item Group: | Output not reasonable | Status: | Fixed |
Privacy: | Public | Assigned to: | pedram |
Open/Closed: | Closed |
Tue 01 Feb 2022 10:32:08 AM UTC, comment #4: |
Pedram Ashofteh-Ardakani <pedram>![]() ![]() |
Tue 01 Feb 2022 09:58:28 AM UTC, comment #3: That last example was great (and more clear!). Here is the reason behind this behavior (which is expected, but not intuitive):
Arithmetic reads every number with the smallest possible numerical data type (even accounting for the un-signed nature; when the integer isn't negative!).
Therefore in the last example, both '100' and '4' are read as an unsigned 8-bit integer. Therefore, since both inputs are 'uint8', the output is also 'uint8' and this numeric data type only takes values betweeen 0 to 255. Therefore, when the value you want to put inside of it is larger, the remainder of that value and 256 will be written there instead: (300 % 256 = 44). This is called Integer overflow. You can see it in practice with this basic C program:
So effectively, this "bug" is the expected behavior! In large data analysis, this is important because a 100Mb file (that is 'uint8'; like binary maps!) can become 400Mb if stored as an 'int32'! We don't want to generically read all small integers as "wider" numbers.
This is something that has been in my mind for a long time! The Good news is that C library's 'errno.h' has a special error code for such range overflows: 'ERANGE'. We should add a check for this error code within arithmetic and if it happens, a warning should be printed that an overflow has happened (to standard-error; so its even printed with '--quiet'!).
Can you define a task for this Pedram? I am so busy with many meetings today and am affraid that I may forget.
I will close this bug and we'll follow this in the newly defined task ;-). |
Mohammad Akhlaghi <makhlaghi>![]() |
Tue 01 Feb 2022 05:59:10 AM UTC, comment #2: I thought maybe this was related to bug #61940 Numbers with many decimals incorrectly been read as float32, so I tried with the most recent version, and the problem persists.
== version ==
|
Pedram Ashofteh-Ardakani <pedram>![]() ![]() |
Tue 01 Feb 2022 05:49:37 AM UTC, comment #1: Actually, the problem occurs for the most basic multiplications with results greater than about 300:
|
Pedram Ashofteh-Ardakani <pedram>![]() ![]() |
Tue 01 Feb 2022 05:42:43 AM UTC, original submission:
problemIncorrect output for a combination of multiplication, subtraction and addition when using integers, but it works fine with float.
steps to reproduce
|
Pedram Ashofteh-Ardakani <pedram>![]() ![]() |
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.
Sure Mohammad, I defined it here in task #16114 :-)