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

 
 

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

Submitted by:  Joel Dahne <urathai>
Submitted on:  Fri 24 Mar 2017 02:25:14 PM UTC  
 
Category:  Octave Forge 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

Add a New Comment (Rich Markup)
   

You are not logged in

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

 

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>
Project 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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project 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.5