bugGNU Octave - Bugs: bug #54562, numel should warn if the resulting...


bug #54562: numel should warn if the resulting double might be inaccurate

Submitter:  Colin Macdonald <cbm>
Submitted:  Thu 23 Aug 2018 05:54:32 PM UTC
Category:  Interpreter Severity:  1 - Wish
Priority:  5 - Normal Item Group:  Inaccurate Result
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Sat 25 Aug 2018 05:50:47 PM UTC, comment #3: 

I agree on a couple of points.  First, Octave's handling of very large indices needs to be better.  Second, the problem can be broken up in to different regimes where, unfortunately, Octave is performing poorly each time.  For indices greater than intmax, as Dan has pointed out, the integer value reverses sign and becomes negative and is generally handled poorly.  That is the first thing to fix.  The second regime is indices greater than flintmax but less than intmax where there can be a loss of precision.  A warning about using linear indexing in this regime would be a good idea.  In addition, to warning about linear indexing it should suggest the alternative of using full subscripts (A(i,j)) which very likely preserves full precision.

Rik <rik5>
Group administrator
Sat 25 Aug 2018 12:11:55 AM UTC, comment #2: 

The warning made me think I've done such a thing not too long ago.  If you are interested, it may be this:


Dan Sebald <sebald>
Sat 25 Aug 2018 12:08:38 AM UTC, comment #1: 

Interesting warning.  The issue is discussed here:


and I believe there is a bug in the way float is cast to an integer for which I've attached a patch:


As an ancillary item, I posted the following regarding the float vs int64/uint64 dilemma for "native" arithmetic:


Dan Sebald <sebald>
Thu 23 Aug 2018 05:54:32 PM UTC, original submission:  

  * With 64-bit indexing, the maximum index value (on my system) is 9.2234e+18

  * flintmax is 9.0072e+15.

  * numel returns type double.

Thus if a matrix is large (maybe sparse), it can easily have enough elements such that numel is larger than flintmax and thus the numel value is not precise.

>> [a, maxint]= computer ()
a = x86_64-pc-linux-gnu
maxint = 9.2234e+18
>> flintmax
ans = 9.0072e+15

>> A = sprand(1e10+123, 1e7+123, 1e-13);
>> j = int64(1e10+123) * int64(1e7+123)
j = 100001231230015129

>> n = numel(A)   # note, below maxint but above flintmax
n = 1e+17
>> i = int64(n)
i = 100001231230015136

>> i - j   # uh oh
ans = 7

Note: Matlab's numel gives a warning: "Number of elements exceeds maximum flint 2^53-1".  Its still imprecise but at least user is informed.

Colin Macdonald <cbm>


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

Attach Files:

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 rik5 (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by cbm (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.

    Only group members can vote.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-25 rik5 Severity3 - Normal 1 - Wish
        StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-c373.
    Corresponding source code