Davide, would it be possible to enable the use of custom units as variable names to solve for in FindRoot()?

The application case is statics of rigid bodies.

The vector sum of all forces is zero and the sum of moments about some reference point is zero. This is then solved for the support reactions.

This usually involves cross products. One of the vectors is typically a vector normalized by it's length and multiplied by an unknown scalar quantity (for which we later want to solve).

I've made quite some experiments on how to get the expressions right. These options seem to work:

- Mark the unknowns including any given quantities as units. This seems to flag them as scalars for SMath simplification.
- Use a custom cross product and Maxima. Then no custom units are required. This is actually a request for a better cross product in SMath.
- Mark the unknowns and any given quantities as units and use Maxima for simplification. This is actually used in 1-2.sm

Only the first version works without Maxima.
So if FindRoot() would accept unit names for unknowns then users could solve such problems without Maxima.

1-2.sm (125 KiB) downloaded 44 time(s).

Vektorprodukt.sm (193 KiB) downloaded 31 time(s).

Wrote

... The application case is statics of rigid bodies. ...

Hope that the attached helps. FindRoots (and roots) without maxima.

1-2.pdf (581 KiB) downloaded 54 time(s).
1-2.sm (138 KiB) downloaded 49 time(s).

Best regards.
Alvaro.

Hi Alvaro your proposal to use vectorize() for products of undefined variables with vectors is recomended by Andrey as well. But here is a simplified example of what can happen using this approach:


Unit vector.sm (8 KiB) downloaded 30 time(s).

In both cases, vectorization is dangerous as it doesn't fail in an obvious way but rather silently produces wrong results.

Martin

Hi Martin. You're right, vectorization in SMath, just like it did in mathcad, can easily produce results that aren't what one would expect, not to mention the one you mentioned earlier that varied depending on whether it was assigned to a variable or not. And as you very well say, it is not a recommended practice to try to explain the erratic behavior of a software in class, even more so if there is really no way to deduce what is due to it. And although perhaps an explanation could be found for that unit vector version, for the other one I don't really find sense. So I think it's a good idea that you could work with units to imply scalars. It would be necessary to add that the sum of these 'units' does not report an error so that its application is broader.

BTW, a workaround, but although I understand (I guess) why your example gives a "wrong" result, I'm not quite sure why this version gives a "correct" one. Maybe it's because the vector is already "spent" on the addition, but the rules are not clear as to why the addition "arrives" before the vectorization. That is to say, if I were to present this in class, assuming it was ethical for me to try to explain it, I would probably be in troubles if someone asked the slightest detail why that result is obtained.



Best regards.
Alvaro.

Hi Alvaro,

Your post supports my belief that there is no safe alternative to the scalarity assumption for undefined variables. Fortunately, units are assumed to be scalars and we can demonstrate how nice and smooth things work with this assumption.

Unfortunately, precious features like FindRoot() currently won't work with this. So I thought it was worth a bit of discussion to find out if there is really no safe alternative.

Perhaps Davide can enable handling of unit-like unknowns.

Yet there are disadvantages of the units approach
- you might run into "units don't match" (so far this was no problem in my applications)
- you have to avoid pre-defined names, ending up with text indices everywhere
- the borderline between where it is essential and where normal variables would do is uncertain

So for now I'd state these textbook rules for symbolic vector operations:
- Do not use vectorize.
- If an expected simplification fails, mark scalar variables as units.

It would probably be overkill to generally forbid ordinary non-unit variables.

Martin

It seems that there is a bug in Jacobian() from Nonlinear Solvers.

The application is to convert a system of equations to matrix form.

The built-in Jacob() function and Maxima's jacobian() work as expected, once you provide the correct type of arguments.

Jacobian() seems to not obey the order of entries in the variables vector (using the ordering returned by Unknowns() ).


Worksheet18.sm (20 KiB) downloaded 30 time(s).

Wrote

It seems that there is a bug in Jacobian() from Nonlinear Solvers.

The application is to convert a system of equations to matrix form.

The built-in Jacob() function and Maxima's jacobian() work as expected, once you provide the correct type of arguments.

Jacobian() seems to not obey the order of entries in the variables vector (using the ordering returned by Unknowns() ).

Odd, I'll check it, thank you Martin.