@sym/subsref: symbolic matrix subsref does not seem to work in m-file

[alexvong243f]

Normally, one can select the desired row or column of a symbolic matrix easily:

octave:1> A = sym ([1 2; 3 4])
Symbolic pkg v3.0.1+: using Pythonic interface, SymPy v1.10.1.
A = (sym 2×2 matrix)

  ⎡1  2⎤
  ⎢    ⎥
  ⎣3  4⎦

octave:2> B = A(1, :)
B = (sym) [1  2]  (1×2 matrix)

However, suppose we create the m-file inst/@sym/foo.m with:

function B = foo (A)
  B = A(1, :);
end

Then what we get is:

octave:1> A = sym ([1 2; 3 4])
Symbolic pkg v3.0.1+: using Pythonic interface, SymPy v1.10.1.
A = (sym 2×2 matrix)

  ⎡1  2⎤
  ⎢    ⎥
  ⎣3  4⎦

octave:2> B = foo (A)
B = (sym 2×2 matrix)

  ⎡1  2⎤
  ⎢    ⎥
  ⎣3  4⎦

which is clearly wrong.

This only happens when foo.m is placed in the @sym directory (and tested with symbolic matrices) but not when it is placed in the @double directory (and tested with numeric matrices). Also, it happens regardless whether we are using pythonic or not.

Can you reproducible it? Or is there something wrong with my installation?

[cbm755]

confirmed... and wtf?!

[cbm755]

oh wait! I know this... you cannot use raw indexing inside a class itself and instead must dance around with calling subsref and friends... is horrible. I have an issue for it somewhere, will link here.

[cbm755]

Issue #17. Aka "MoFo Issue #17" ;-) I hit this so often when I was starting this project. Is extremely frustrating.

grep * -rie "issue #17"
@sym/private/codegen.m:    %A(i) = C{i};  % Issue #17
@sym/private/codegen.m:      % MoFo Issue #17
@sym/findsym.m:      % MoFo Issue #17
@sym/fourier.m:%! % SymPy cannot evaluate? (Issue #170)
@sym/laplace.m:%! % SymPy cannot evaluate? (Issue #170)
@sym/double.m:      % temp = x(j)  (Issue #17)
@sym/find.m:      % issue #17:  v(n) = x(i(n), j(n));
@sym/symprod.m:    %a = n(1);  % issue #17
@sym/symprod.m:    %b = a(2);  % issue #17
@sym/symsum.m:    %a = n(1);  % issue #17
@sym/symsum.m:    %b = a(2);  % issue #17

[alexvong243f]

Closing for now since it's a feature... :)

[cbm755]

yeah "feature" :(

I think it indicates that a fundamental choice I made when starting this project might've been wrong: whether to use Octave arrays of SymPy scalar objects, or Octave objects that contain SymPy objects (which might be arrays). I did the latter.