[Octave-bug-tracker] [bug #56006] Object indexing: obj(1).property(end+1:n) - end is interpreted wrong

[Andrew Janke]

URL:
  <https://savannah.gnu.org/bugs/?56006>

                 Summary: Object indexing: obj(1).property(end+1:n) - end is
interpreted wrong
                 Project: GNU Octave
            Submitted by: apjanke
            Submitted on: Wed 27 Mar 2019 02:21:41 AM UTC
                Category: Interpreter
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: Mac OS

    _______________________________________________________

Details:

I'm running into a weird indexing issue.

Let's say I have a class Version, that represents software versions.


classdef Version
  properties
    elements = [0]
  endproperties
  methods
    function this = Version (elements)
      if nargin == 0
        return
      endif
      this.elements = elements;
    endfunction
    function disp (this)
      fprintf ("Version: %s\n", mat2str(this.elements));
    endfunction
  endmethods
endclassdef


I have a 3-element Version that I want to pad out with zeros to be six
elements. If it is a scalar Version object and I address it as such, this
works fine.


octave:16> v = Version([3 3 3])
v =
Version: [3 3 3]

octave:17> v.elements(end+1:6) = 0
v =
Version: [3 3 3 0 0 0]


But if I have an array of Version objects and I index them individually before
addressing their property, the wrong elements get overwritten.


octave:19> v = Version([3 3 3])
v =
Version: [3 3 3]

octave:20> v(1).elements(end+1:6) = 0
v =
Version: [3 0 0 0 0 0]

octave:21>


It seems like in this case, the `end` is being interpreted with respect to the
size of v or v(1), not the size of v(1).elements (which I think it should
be).

Happens in 4.4.1, 5.1.0, and default.





    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?56006>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/