Fixed, plugin updated.

The function mat2sys.1 affects also the inner matrix, if evaluated numerically AND if this inner matrix contains only element.

Is that really the intended behaviour?



I wanted to build my own mat2sys.1 using num2str, ... replace mat with sys... str2num
Looks like str2num is the "culprit", at least in my own function (only while evaluating numerically).



Maybe the better question is: Is this behaviour of str2num intended?

Wrote

Is that really the intended behaviour?

There are miscellaneous applications, mostly Fourier stuff.

Fourier Geometric Coplanar COMPLEX.sm (17 KiB) downloaded 76 time(s).

... I don't understand the remaining of the demand.

The behaviour is driven by the evaluation of the outer sys(); on numerical evaluation, the "first level" of 1x1 matrices is suppressed.



I'm not sure if it is really intended, but it might be part of the special behaviours of sys() (have to check the code/ask Andrey).

By now I think it's the general behaviour (intended or not), that 1×1 matrices are evaluated to its element (numeric).

That's why I use Gettype() to check if an element was found.

Found a bug in cases in combination with for loops and continue:

Two identical loops.
If if(,,) is used, continue causes the rest to be skipped (as expected).
If cases(,,) is used, continue has no effect

appVersion(4)="0.99.7822.147"

Wrote

Sorry for pulling this to the surface.

I am wondering if I am the only one, who's using continue/break in a similar way.
At the moment I replace every cases with if(s), when used in combination with for loops and continue/break.

Wrote

Found a bug in cases in combination with for loops and continue:

Two identical loops.
If if(,,) is used, continue causes the rest to be skipped (as expected).
If cases(,,) is used, continue has no effect

appVersion(4)="0.99.7822.147"

Confirmed, with a strange behavior.
Reversing the cases makes it correct.

At first glance I'm not sure about the cause, I'll check it.

However looking at the screenshot I have to point out once again that in general you shouldn't put definitions inside cases().
Unlike if(), when a condition or a case fails instead of throwing an error the whole function is returned like if doesn't exists. The consequence is that every argument is exposed and preprocessed, with potential unwanted behaviors respect to the expected logic. This is on the edge of SMath possibilities, but is what makes possible to use cases() whereas if() usually fails.

Wrote

Sorry for pulling this to the surface.

Nothing to be afraid, is in the best interests of anyone having things to work flawlessly

Wrote

Confirmed, with a strange behavior.
Reversing the cases makes it correct.

Interesting, nice catch .

PLUGIN UPDATED SMath Studio 0.99.7822 and later

• image2rgb/image2rgba: implemented different algorithm for linux users;
  
• image2rgb/image2rgba fixed exception on failed disposal of temporary files;

cases() refuse to be vectorized if it is a function.

Sometimes a line at the right place helps a lot.

And hovering the mouse over an expression helps finding the glitch.

Wrote

Sometimes a line at the right place helps a lot.

And hovering the mouse over an expression helps finding the glitch.

Hah, I get it. Mysterious (but necessary according to this) line again.
Even though I use smath several years, I still forgot some of its tricks.
No need to hover the mouse, lasterror() has the same behavior.

Regards