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)



Thank you, done


best regards,

w3b5urf3r

Edited by user 07 May 2013 00:42:12(UTC)  | Reason: Not specified

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

Edited by user 05 August 2013 12:45:49(UTC)  | Reason: Not specified

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:

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)

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

Regards,
Radovan

Edited by user 05 August 2013 22:37:43(UTC)  | Reason: Not specified

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

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

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.

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

Jacobian.CD seems to be unstable.

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