bugGNU Octave - Bugs: bug #53000, Variable editor: Value of '0' is...

 
 

bug #53000: Variable editor: Value of '0' is not aligned correctly

Submitter:  Rik <rik5>
Submitted:  Mon 29 Jan 2018 04:43:29 PM UTC
   
 
Category:  GUI Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Feature Request
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 02 Feb 2018 08:38:19 PM UTC, comment #16: 

I pulled the latest code (24676:b5dbcfa1e3e7).  I certainly can see a change in both the core's PR-printout--or whatever it is called--and the VE display.  Basically,


>> z_cell_mix = {"0";1}
z_cell_mix =
{
  [1,1] = 0
  [2,1] =  1
}

>> openvar z_cell_mix
>> z_cell_mix{2,1} = 001.2300
z_cell_mix =
{
  [1,1] = 0
  [2,1] =  1.2300
}


Compare both of the above with what I listed in #14.  Now the numeric cell entry is not right-aligned, but left-aligned--it also has the 4 number fractional width where before the 00 was dropped.  But here again it looks like the number entry is leaving a space at front for the minus symbol.

When viewed within V.E., the above has both fields left-aligned and that space in front of 1.2300 above is gone.

And, as Rik reported, the trailing 00s are dropped in V.E. for something like


>> x = [1; 1.23]
x =

   1.0000
   1.2300

>> openvar x


So, there looks to be a combination of things, in the core and whatever Qt tables are doing.

Dan Sebald <sebald>
Fri 02 Feb 2018 08:01:06 PM UTC, comment #15: 

@jwe: Still happens for me.


x = [0.1; 0.123]
x =

   0.10000
   0.12300

openvar x


See attached screenshot.

This is with


parent: 24673:5c1d6ea818cd tip
 fix regression in formatted output introduced in d4dd741b2794
branch: default


I tried 'format long' as well and the size of the field grew bigger, but it was just padded with blanks.  There is still no string of trailing zeros.



Rik <rik5>
Group administrator
Fri 02 Feb 2018 07:46:57 PM UTC, comment #14: 

There may be a spread-sheet-like interpretation of the entered string.  It's clear there is a difference.  Try the following:


>> z_cell_mix = {"0";1}
z_cell_mix =
{
  [1,1] = 0
  [2,1] =          1
}

>> openvar z_cell_mix


(Note how the above variable print-out has strings left-aligned, numbers right-aligned.)  Now experiment with entering in these entries something like "001.2300" in these cells.  For the numeric cell, the 00 is dropped.

Then again, a similar thing happens when I do so at the command line:


>> z_cell_mix{2,1} = 001.2300
z_cell_mix =
{
  [1,1] = 001.2300
  [2,1] =       1.23
}


But maybe cells are different from arrays within Octave core too:


>> x = [1; 1]
x =

   1
   1

>> x(2)
ans =  1
>> x(2) = 1.23
x =

   1.0000
   1.2300

>> x(2)
ans =  1.2300


Perhaps there is a special table member function which sets the table cell entry to be a string even if the ASCII translates to a valid string.  Or experiment with tacking an apostrophe to the front of what is passed to the Qt table, as I know in spreadsheets entering something like '0123 (only apostrophe at front) will interpret the contents as a string rather than numeric.

This could explain the left-aligned "0" and possibly why I was seeing the initial left-aligned numbers suddenly jump to right aligned.  I'm not sure how, but I would guess it can be a confusing lost-in-translation kind of thing.

Dan Sebald <sebald>
Fri 02 Feb 2018 07:31:31 PM UTC, comment #13: 

Rik, I don't see this behavior with the current sources.  Is it still happening for you after 5c1d6ea818cd?

John W. Eaton <jwe>
Group administrator
Fri 02 Feb 2018 06:57:40 PM UTC, comment #12: 

If Qt is stripping out zeros, that's really strange because we are giving Qt QString object containing the formatted numbers, not numeric values (double, float, int32_t, whatever).


John W. Eaton <jwe>
Group administrator
Fri 02 Feb 2018 05:39:28 AM UTC, comment #11: 

I think the problem with decimal alignment might be caused by Qt stripping out extra '0's.  In the Command Window


x = [0.1; 0.123]
x =

   0.10000
   0.12300

openvar x


In the Variable Editor these numbers are displayed as


  0.1
0.123


The floating point numbers are right-aligned, but the zeros have been stripped so decimal points don't align.

Rik <rik5>
Group administrator
Fri 02 Feb 2018 02:24:25 AM UTC, comment #10: 

I'm testing some recent mods to the variable editor autofit/optimal-width.  In particular

changeset:   24670:62a05d23cd00

I find that the autofit isn't the way I'd prefer.  It seems to be right-aligning within a 10-character width, which doesn't seem to achieve optimal width for matrices that have short numbers like zeros() or eye(), that is "0" or "1".

Try the following:


clear all
y = eye(5);
openvar y;


At this point I see in the V.E. the cell contents are left aligned.  Now, select one of the cells and change a value from, say, "0" to "123".  All of the numbers in the table will suddenly become right aligned.

