bugGNU Octave - Bugs: bug #44201, "whos" and gui display...

 
 

bug #44201: "whos" and gui display non-integer sizes inf/nan poorly

Submitter:  Colin Macdonald <cbm>
Submitted:  Sat 07 Feb 2015 02:55:23 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  None 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
   

Jump to the original submission

Sun 15 Feb 2015 04:13:30 PM UTC, comment #11: 

That is fine for 4.0.  We seem to support inf and nan just fine in user classes, so its just cosmetic.

But I do not think we should "rethink those classes".  My arguments:

1.  Chebfun is a popular toolbox that regularly uses Infx1 and Infx3 etc.  With classdef we are likely to be able to run it.  Its not our class to think about.  The "infinite length vector" is a core mathematical concept for them.

2.  I'm likely to support symbolic sized matrices in "symbolic" (mxn where m and n are sym() objects).  I can display these as 1x1 in whos.  But NaN x NaN seems nicer to me.

3.  Matlab does it.

> easier for the programmer if Octave tells them exactly
> how it sees the object in question.


Disagree.  If that were so, size for a user defined class might always be "1x1".  I think Octave in general has little idea about how a user-defined class chooses to represent itself.  size.m is supposed to doubles.  My class gives doubles.

Colin Macdonald <cbm>
Sun 15 Feb 2015 03:37:12 PM UTC, comment #10: 

How important is it to expand dim vectors to support NaN and Inf?  At least in core Octave I don't see an easy way to even generate such an object.


x = ones (2, Inf)
error: out of memory or dimension too large for Octave's index type
x = ones (2, NaN, 3)
x = [](2x0x3)


Now you could have a class that overloads size to return Inf and NaN values, but maybe the best approach is to rethink those classes rather than requiring Octave to try and understand them?

I am also wary of having the same information, the dim_vector, interpreted two ways.  If you do whos ('x') on the second example you would get "2xNaNx3".  But if you ask Octave to do a calculation on x it will treat the whole thing as an empty matrix.  I think it is easier for a programmer if Octave tells them exactly how it sees the object in question.


Rik <rik5>
Group administrator
Fri 13 Feb 2015 09:41:17 PM UTC, comment #9: 


> I still have not read how to squash commits,


If you're using evolve, it's the `hg squash` command, which is aliased to `hg fold`.

If you're not, it's the "fold" action in `hg histedit`, which is almost the same as `git rebase -i` (but not like `git rebase`, that's `hg rebase`).

My plug for evolve:

https://www.youtube.com/watch?v=4OlDm3akbqg

Jordi GutiƩrrez Hermoso <jordigh>
Group Member
Tue 10 Feb 2015 10:40:25 AM UTC, comment #8: 

Version 4 attached.  Use a std::string for the separator, default is still ascii "x".  But in the GUI panel use the utf8 string corresponding to the TeX $\times$ char.

(file #33045)

Colin Macdonald <cbm>
Tue 10 Feb 2015 12:01:30 AM UTC, comment #7: 

Ok, attached version 3, which uses xisinf/xisnan (thanks @sebald) to render as "NaNxInf".

(file #33043)

Colin Macdonald <cbm>
Mon 09 Feb 2015 11:51:37 PM UTC, comment #6: 

@jwe: Ok done.  I exported it from variables .h and included this symtab.cc.  Let me know if this is not right!

I still have not read how to squash commits, so update is just a diff (instead of hg patch).  It is the output of:

hg diff -r 5a59c0e1203d > ../infnan_sizes_in_whos_and_gui.diff

- - - - - - - - - - - - - - - - - - - - - - - - -

@sebald:

1.  I assume you mean as a method of getting "NaNxInf" displayed instead of "nanxinf" (as my patch currently does).  If so, thanks I will look those up.

2.  My size.m is just an example of this bug!  Its simply the size method for the @A class...  It is not supposed to be general.  And yes it assumes 2D only.  It is not proposed for merging.


(file #33042)

Colin Macdonald <cbm>
Mon 09 Feb 2015 08:10:42 PM UTC, comment #5: 

Please create a single function that does this job instead of duplicating the code in multiple places.

John W. Eaton <jwe>
Group administrator
Mon 09 Feb 2015 06:57:02 PM UTC, comment #4: 

1.
Most of the follow examples from the project test for xisinf() and xisnan():


[@octave]$ grep '"NaN"' * -r
Binary file doc/interpreter/octave.info-5 matches
etc/OLD-ChangeLogs/ChangeLog.1:        with a sign) or "NaN").
gnulib-hg/m4/strtod.m4:    const char *string = "NaN";
junk.log:that was checked to see if it was 'N' for "NaN" rather than "NA".
libinterp/parse-tree/lex.ll:             || tok == "NaN" || tok == "nan")))
libinterp/corefcn/str2double.cc:%!assert (str2double ("NaN"), NaN)
libinterp/corefcn/data.cc:                      lo_ieee_float_nan_value (), "NaN");
libinterp/corefcn/pr-output.cc:            os << std::setw (fw) << "NaN";
libinterp/corefcn/pr-output.cc:            os << "NaN";
libinterp/corefcn/oct-stream.cc:            tval = (lo_ieee_is_NA (dval) ? "NA" : "NaN");
libinterp/octave-value/ov-fcn-inline.cc:                          tmp_arg != "NaN" && tmp_arg != "nan" &&
liboctave/util/lo-utils.cc:    os << "NaN";
liboctave/util/lo-utils.cc:    os << "NaN";
scripts/general/num2str.m:%!assert (num2str (nan), "NaN")
scripts/general/validateattributes.m:          w_size_str = strrep (w_size_str, "NaN", "N");
scripts/testfun/assert.m:%!   elseif (strfind (errmsg, "NaN"))


