bugGNU Octave - Bugs: bug #30423, Incorrect limit for array sizes?

 
 

bug #30423: Incorrect limit for array sizes?

Submitter:  John W. Eaton <jwe>
Submitted:  Mon 12 Jul 2010 05:17:46 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Wont Fix Assigned to:  None
Originator Name:  John W. Eaton Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 21 Jul 2010 07:02:11 AM UTC, comment #4: 

I've made it sizemax() for the time being:
http://hg.savannah.gnu.org/hgweb/octave/rev/e38c071bbc41

Jaroslav Hajek <highegg>
Tue 20 Jul 2010 07:21:06 PM UTC, comment #3: 

I made the maximum extent value accessible as a static member of dim_vector and documented the choice. I think it would be best to simply make the value accessible from the interpreter, so that it can change in the future.

Would you prefer indexmax() or intmax("index")?

Jaroslav Hajek <highegg>
Tue 20 Jul 2010 03:47:58 PM UTC, comment #2: 

Unless there is a good reason (as you say, there may be), I would expect to be able to index elements 1 to intmax ('int32') if octave_idx_type is int32_t.  Likewise for int64.

I can accept a smaller limit provided that it is documented to avoid future confusion.  I know I was confused that I couldn't allocate an array with intmax ('int32') elements.

John W. Eaton <jwe>
Group administrator
Wed 14 Jul 2010 07:08:38 AM UTC, comment #1: 

The fix is trivial (attached), but should it be fixed? I think I've done this on purpose, though I failed to record it there :(

For instance, consider a sparse row vector of length n = 2147483647 columns (disregarding the fact that sparse row vectors are a bad idea in practice).
The SparseRep holds boundaries for i-th row in c[i-1]<= j < c[i],
so c needs to be of length n+1. Overflow; bang, you're dead.

Maybe there are other cases where you want an internal buffer of size n+1 (for instance, for cumulative sums).

On the contrary, how does this matter if it's intmax or intmax-1?

(file #20970)

Jaroslav Hajek <highegg>
Mon 12 Jul 2010 05:17:46 PM UTC, original submission:  

When using a 32-bit signed integer for octave_idx_type, I would expect to be able to create an array with intmax ('int32') elements, but that fails:

  octave:1> z = zeros (intmax ('int32'), 1, 'int8');
  error: memory exhausted or requested size too large for range of Octave's index type -- trying to return to prompt

However, I am able to create an array with intmax ('int32') - 1 elements:

  octave:1> z = zeros (intmax ('int32') - 1, 1, 'int8');
  octave:2> format long
  octave:3> size (z)
  ans =

     2147483646            1

This is on a 64-bit Debian system, but I'm not configuring with --enable-64.  Even so, shouldn't it be possible to use all intmax ('int32') elements?

I think the problem is with dim_vector::safe_numel, but I don't see a proper fix at the moment.

John W. Eaton <jwe>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #20970:  max1.diff added by highegg (407B - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by highegg (Updated the item)
  • -email is unavailable- added by jwe (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-22 highegg StatusNone Wont Fix
    2010-07-22 highegg Open/ClosedOpen Closed
    2010-07-14 highegg Attached File- Added max1.diff, #20970

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code