  Rank: Advanced Member Groups: Registered
Joined: 23/03/2016(UTC) Posts: 277  Was thanked: 91 time(s) in 57 post(s)
|
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 (15kb) downloaded 9 time(s). variablesInConditions.pdf (89kb) downloaded 17 time(s). |
|
|
|
|
|
|
 Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866  Was thanked: 981 time(s) in 809 post(s)
|
... 
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 23/03/2016(UTC) Posts: 277 Was thanked: 91 time(s) in 57 post(s)
|
Originally Posted by: Jean Giraud  ... 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. |
|
|
|
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
Originally Posted by: alyles 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 !
|
|
|
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
|
|
|
|
|
|
 Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,649   Location: Italy Was thanked: 1333 time(s) in 877 post(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. Edited by user 21 June 2023 20:09:37(UTC)
| Reason: Not specified |
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
 1 user thanked Davide Carpi for this useful post.
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 23/03/2016(UTC) Posts: 277 Was thanked: 91 time(s) in 57 post(s)
|
Originally Posted by: Davide Carpi 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 (16kb) downloaded 8 time(s). |
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered, Advanced Member Joined: 13/01/2012(UTC) Posts: 2,649 Location: Italy Was thanked: 1333 time(s) in 877 post(s)
|
Hi, sorry the late answer! Originally Posted by: alyles 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. ![2023-06-23 14_00_12-SMath Solver - [variablesInConditions_alt1.sm].png](/forum/resource.ashx?a=47433&b=2) 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. ![2023-06-23 15_20_28-SMath Solver - [variablesInConditions_alt1.sm_].png](/forum/resource.ashx?a=47438&b=2) variablesInConditions_alt1.sm (12kb) downloaded 12 time(s).(The attachment has a more complicated function just to make the string input independant from localization settings) Edited by user 23 June 2023 16:45:35(UTC)
| Reason: clarifications |
If you like my plugins consider to support SMath Studio buying a plan; to offer me a coffee: paypal.me/dcprojects |
1 user thanked Davide Carpi for this useful post.
|
|
|
|
Rank: Guest
Groups: Registered
Joined: 04/07/2015(UTC) Posts: 6,866 Was thanked: 981 time(s) in 809 post(s)
|
More instances of if/otherwise failed in program. if/otherwise does not belong to the Smath kernel. 
|
|
|
|
|
|
Rank: Advanced Member Groups: Registered
Joined: 23/03/2016(UTC) Posts: 277 Was thanked: 91 time(s) in 57 post(s)
|
Originally Posted by: Davide Carpi Hi, sorry the late answer! Originally Posted by: alyles 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 (12kb) downloaded 12 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. |
|
1 user thanked alyles for this useful post.
|
|
|
|
Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.
