Closed alexvong243f closed 2 years ago
confirmed... and wtf?!
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.
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
Closing for now since it's a feature... :)
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.
Normally, one can select the desired row or column of a symbolic matrix easily:
However, suppose we create the m-file
inst/@sym/foo.m
with:Then what we get is:
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?