I am having some strange issues with cases/if statements that contain variables in the condition in addition to error() function in the result.

The issue only arises when the if/cases statements are in a function that is passed into another function. See attached.
Any thoughts?

variablesInConditions.sm (14 KiB) downloaded 38 time(s).
variablesInConditions.pdf (88 KiB) downloaded 44 time(s).

...

Wrote

...

This is certainly a workaround. Something I could do and perform error handling at the next level.
I'm more curious is this is an actual bug or if I'm doing something incorrectly.

Wrote

I'm more curious is this is an actual bug or if I'm doing something incorrectly.

Your function of function complains about the code as bug.
Will come back ... time to seed bean !

No more red, I don't understand the project.

variablesInConditions.sm (19 KiB) downloaded 29 time(s).

Hello, this is expected. By design because framework constraints, not by will, but it is the only way to have the function working in some contexts like inside integrals and such.

In case of numerical evaluation of the conditions, like in the if(...) function, the single cases are "sealed" from evalution up to when the conditions are actually evaluable. In cases(...) everything is always exposed to evaluation (and that's why you shouldn't use assignments inside the single cases). Hence, since error() is evaluated, it throws the error message.

Wrote

Hello, this is expected. By design because framework constraints, not by will, but it is the only way to have the function working in some contexts like inside integrals and such.

In case of numerical evaluation of the conditions, like in the if(...) function, the single cases are "sealed" from evalution up to when the conditions are actually evaluable. In cases(...) everything is always exposed to evaluation (and that's why you shouldn't use assignments inside the single cases). Hence, since error() is evaluated, it throws the error message.

Hi Davide,
Thanks for the explanation. I think I understand why cases(...) will not work. But I still receive a strange error when using if(...). Is this also expected?


variablesInConditions.sm (15 KiB) downloaded 32 time(s).

Hi, sorry the late answer!

Wrote

hanks for the explanation. I think I understand why cases(...) will not work. But I still receive a strange error when using if(...). Is this also expected?

Yes, altough I'm not sure if could be improved by Andrey somehow.

With some slight modifications on the names, you can see more clearly that the error is generated on the F1(2) preprocessing. Here x is passed as input to the first argument and if() fires the error.



The only alternative that comes to my mind right now is the one below. You have to pass the function name rather than the function itself.

It is a workaround, and if you pass it as a variable, the variable itself must be not defined.



variablesInConditions_alt1.sm (11 KiB) downloaded 40 time(s).

(The attachment has a more complicated function just to make the string input independant from localization settings)

More instances of if/otherwise failed in program.
if/otherwise does not belong to the Smath kernel.

Wrote

Hi, sorry the late answer!

Wrote

hanks for the explanation. I think I understand why cases(...) will not work. But I still receive a strange error when using if(...). Is this also expected?

Yes, altough I'm not sure if could be improved by Andrey somehow.

With some slight modifications on the names, you can see more clearly that the error is generated on the F1(2) preprocessing. Here x is passed as input to the first argument and if() fires the error.



The only alternative that comes to my mind right now is the one below. You have to pass the function name rather than the function itself.

It is a workaround, and if you pass it as a variable, the variable itself must be not defined.



variablesInConditions_alt1.sm (11 KiB) downloaded 40 time(s).

(The attachment has a more complicated function just to make the string input independant from localization settings)

Thanks Davide!
This workaround will suffice for me.