Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in development Crash with no stack trace Already fixed in newer version Fixed in stable Bad description Bad description and crash Bad stack trace Obsolete version Duplicate and not fixed Duplicate and needs more info Duplicate and fixed Need info and old
> 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
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.
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.
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 ()));
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?
(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
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.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 4 latest changes.
Copyright © 2022 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.9