bugGNU Octave - Bugs: bug #47091, string representation of a colon...

 
 

bug #47091: string representation of a colon expression may be missing parentheses

Submitter:  Alexander Klein <matalex>
Submitted:  Mon 08 Feb 2016 04:06:32 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 20 Aug 2018 01:47:28 AM UTC, comment #8: 

This is why debugging is so hard.  Turned out not to be in printing or parsing.  This now works for me as well.  Marking as fixed and closing report.

Rik <rik5>
Group administrator
Sun 19 Aug 2018 08:49:24 PM UTC, comment #7: 

Hi,

This fixed the issue for me.
It also fixes the outputs in comment #2.

Juan Pablo Carbajal <juanpi>
Group Member
Sat 18 Aug 2018 05:51:25 PM UTC, comment #6: 

I pushed the following change on stable and merged with default:

http://hg.savannah.gnu.org/hgweb/octave/rev/a8a72d1c21dd

John W. Eaton <jwe>
Group administrator
Fri 17 Aug 2018 10:37:07 PM UTC, comment #5: 

This should be relatively simple to fix, but Lachlan was right that this is an issue in the parser rather than an issue with printing.  I'm adding jwe to the CC list since I don't know the parser at all well.

If I create a file tmp.m with the following contents


a = 1;
b = 4;
a + (2:b)


and then run it with all commands set to be echoed I get


octave:2> echo on all
octave:3> blah
+ a = 1;
+ b = 4;
+ a + (2:b)
ans =

   3   4   5

+


In this case, the parentheses are properly printed.

Looking at oct-parse.yy, there is only one place where the function mark_in_parens() is used which is in the rule for "primary_expr"


                | '(' expression ')'
                  { $$ = $2->mark_in_parens (); }


It seems like somehow the rule for anon_fcn_handle does not manange to hit primary_expr.


anon_fcn_handle : '@' param_list stmt_begin expr_no_assign



Rik <rik5>
Group administrator
Fri 17 Aug 2018 12:57:36 PM UTC, comment #4: 

Pinging this bug, it is still there in 4.4.0.
I hit it when I got a saved file from a colleague

Here there is a Minimal, Complete, and Verifiable example.

Do we need to increase the Severity of this bug?


> a=10;
> b=3;
> f=@() a+(1:b);
> f,
f =

@() a + 1:b

> f(),
ans =

   11   12   13

> save('/tmp/tt.mat', 'f');
> clear all;
> load ('/tmp/tt.mat');
> f,
f =

@() a + 1:b
> f()
ans = [](1x0)


Juan Pablo Carbajal <juanpi>
Group Member
Fri 17 Jun 2016 05:35:56 AM UTC, comment #3: 

I don't think this is about the printing, but about the construction of the parse tree.

First: for functions in files, the parentheses are printed correctly with "echo on all".

Second:  The printing code starts


tree_print_code::visit_colon_expression (tree_colon_expression& expr)
{
  indent ();

  print_parens (expr, "(");


and print_parens is


tree_print_code::print_parens (const tree_expression& expr, const char *txt)
{
  int n = expr.paren_count ();

  for (int i = 0; i < n; i++)
    os << txt;
}


It seems to me that  num_parens  [the variable behind paren_count()]  isn't getting set for colon expressions in anonymous functions.

Lachlan Andrew <lachlan>
Tue 09 Feb 2016 12:39:43 AM UTC, comment #2: 

This affects anonymous functions saved in binary format as well.

The issue is quite easy to see at the command line even without saving the variable.


octave:36> f = @(m,n) 1 + m:n + 5
f =

@(m, n) 1 + m:n + 5

octave:37> f(1,2)
ans =

   2   3   4   5   6   7

octave:38> f = @(m,n) 1 + (m:n) + 5
f =

@(m, n) 1 + m:n + 5

octave:39> f(1,2)
ans =

   7   8


From the second example you can see that Octave knows that 'm:n' is an atomic unit, but it just isn't displayed that way.

Interestingly enough, for a definite range, i.e., values are fixed, the parentheses are correctly added.


f = @(m,n) m + (1:4) + n
f =

@(m, n) m + (1:4) + n


I believe Octave walks it's own internal parse tree of the function in order to print it.  It seems like it should be able to determine whether or not the range is atomic and print the parentheses as necessary.

Rik <rik5>
Group administrator
Mon 08 Feb 2016 04:16:58 PM UTC, comment #1: 

confirmed on Ubuntu 15.10 and octave DEV from 2 days ago.

Doug Stewart <dastew>
Mon 08 Feb 2016 04:06:32 PM UTC, original submission:  

When saving and loading variables containing anonymous functions, the string representation in the output file may not match their semantics.

What apparently happens in the attached example is that upon converting the function f back to a string when saving, the brackets surrounding the colon expression get trashed, and when again converting the new - and wrong - string representation to a function, the + operator takes precedence over the :, as it should, and we get funny results.

Alexander Klein <matalex>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #36277:  source_me added by matalex (157B - application/octet-stream)

 

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 rik5
  • -email is unavailable- added by juanpi (Posted a comment)
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dastew (Posted a comment)
  • -email is unavailable- added by matalex (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-08-20 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2018-08-18 jwe StatusConfirmed Ready For Test
    2018-08-17 rik5 Carbon-Copy- Added jwe
    2016-03-31 mtmiller Operating SystemBSD Any
        SummaryString representation of an anonymous function may not match its semantics string representation of a colon expression may be missing parentheses
    2016-02-09 rik5 StatusNone Confirmed
        Release3.8.2 dev
    2016-02-08 matalex Attached File- Added source_me, #36277

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code