bugGNU Octave - Bugs: bug #50626, Indexing with "end" does...

 
 

bug #50626: Indexing with "end" does not work for matrices of intervals

Submitter:  Joel Dahne <urathai>
Submitted:  Fri 24 Mar 2017 02:25:14 PM UTC
   
 
Category:  Octave Package Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 4.2.1 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 18 Apr 2017 10:17:12 PM UTC, comment #5: 

Agree to comment #4 and comment #3 claims to have resolved the issue.

Thus, closing report.

Kai Torben Ohlhus <siko1056>
Group Member
Fri 14 Apr 2017 06:16:15 PM UTC, comment #4: 

``end'' is discussed [here](https://www.gnu.org/software/octave/doc/interpreter/Defining-Indexing-And-Indexed-Assignment.html) starting with:


If you wish to use the end keyword in subscripted expressions of an object...


Colin Macdonald <cbm>
Mon 27 Mar 2017 06:01:38 PM UTC, comment #3: 

Thanks, works like a charm. I didn't know that you can override the “end” method. This should go into the Octave manual, probably somewhere here, next to overloading subsref and subsasgn:
https://www.gnu.org/software/octave/doc/interpreter/Operator-Overloading.html

What do Octave core developers think?

Anyway, I pushed your patch with minor adjustments:
https://sourceforge.net/p/octave/interval/ci/5139ef44ff4088222b2b71f37fca801d52534cbe/

Oliver Heimlich <oheim>
Mon 27 Mar 2017 02:27:34 PM UTC, comment #2: 

After looking at some other classes were usage of `end` does work I found that the only problem is that the interval package has no end.m function.

I attach a patch adding this function. Please take a look and see if it is correct.

(file #40169)

Joel Dahne <urathai>
Fri 24 Mar 2017 06:05:17 PM UTC, comment #1: 

I consider this a bug, but it might be difficult to fix. If you debug
into the subsref method (you can set a break point with `dbstop
@infsup/subsref`), you will see that it is called as if you had written
v(1). That means, Octave somehow evaluates the 1:end expression into 1
before calling the subsref method.

Background information: Classes, which are implemented as m-files, are
represented as “structure arrays” internally (see
https://www.gnu.org/software/octave/doc/interpreter/Structure-Arrays.html
). To avoid a lot of conversion overhead, interval matrices of size m×n
are stored as a 1×1 structure array object with two properties inf and
sup. The properties are matrices, which are of size m×n each. This way,
inf and sup are stored as two matrices. If I hadn't overridden the size
method, Octave would think that this object was of size 1×1. Maybe
Octave uses this (wrong) information when the 1:end expression is
evaluated, which might happen deep into Octave's C++ code where somebody
forgot to call the overridden size or numel methods of the @infsup class.

I have tried to store interval matrices as structure arrays of size m×n,
where each entry stores a scalar inf and sup boundary, but then I would
have to do a lot of conversion during computation and it would have a
big impact on performance.

Oliver Heimlich <oheim>
Fri 24 Mar 2017 02:25:14 PM UTC, original submission:  

When getting a subset of an interval matrix using `1:end` yields only the first element, the `end` syntax seems to always evaluate to 1.

For a normal vector we have

>> v = [1, 2, 3, 4, 5];
>> v(1:end)
ans = [1, 2, 3, 4, 5]


For a vector of intervals we instead get

>> v = infsup([1, 2, 3, 4, 5]);
>> v(1:end)
ans = [1]

Here `1:end` should be the same as `1:5` but it evaluates to `1:1`.

From what I can tell the problems seems to occur before the call to `subsref`. The input argument to `subsref` are consistent with `end` being evaluated to 1.

Joel Dahne <urathai>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #40169:  end-patch added by urathai (5KiB - 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 siko1056 (Posted a comment)
  • -email is unavailable- added by cbm (Posted a comment)
  • -email is unavailable- added by oheim (Posted a comment)
  • -email is unavailable- added by urathai (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-04-18 siko1056 StatusNone Fixed
        Open/ClosedOpen Closed
    2017-03-27 urathai Attached File- Added end-patch, #40169

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code