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


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

Submitted by:  Rik <rik5>
Submitted on:  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

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( 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,

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

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.

See attached screenshot.

This is with

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.

(file #43157)

Rik <rik5>
Project 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:

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

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

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

In the Variable Editor these numbers are displayed as

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

Rik <rik5>
Project 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:

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

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

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

Rik <rik5>
Project 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>
Project 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>
Project 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>
Project 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:

Rik <rik5>
Project 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:

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>
Project Administrator


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

Attach Files:

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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    Fri 02 Feb 2018 08:01:06 PM UTC rik5 Attached File- => Added Screenshot_20180202_115841.png, #43157
    Mon 29 Jan 2018 04:43:29 PM UTC rik5 Attached File- => Added Var_Editor_0.png, #43106

    Back to the top

    Powered by Savane 3.3