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

 Submitted by: Colin Macdonald Submitted on: 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

You are not logged in

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.

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>
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:

Jordi Gutiérrez Hermoso <jordigh>
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.

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".

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.

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>
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():

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:

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

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:

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:

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

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

With my patch, I get:

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

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

Do you think this task is very important?
This task has 0 encouragements so far.

Only project members can vote.