Correction SS-2316
1 vote

An error in cases() condition evaluation (Custom Functions plugin)

Created by Mike Kaganski on 4/13/2016 5:53 AM Last Updated by Davide on 9/15/2016 6:12 PM
Logged: 0   (hrs)


In attached file, the problem is demonstrated. If cases() is inside line() inside a function, it cannot work properly.

    Davide (Tuesday, September 13, 2016 5:40 PM) #

Please try with latest beta version of the plugin :)

    Davide (Friday, April 15, 2016 1:29 PM) #

The double evaluation mode (triple as for the truth, since "none" doesn't evaluate at all) was provided to make the functions based on cases(...) suitable for built-in integration (piecewise functions).
In symbolic mode, I can use if/else or made the function to return the function itself, but this means that wouldn't be possible anymore to use functions based on cases(...) for integrations (see attached, play with f(x)'s optimization; consider that by my design "none" returns the function itself, "numeric" an if/else, "symbolic" the sum with booleans).

I may be wrong but AFAIK there's no way to distinguish if the function it is running behind a programming-function or stand-alone; but I think you hit exactly the point here: except for very particular cases, a function in RHS shouldn't returns a result if in his arguments there are arguments of the parent function (LHS).

In your example, UnitsOf(whatever(a,b)) should be stored without evaluation of a and b because these are arguments of the parent function, thus "not yet defined for they're usage", regardless the optimization used; this means that provided this tool (or how to approach this task, if it is already possible - here we have to ask Andrey), it will be possible to made such functions working in the expected way

    Mike Kaganski (Friday, April 15, 2016 3:04 AM) #

Thank you Davide!

1. Can't you use "if"s in symbolic mode, too? isn't it suitable for symbolics?

2. A side question. Is there a possibility for you to differentiate between "stand-alone" mode and "function" mode? Because inside functions, it's often desirable that when the function is declared and optimized, some functions (like this) wouldn't optimize themselves, but return themselves as entered, to only be actually evaluated when the function is used.

To demonstrate, you may try the following (this example only uses in-build SMath functions):

f(a,b):=if UnitsOf(a)=UnitsOf(b)





This function will be cancelled out to f(a;b):=1, because at the optimization stage, the program incorrectly takes current values of a and b, that are unitless at that stage. eval() is unfortunately required here.

I would further suggest that both your cases() and Andrey's UnitsOf() would unconditionally return themselves instead of processing, when used in symbolic optimization.

Or alternatively, when inside a function, a call includes arguments (or their derivatives) that are of course unknown at this stage, SMath should somehow pass to plugins a flag that this argument is undefined, so that plugin function could choose if to return actual result, or return itself (or yet another intermediate variant).

    Davide (Wednesday, April 13, 2016 7:50 PM) #

This is because how it is implemented cases; if you use a numeric optimization, a nested if/else is used. If you use a symbolic optimization, a sum it is used.

As it is, outside programming functions you can setup the optimization from the context menu, inside programming functions you have to use eval().


I'll check if I can improve the sum to completely avoid the evaluation of unused terms.