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

 
 

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

Submitted by:  Alexander Klein <matalex>
Submitted on:  Mon 08 Feb 2016 04:06:32 PM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: ConfirmedAssigned to: None
Originator Name: Open/Closed: Open
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

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

and print_parens is

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

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.

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>
Project 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 File(s):
   
   
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
  • -unavailable- added by lachlan (Posted a comment)
  • -unavailable- added by mtmiller (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by dastew (Posted a comment)
  • -unavailable- added by matalex (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to 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 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 31 Mar 2016 05:13:37 AM UTCmtmillerOperating SystemBSD=>Any
      SummaryString representation of an anonymous function may not match its semantics=>string representation of a colon expression may be missing parentheses
    Tue 09 Feb 2016 12:39:43 AM UTCrik5StatusNone=>Confirmed
      Release3.8.2=>dev
    Mon 08 Feb 2016 04:06:32 PM UTCmatalexAttached File-=>Added source_me, #36277

    Back to the top


    Powered by Savane 3.1-cleanup1