bugGNU Octave - Bugs: bug #61041, Sum behaves unexpectedly for large...

 
 

bug #61041: Sum behaves unexpectedly for large uint64 values when not using native mode

Submitter:  None
Submitted:  Sat 14 Aug 2021 05:55:59 PM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 16 Aug 2021 08:54:02 PM UTC, comment #2: 

Only 90 eps for 88 million values is actually quite good. The point is that during the computation of the sum, at some point the current partial sum exceeds flintmax, meaning that not all integer can be exactly expressed any more. Specifically, between flintmax and 2*flintmax only the even integers can be expressed, and from 2*flintmax to 4*flintmax only the multiples of 4 (and so on). Thus, once you are above flintmax each single addition will lead to an error on the order of eps. Partially, these errors will cancel, but you can expect the partial sum to perform something like Brownian motion relative to the true partial sums. Try the option "extra" of the sum command, which supposedly uses a more accurate summation algorithm (perhaps Kahan summation, but not specified by the documentation).

Michael Leitner <mleitner>
Sun 15 Aug 2021 04:32:36 PM UTC, comment #1: 

`flintmax`, i.e. the maximum integer up to which all integers can be represented accurately in floating point precision, is 2^53 (about 9e15) for double precision floating point numbers. If the result of the sum is in the order of 4e17 (i.e. approx. 2 orders of magnitude higher than `flintmax`), relatively large inaccuracies are to be expected in general.
On the other hand, the maximum number that can be represented in uint64 is 2^64-1 (about 1.8e19). So performing a native sum should work correctly.

Closing as invalid.
Please, comment if you think that Octave should do something different and we can re-open.


Markus Mützel <mmuetzel>
Group administrator
Sat 14 Aug 2021 05:55:59 PM UTC, original submission:  

Foo is a uint64 vector of length 88 million, whose values are all in the range 0 to 2**41. The sum of those numbers in foo comes to about 4.3e17 and is an integer, so using sum(foo,"native") is very much warranted to avoid rounding problems with converting uint64 to double and back.

The unexpected behavior is that the relative difference between sum(foo) and sum(foo,"native") is about 90*eps, not close to eps like expected but two orders of magnitude larger. Is this an expected discrepancy for sum without using native mode? If so, it's not a bug. If it's unexpected for you too, it might warrant looking into why it's so big.

This was on Octave 7 with OpenBlas 3.17.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

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 mleitner (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  •  

    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.

    Only group members can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-08-15 mmuetzel StatusNone Invalid / Not an Octave Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code