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: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: Wont FixAssigned to: None
Originator Name: John W. EatonOpen/Closed: Closed
Release: devOperating 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 File(s):
   
   
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
  • -unavailable- added by highegg (Updated the item)
  • -unavailable- added by jwe (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 22 Jul 2010 08:09:06 AM UTChigheggStatusNone=>Wont Fix
    Thu 22 Jul 2010 07:04:05 AM UTChigheggOpen/ClosedOpen=>Closed
    Wed 14 Jul 2010 07:08:38 AM UTChigheggAttached File-=>Added max1.diff, #20970

    Back to the top


    Powered by Savane 3.1-cleanup1