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

 
 

bug #30423: Incorrect limit for array sizes?

Submitted by:  John W. Eaton <jwe>
Submitted on:  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

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project 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>
Project 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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project 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.5