bugGNU Octave - Bugs: bug #52009, allow creation of 1-by-1 array...

 
 

bug #52009: allow creation of 1-by-1 array with a single function handle

Submitted by:  Ernst Reissner <ernstreissner>
Submitted on:  Wed 13 Sep 2017 10:32:59 AM UTC  
 
Category: InterpreterSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: ConfirmedAssigned to: None
Originator Name: ernstreissnerOpen/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.

 

(Jump to the original submission Jump to the original submission)

Mon 18 Sep 2017 07:39:29 AM UTC, comment #8:

My initial idea of getting this done quickly, does not pay off, feeling similar to Rik in comment #7.

My suggestion of comment #1, just implementing `resize` for `octave_fcn_handle`, was not the ultimate solution. It requires to implement it for `octave_user_function` and some others too, as resize is called recursively in a way I do not understand. I am afraid to introduce more bad and unintended corner cases than just "fixing" that one.

Mike's idea of comment #5 appeals a lot to me. Avoid the resizing just where it is called without need, but this goes beyond my knowledge of that code.

So for now I am giving up on this item.

Kai Torben Ohlhus <siko1056>
Project Member
Fri 15 Sep 2017 07:09:15 PM UTC, comment #7:

This is probably beyond me. I took a look and I couldn't follow all the twists and turns between different templates for do_single_type_concat and single_type_concat in pt-tm-const.[cc|h]. It seems like eventually there is just an octave_value_extract<T> (...), but not clear to me how to promote some of that code up in to pt-eval.cc. Alternatively, it looks like there are occasional optimizations in the concat routines. Maybe they should be checking for the 1x1 case and optimizing there.

Rik <rik5>
Project Administrator
Fri 15 Sep 2017 04:38:30 PM UTC, comment #6:

I like the suggestion. It is a general phenomenon that

so for efficiency it would be nice if every data type avoided the unnecessary call to resize. But, yes we would have to have special decode logic for ranges since '[ ]' is the equivalent of 'full (x)'.

Rik <rik5>
Project Administrator
Fri 15 Sep 2017 04:22:05 PM UTC, comment #5:

I wonder if this could be handled (and would make sense to handle) in octave::tree_evaluator::visit_matrix with a special case. If the dimensions of the matrix expression are 1×1, there is no need to do any concatenation or resizing of the arguments. The result would just be the single object in the matrix expression as-is.

If this were only done for the 'else' case (non-numeric types) this should be safe. If it were done for all types it would break the case where '[1:10]' is turned into a normal Matrix, I don't think we want that.

Mike Miller <mtmiller>
Project Administrator
Thu 14 Sep 2017 09:08:22 AM UTC, comment #4:

@Rik: this should be a special case:

Again Matlab 2017a:

and

Kai Torben Ohlhus <siko1056>
Project Member
Wed 13 Sep 2017 10:51:36 PM UTC, comment #3:

Is this just a special case? What happens in Matlab if you try to reshape a function handle? Sample code:

As Kai pointed out, it might be very simple to overload resize() for function handles to allow 1x1.

Rik <rik5>
Project Administrator
Wed 13 Sep 2017 06:29:09 PM UTC, comment #2:

Same bug applies to function handle to a real function, not just anonymous functions

Mike Miller <mtmiller>
Project Administrator
Wed 13 Sep 2017 12:12:16 PM UTC, comment #1:

Confirmed, Matlab 2017a treats this case like there were no brackets:

vs. Octave (hg id

This is because Octave's `octave_fcn_handle`

https://hg.savannah.gnu.org/hgweb/octave/file/ec3d37eeafa2/libinterp/octave-value/ov-fcn-handle.h#l45

does not overwrite `octave_base_value::resize()`

https://hg.savannah.gnu.org/hgweb/octave/file/ec3d37eeafa2/libinterp/octave-value/ov-base.cc#l364

Maybe you can implement this method to just return itself, if the dimension vector is (1,1).

Anyways, I was curious, where did you find/use this border case?

Kai Torben Ohlhus <siko1056>
Project Member
Wed 13 Sep 2017 10:32:59 AM UTC, original submission:

The expression [@() true]
yields
error: octave_base_value::resize (): wrong type argument 'function handle'

Ernst Reissner <ernstreissner>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by siko1056 (Posted a comment)
  • -unavailable- added by ernstreissner (Submitted the item)
  • -unavailable- added by ernstreissner
  •  

    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 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 18 Sep 2017 07:39:44 AM UTCsiko1056Assigned tosiko1056=>None
    Thu 14 Sep 2017 09:08:22 AM UTCsiko1056Assigned toNone=>siko1056
    Wed 13 Sep 2017 06:29:09 PM UTCmtmillerItem GroupUnexpected Error=>Matlab Compatibility
      SummaryOctave does not ignore brackets around anonymous function [@() true]=>allow creation of 1-by-1 array with a single function handle
    Wed 13 Sep 2017 12:12:16 PM UTCsiko1056StatusNone=>Confirmed
      Summaryhandle in array-->error=>Octave does not ignore brackets around anonymous function [@() true]
    Wed 13 Sep 2017 10:32:59 AM UTCernstreissnerCarbon-Copy-=>Added -unavailable-

    Back to the top


    Powered by Savane 3.1-cleanup1