Shouldn't the variable A be replaced by its value 1 when 'cases' is used instead of 'if/else'?

Wrote

Shouldn't the variable A be replaced by its value 1 when 'cases' is used instead of 'if/else'?

Whatever is behind the scene, your project is ill posed..
Conditional statements must be intelligible for the numerical maths.

I really don't want to play silly games with you anymore.

I asked a simple question: "Why is the value of the canvas variable A not stored in the function, when cases is involved?"

Your answer has absolutely nothing to do with my question.

I have attended another screenshot to show the consequences of not storing the value.
cases behaves, as if there where a line operator.



cases.sm (9,81 KiB) descargado 1151 vez(es).

I notice one instance if/otherwise does not work vs if/else.
Reported, not acknowledged ... maybe more than one instance.

... generally, if/else is more convenient in program.

Utilities Matrix Exclude Region.sm (35,43 KiB) descargado 1152 vez(es).

Wrote

.. generally, if/else is more convenient in program.

... refreshed

Utilities Matrix Exclude Region.sm (41,01 KiB) descargado 1119 vez(es).

... ill posed code don't speak, rather crash the project.
Glance for De Boor in Samples,,, will be pleased to re-post.

Citar

Shouldn't the variable A be replaced by its value 1 when 'cases' is used instead of 'if/else'?

Davide can answer this for certain. However, I would imagine that it should not. Since cases() function is kind of like a wrapper for nested if() statements, I imagine that it stays completely symbolic until evaluated numerically.

This is just a guess. Otherwise I would imagine that when you evaluated a cases() statement symbolically you would see the nested if() instead.

Wrote

... However, I would imagine that it should not. Since cases() function is kind of like a wrapper for nested if() statements, I imagine that it stays completely symbolic until evaluated numerically.

This is just a guess. Otherwise I would imagine that when you evaluated a cases() statement symbolically you would see the nested if() instead.

The two expressions in the screenshot in my first post are evaluated symbolically.
I think I can remember that in the past when "hovering the mouse" it was was dissolved in a chain (product) of boolean expressions, without using if/else.

Wrote

I think I can remember that in the past when "hovering the mouse" it was was dissolved in a chain (product) of boolean expressions, without using if/else.

Yes, It looks like that may have changed about two years ago according to this post: https://en.smath.info/forum/yaf_postsm35489_Custom-Functions-plugin.aspx#post35489

Which leads me to believe the cases() functions worked different depending on the optimization.

You can see source code here: https://smath.info:8443/!/#public/view/head/plugins/CustomFunctions/SMathFunctions/Programming/cases.cs

I'm not well versed enough in plugin creation to know how this is handled with different optimizations.

I suppose what it comes down to is how input variables are passed to a function defined in a plugin and when they are evaluated w.r.t. the different optimization options.

Wrote

The two expressions in the screenshot in my first post are evaluated symbolically.

Can't be evaluated otherwise => nothing is defined/assigned,
thus literal evaluation ... try this





Maybe you missed my other point about appropriate condition [De Boor]
You have that in much simpler instances, not visible and falsifying project.

The values of a, b and q(x) are not stored in f, as you can see in the following screenshot.


And by assigning f to f they are!
And that seems to me like a kind of invisible line operator, because it behaves like one.

Have you tried programing it? Use line in lieu of the system of values or equations bracket?

by--->MarB

Citar

Shouldn't the variable A be replaced by its value 1 when 'cases' is used instead of 'if/else'?

I do not understand. The cases function works perfectly.





cases_ok.sm (4,6 KiB) descargado 1144 vez(es).


Best Regards

Carlos

The all thing is about what comes from conditional.
For instance: the integration operator needs an analytical integrand.
From if/else, integrand is not scalar vs if/Otherwise.
Simple things turn nightmare ... many same in Mathcad.

Plots are same but not integration.

Wrote

From if/else, integrand is not scalar vs if/Otherwise.

... for this particular integration example, it is necessary and sufficeinet
to transform the domain of if/else [ infinitesimal ...] in scalar domain.
Here, we have it already done in term of integration.

Integrate Discontinuous [Nuance].sm (13,02 KiB) descargado 990 vez(es).

Wrote

I do not understand. The cases function works perfectly.

The difference comes when the value of A changes after the definition of f(x) and g(x).

For g(x) the original definition of A:=1 remains. However, for f(x) the value of A changes.


cases_ok_alyles.sm (5,57 KiB) descargado 1126 vez(es).

Citar

And by assigning f to f they are!
And that seems to me like a kind of invisible line operator, because it behaves like one.

So I believe I understand what is going on a little better.
I've attached the same .sm file as before only this time with break points. If you open the debugger window and step through you can see exactly what happens.
When f(x) is defined it sets f(x) equal to cases(a,xNote when g(x) is defined it will step through and evaluate the if() function and each individual input parameter (xThe cases() function within f(x) doesn't actually evaluate until it is called with f(0).
This is why, as you described earlier, if you set f(x):=f(x) you finally get the result that you want, because at this point it will finally evaluate cases(a,x
I'm not sure if this is a plugin issue or if this is just how SMath handles it's plugin interface.


cases_ok_alyles_with_breakpoints.sm (5,57 KiB) descargado 1143 vez(es).

Wrote

I'm not sure if this is a plugin issue or if this is just how SMath handles it's plugin interface.

This type of maths is universal and maybe centuries accepted,
and a rigorous rule since numerical computing machinery.

Just like this.