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.

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 pttmconst.[cch]. 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 pteval.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.

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)'.

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 asis.
If this were only done for the 'else' case (nonnumeric 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.

Thu 14 Sep 2017 09:08:22 AM UTC, comment #4:
@Rik: this should be a special case:
Again Matlab 2017a:
and

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.

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

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/octavevalue/ovfcnhandle.h#l45
does not overwrite `octave_base_value::resize()`
https://hg.savannah.gnu.org/hgweb/octave/file/ec3d37eeafa2/libinterp/octavevalue/ovbase.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?

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'