Furthermore, decimal points don't align, enter 1.23 in one cell and 12.3 in a cell below that one.  (It's OK to not have alignment, but if there is any, decimal point would be my preference.)

[From a different bug report]  Now, as to the autofit behavior, the one thing we have right now is the double-click to autofit feature that Philip mentioned. I use that, and the autofit doesn't seem quite right. As an example, do


x = zeros(50);
openvar x;


There is a great deal of whitespace to the left of the zero when there could be more columns autofit in the view. Also, if I shrink the width of column 1, say, down to nearly nothing and double-click the line between column 1 and 2, the autofit occurs and goes back to that large-pre-whitespace width. If I expand the first column so there is a large amount of white space after the zero and double-click the line the the column goes back to the original autofit size. So it seems that there is more pre-whitespace than necessary or some type of minimum limit on the column width. Is this happening because the code attempts to align the numbers, i.e., its format is 10 character width numbers so that is somehow the minimum allowable size?

Dan Sebald <sebald>
Mon 29 Jan 2018 10:54:32 PM UTC, comment #9: 

I think we do want to respect what the user has set over in the Command Window.  I like the display over there and I expect it to be the same in the GUI as in the terminal.

Rik <rik5>
Group administrator
Mon 29 Jan 2018 10:47:51 PM UTC, comment #8: 

Yes, it's exactly the same issue with decimal point alignment, something that is probably best solved by the method I described earlier.  Especially if we want the display in the editor to respect format settings.  Do we?  Some people might like to see engineering format, or fixed format, or always have "long E" or whatever.

John W. Eaton <jwe>
Group administrator
Mon 29 Jan 2018 10:45:46 PM UTC, comment #7: 

Dispatch on type is already done by way of a virtual function in the octave_value class hierarchy.

John W. Eaton <jwe>
Group administrator
Mon 29 Jan 2018 10:45:16 PM UTC, comment #6: 

This is probably related, but when there are decimal points and scientific notation the numbers are not always aligned vertically.

Steps to reproduce:


x = [1; 1e-3; 1e-6; 1e-9];
openvar x


I would expect that the initial '1' in all of these numbers is aligned.

Rik <rik5>
Group administrator
Mon 29 Jan 2018 10:44:57 PM UTC, comment #5: 

We aren't actually specifying the format at the moment, we are just calling octave_print_internal on the array element and letting it do its thing.

John W. Eaton <jwe>
Group administrator
Mon 29 Jan 2018 10:38:24 PM UTC, comment #4: 

Makes sense.  Why not just add the space to the output format?  That would take care of the problem, and wouldn't even require parsing the value to display (although you would do that anyways to determine integer or floating point).

Rik <rik5>
Group administrator
Mon 29 Jan 2018 10:27:16 PM UTC, comment #3: 

The problem with alignment is caused by only looking at one element at a time in the variable editor.  That's the way this table widget works.  It requests a single element for display at any given time.

When Octave displays an array in the command window, it looks a the values of the whole array to decide what format to use.  We could do something similar for the variable editor when the first element of an array is displayed and then cache the result for subsequent elements.  I've been thinking about trying this, but just haven't gotten to it yet.

John W. Eaton <jwe>
Group administrator
Mon 29 Jan 2018 10:07:29 PM UTC, comment #2: 

You're correct.  Using '-0' does align things.  Where is the format being specified?  Can we mess with adding ' ' to that format string so that this happens:


' '    (a space) A blank should be left before a positive number (or empty string)
       produced by a signed conversion.



Rik <rik5>
Group administrator
Mon 29 Jan 2018 08:52:45 PM UTC, comment #1: 

Strange.  It's only the zero that will align one character to the left.  I say one character because if I mouse-drag expand the columns/cells it's clear that the numbers/contents are left-aligned.  But all numbers, except 0 (and that includes fractions which begin with 0), are aligning left but leaving one extra blank character at the front--it's as though the numbers are leaving space for a negative symbol at the front.  Maybe the code is assuming that a 0 cannot have a minus sign in front of... but of course it can in Octave, i.e., -0 is valid.

Dan Sebald <sebald>
Mon 29 Jan 2018 04:43:29 PM UTC, original submission:  

The value '0' has a different justification then any other value when displayed in the variable editor.  This causes columns of numbers to mis-align.  It is not tragic, but it is annoying and the terminal output, for example, already gets this right.

Sample code:


>> x = magic (3)
x =

   8   1   6
   3   5   7
   4   9   2

>> x(2,1) = 0
x =

   8   1   6
   0   5   7
   4   9   2

>> openvar x


Notice how the the number '0' aligns with '8' and '4' in the first column.  Attached is a screenshot of how it displays in the variable editor with the '0' cell left-aligned.

Rik <rik5>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #43106:  Var_Editor_0.png added by rik5 (12KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by rik5 (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-02-02 rik5 Attached File- Added Screenshot_20180202_115841.png, #43157
    2018-01-29 rik5 Attached File- Added Var_Editor_0.png, #43106

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code