Wrote

I'm agree. Do you have an exact example (which requires no additional plug-ins) where I can see an issue?

Regards.

Actually, not...

Except for the calculation output - when the output is null and the right side unit is not set (but this is widely acceptable, I think) - the zero-with-units handling of SMath Studio is very good...

The error shown above by Martin arises inside the plugin when you want to add parameters not given by the user (domain bounds, tollerances, etc...).

Using a set of homemade low-level functions to get or remove units (something like this code), I've tried with two approaches:
1) Assigning units to dimensionless parameteres from known values (functions, variables) -> if functions or variables are null I can't assign units -> when SMath parse the function at the first iteration retrieve an incongruence and (correctly) output an error; actually the workaround is to use a little non null value.
2) The second approach, that I'm following now (mainly for other purposes ), is to strip-off all input units, solve equations with dimensionless functions and parameters, and set again the units on the result. The issue with this approach is that you can have some dimensionless correct results (no unit as input no unit as output)

Maybe exist a secure way to obtain units from terms even when the functions/variables returns a dimensional null value (but I don't know it)

Wrote

I'd recommend to put all current material (beta and non-beta) to the topic starter posting. But never mind, I am now a bit more strict in archiving plugin distros (and just can cite uni: need more sleep...)

Thank you, done


best regards,

w3b5urf3r

Hi all,

there's a beta of Nonlinear Solvers available in the online gallery; is not yet finished (because I want to add other algorithms and a couple of new features, and obviously the multilanguage UI) but who want can try it (password: NonlinearSolvers)

Unfortunatly I can't make a complete documentation but you can referrer to:
- Martin's handbook
- this album


best regards,

Davide

Here is a proposal for a unit-proof and user-friendly linear solver.

Davide, I propose to include it in the NonLinearSolvers plugin, perhaps as FindRoot(1).

- Equations can be specified using boolean equal with arbitrary distribution of linear and absolute terms to left and right hand side
- equations and unknowns can have arbitrary and different units
- no need for initial guess
- no need for specification of result units

I was not able to reproduce the embedded assignment feature in the example procedure. I would propose to enable that by default and perhaps provide an optional assignment flag.
Also, a linearity check (e.g. hessian-based) might be sensible.

The procedure LinSolve() looks more cumbersome than it ought to be, because of unreliable symbolic matrix inversion and multiplication. Fortunately, the alg() function works and thus the inverse can be computed with moderate coding effort.

LinSolve() provides an alternative for "hand made" sparse linear systems, as they typically occure in basic engineering mechanics. For densly populated systems, the matrix notation of the system might be more appropriate.

---

Martin!

Thank you for your perfect work and bright examples. This function will be very helpful for us when it will be included to the plugin.

The best regards,
Janusz

Wrote

Here is a proposal for a unit-proof and user-friendly linear solver.

Davide, I propose to include it in the NonLinearSolvers plugin, perhaps as FindRoot(1).

- Equations can be specified using boolean equal with arbitrary distribution of linear and absolute terms to left and right hand side
- equations and unknowns can have arbitrary and different units
- no need for initial guess
- no need for specification of result units

I was not able to reproduce the embedded assignment feature in the example procedure. I would propose to enable that by default and perhaps provide an optional assignment flag.
Also, a linearity check (e.g. hessian-based) might be sensible.

The procedure LinSolve() looks more cumbersome than it ought to be, because of unreliable symbolic matrix inversion and multiplication. Fortunately, the alg() function works and thus the inverse can be computed with moderate coding effort.

LinSolve() provides an alternative for "hand made" sparse linear systems, as they typically occure in basic engineering mechanics. For densly populated systems, the matrix notation of the system might be more appropriate.

I agree with you completely . Your solution is quite educative and very interesting. A linear solver of this kind would be rather appreciated. We are also aware of unreliable Jacobian (derivatives) calculation, matrix inverse etc. Nevertheless, classical nonlinear solver approach could stuck if you give the linear system and try to force it in a nonlinear fashion. I suppose that you gave the idea to Davide how to make a basically linear solver. I just would like if there would be a possibility to incorporate into the solvers some kind of linearity check, like you said, and the option to solve it as a linear problem.

Regards,
Radovan

Thank you Martin, I'll add surely your code into the plugin

Wrote

I just would like if there would be a possibility to incorporate into the solvers some kind of linearity check, like you said, and the option to solve it as a linear problem.

me too...

I agree

BTW also DotNumerics contains some linear solvers

Wrote

Your solution could be of certain practical interest (!?).
Linking this topic (of linear solvers) with that of non linear solvers is not the best way of dealing the subject, in my opinion.
Using SMat for sparse matrix linear solvers seems attractive for me.

The only reason why I posted the issue here is that I see the proposed linear solver as a special case of the findroot function in the nonlinear solvers plugin. I am very happy with the user interface of this solver, in particular
- the flexible way to specify the equations (in close to natural notation)
- unrestricted use of units
- and the embedded assignment, which allows me to display and use the unknowns as soon as the solver was called, without any post-processing.

It is just laziness that I do not want to specify initial guesses when that should not be necessary.

With the term "sparse matrix solver" I had in mind just moderate systems with hand-written equations, let's say e.g. equilibrium conditions next to free body diagrams.

Some numeric libraries (like ITPACK) provide dedicated solvers for sparse matrices with elaborate storage techniques. This issue is by no way related to my proposal.

However, I would not mind the moderators to shift the discussion to a separate topic. For the time being I hope for ruthless testing of the proposed algorithm.

Wrote

I agree

BTW also DotNumerics contains some linear solvers

You are right , and that is very useful by using different algorithms for say, overdetermened, underdetermined systems etc. (some testing from the users might be useful here). Moreover, as I figured out, these functions need matrices of the system A and resulting vector B. Martin posted an alternative to this problem and gave it in a bit different form pointing out to the FindRoot() functions from NonlinearSOlvers plugin and equations given with boolean equal to. I've just commented that because this remind me on the ability of some symbolic engines which are capable of solving the linear equations which do not look linear at all at, a first glance. I meant something like this:

[MATH=eng]maple(solve(sys(5*x-6≡8,5+6*x/y≡10*z/y,x/y≡3,3,1),sys(x,y,z,3,1)))=mat(14/5,14/15,161/75,3,1)[/MATH]

but I do not know if something like this could be done directly in SMath.

Regards,
Radovan

I found an example, where FindRoot() silently returns a solution that by far does not solve the given equations. It is ok that the solution may depend on initial values. In the given case, however, there is only a single solution and the wrong result is not converged. I have no idea what causes the problem. Setting tight error limits does not help.

---

Example Linsolve Beam2.sm (21 KiB) downloaded 93 time(s).

Thank you Martin for this,

It is interesting to note that FindRoot() would take a considerable time to solve it with the appropriate initial guess (about 2min on my comp). I have no idea why FindRoot() gave the wrong results with some other initial guess (hope that Davide will find the problem). I also tried DotNumeric solver - see the picture please. The difference is regarding "units like variables" (no units here). The result might not be considered correct, and regarding that this is a numerical solver, I have no idea how dn_LinAlgSolve() escaped from this.

Regards,
Radovan

---

Wrote

The difference is regarding "units like variables" (no units here). The result might not be considered correct, and regarding that this is a numerical solver, I have no idea how dn_LinAlgSolve() escaped from this.

Let me just contribute a guess, Andrey may confirm or correct: Any unit that is not assigned to any dimension, is considered to be a base unit system on it's own. Thus, for procedures that cannot handle units, they are just set to one and the user must take care to assign the correct unit to the result. I do not think that dn_LinAlgSolve() has any provisions for handling this (uni, correct me if I am wrong).

The functions Gradient and Gradient.CD complain if the function is a vector.

---

Gradient.CD.sm (9 KiB) downloaded 89 time(s).

Why not Jacobian(), Jacobian.CD() from this plugin?

Regards,
Radovan

---

Wrote

Why not Jacobian(), Jacobian.CD() from this plugin?

Because I just wanted to fill the gaps of the active book function reference. I had the impression from the test file that the function was meant to handle vector functions. Davide, correct me if that is wrong.

Wrote

Wrote

Why not Jacobian(), Jacobian.CD() from this plugin?

Because I just wanted to fill the gaps of the active book function reference. I had the impression from the test file that the function was meant to handle vector functions. Davide, correct me if that is wrong.

Yes, you are right about the test file (Gradient_testing.sm). I did not remember this in the first place, but guessed there must be a reason you asked about it

Regards,
Radovan

This feature was deleted in the alpha version, I'll think if could be restored...

Wrote

This feature was deleted in the alpha version, I'll think if could be restored...

No special need for that. If Gradient is deprecated and replaced by Jacobian(), then be it.

Jacobian.CD seems to be unstable.

Davide, do you have any valid test or demo file, describing the expected functions?

---

Thank you Martin,

you are right, I'll try to fix it...

---