The project should have "NaN" ("Inf") defined as NANSTRING (INFSTRING) or something similar.

2.
Well, seems like some kind of change is needed...  The attached size.m file, is that supposed to be general?  If so, this doesn't seem correct:


octave:1> x = [1 2 3]
x =

   1   2   3

octave:2> dim = 1
dim =  1
octave:3> size(x,dim)
ans = NaN


Also, the range test should have a couple more checks for greater than 2:


function [n, m] = size(x, dim)

  sz = [nan inf];

  if ((nargin >= 2) || ...
      (nargout >= 2) || ...
      (nargin == 2) && (nargout == 2))
    error('size: invalid call')
...
end


Dan Sebald <sebald>
Sat 07 Feb 2015 06:16:49 PM UTC, comment #3: 

1.  Re: Inf and NaN: I agree but I don't know enough C++ to know how to do this (mixing sprintf(%g) and << perhaps).  I suggest we worry about whether this would in principle go in (esp. viz #43096 changes), then worry about fine-tuning this patch.

2.  Re:

> In the first example, sizes shouldn't be negative, so those
> should be displayed as unsigned numbers, not signed.


I don't think that is my point.  The code is converting double to int (apparently signed int).  But my size.m is returning "inf" and "nan" which are valid doubles, but apparently they convert to -BIGINT or something like that.

In case I wasn't clear: the "first example" is what currently happens.  The second output is what it should be, after my patch.

Colin Macdonald <cbm>
Sat 07 Feb 2015 05:24:25 PM UTC, comment #2: 

I haven't done so, but I think you'd just export the two patches at once.  That way when they find their way into the source tree it appears as one patch after another.  But individually is fine too as a developer can easily apply the changeset like a normal patch and then copy the comment used for commit.

Octave displays Inf and NaN:


>> x = 1/0
warning: division by zero
x = Inf
>> x = 0 * Inf
x = NaN
>>


so go with that.

In the first example, sizes shouldn't be negative, so those should be displayed as unsigned numbers, not signed.  (Or does the numel() routine returned signed?)

Dan Sebald <sebald>
Sat 07 Feb 2015 02:56:35 PM UTC, comment #1: 

Oops, I should add my patch is on top of a patch I submitted for https://savannah.gnu.org/bugs/?43096.  (I don't know enough yet about hg to squash the two commits to one patch).

Colin Macdonald <cbm>
Sat 07 Feb 2015 02:55:23 PM UTC, original submission:  

I attach a patch.

- - - - - - - - - - - - - - - - - - - - - - - -

"whos" and "gui" blindly convert sizes to int as if all objects would have integer sizes, how presumptuous ;-)

Seriously, examples where this is done:

1.  Matlab allows at least size to return "inf".  Chebfun (www.chebfun.org) does this for example.  I would like to get chebfun running on Octave soonish.  (Their logic is that a function in treated as a length infinity vector).

2.  I'm contemplating returning [nan 3] from size.m for matrices with symbolic size (e.g., "n x 3") in the "symbolic" pkg.

Both nan and inf sizes seem ok in Octave (no problems noted yet) but "whos" and the GUI display the sizes wrong:


   Attr Name             Size                     Bytes  Class
   ==== ====             ====                     =====  =====
        a      -2147483648x-2147483648                8  nansz

where "a" is "nan by inf" object.

- - - - - - - - - - - - - - - - - - - - - - - - - - - -

With my patch, I get:


>> a = nansz(42)
class is: nansz
 with data:
 42
>> whos
Variables in the current scope:

   Attr Name        Size                     Bytes  Class
   ==== ====        ====                     =====  =====
        a         nanxinf                        8  nansz

Total is 1 element using 8 bytes


This could be further improved to "NaNxInf" (as Matlab does), and/or perhaps also by using the unicode for $\times$.

Comments?

Colin Macdonald <cbm>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #33045:  infnan_sizes_in_whos_and_gui_v4.diff added by cbm (3KiB - text/x-patch - version 4 of patch, with unicode)
file #33043:  infnan_sizes_in_whos_and_gui_v3.diff added by cbm (3KiB - text/x-patch - version 3 of patch)
file #33042:  infnan_sizes_in_whos_and_gui.diff added by cbm (3KiB - text/x-patch - version 2 of patch)
file #33022:  nansz.m added by cbm (79B - text/x-objcsrc)
file #33023:  size.m added by cbm (244B - text/x-objcsrc)

 

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 jordigh (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by cbm (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-10 cbm Attached File- Added infnan_sizes_in_whos_and_gui_v4.diff, #33045
    2015-02-10 cbm Attached File- Added infnan_sizes_in_whos_and_gui_v3.diff, #33043
    2015-02-09 cbm Attached File- Added infnan_sizes_in_whos_and_gui.diff, #33042
    2015-02-07 cbm Attached File- Added nansz.m, #33022
        Attached File- Added size.m, #33023
        Attached File- Added infnan_size_whos_gui_output.diff, #33024

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code