bugGNU Octave - Bugs: bug #47469, sizemax() is off by one

 
 

bug #47469: sizemax() is off by one

Submitter:  Carnë Draug <carandraug>
Submitted:  Sat 19 Mar 2016 07:07:59 PM UTC
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  In Progress Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

Sat 23 Jul 2022 11:44:39 PM UTC, comment #4: 

> I have posted a request for comment/advice on the Octave Maintainer's list.


For details, the post is at https://lists.gnu.org/archive/html/octave-maintainers/2019-12/msg00134.html

Carnë Draug <carandraug>
Project Member
Mon 30 Dec 2019 09:11:55 PM UTC, comment #3: 

I reverted the changeset that deprecated sizemax().  This issue requires more thought, and isn't ready for the imminent 6.1 release.  I have posted a request for comment/advice on the Octave Maintainer's list.

Re-opening report.

Rik <rik5>
Project Administrator
Mon 04 Nov 2019 04:10:48 PM UTC, comment #2: 

I deprecated sizemax() in this cset: https://hg.savannah.gnu.org/hgweb/octave/rev/2890a931e647.

There isn't a good reason to restrict Octave to intmax - 1 so it was better to just remove this code entirely.

Rik <rik5>
Project Administrator
Wed 30 Mar 2016 10:50:13 AM UTC, comment #1: 

I suggest to deprecate "sizemax" and remove "dim_vector::dim_max". Or is there any non-obvious benefit from it?

1. The function name is misleading. "numelmax" or alike would be more applicable, as it gives the information, how many elements an array can index. The misleading idea is, that something like

ones (2, sizemax())

was okay. I think in bug #47468 the intention is to use it in test code, what I think is a bad idea, to start relying on this function.

2. The information of 64-bit indices for the user is implicitly given by

__have_feature__ ("ENABLE_64")

3. The only "real" usage is in scripts/sparse/private/__sprand__.m, but after diving into that code, it is only part of a dirty hack, that should be solved in the randperm() function.

>> grep -R sizemax
libinterp/corefcn/bitfcns.cc:DEFUN (sizemax, args, ,
libinterp/corefcn/bitfcns.cc:@deftypefn {} {} sizemax ()\n\
libinterp/corefcn/bitfcns.cc:%!assert (sizemax () >= (intmax ("int32") - 1))
libinterp/corefcn/bitfcns.cc:%!error sizemax (0)
scripts/sparse/private/__sprand__.m:      if (mn > sizemax ())

>> grep -R dim_max
liboctave/array/dim-vector.h:  static octave_idx_type dim_max (void);
liboctave/array/dim-vector.cc:dim_vector::dim_max (void)
liboctave/array/dim-vector.cc:  octave_idx_type idx_max = dim_max ();
libinterp/corefcn/bitfcns.cc:  return octave_value (octave_int<octave_idx_type> (dim_vector::dim_max ()));

Kai Torben Ohlhus <siko1056>
Project Member
Sat 19 Mar 2016 07:07:59 PM UTC, original submission:  

The function sizemax() is off by one.

octave> sizemax ()
ans = 2147483646
octave> intmax ("int32")
ans = 2147483647
octave> uint64 (numel (ones (1, 2147483647)))
ans = 2147483647

The fact that I can create that array of ones is a separate bug (see bug #47468). The reason for being off by one is mentioned in the source of dim-vector:

    http://hg.savannah.gnu.org/hgweb/octave/file/2cdbae31c022/liboctave/array/dim-vector.cc#l32

Checking the logs for a better explanation brings up this:

    http://hg.savannah.gnu.org/hgweb/octave/rev/6683f0c9d742

I removed the "-1" from dim_vector::dim_max and make check reports no new failures. Maybe it is no longer needed (or maybe it's some untested codepath. Anyone has any insight?

Carnë Draug <carandraug>
Project Member

 

(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 rik5 (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by carandraug (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 project members can vote.

     

     

     

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-30 rik5 StatusWont Fix In Progress
        Open/ClosedClosed Open
    2019-11-04 rik5 Open/ClosedOpen Closed
    2019-11-04 rik5 StatusNone Wont Fix

    Back to the top

    Powered by Savane 3.9