NonlinearSolvers plugin - BDQRF, Bisection, Brent's, Broyden's, Newton-Raphson, Ridder's, Secant, Homotopy - Messages
WroteHello w3bsurf3r,
I played around with nonlinear solvers, unfortunately without any success. At least not if units are involved.
Are the solvers supposed to work with units?
- can the unknown variables have units (given via units of limits or start point)?
- need the epsilons have units as well?
do I need to define functions or can I just give expressions as first argument?
Are the solvers supposed to work with units? -> yes...
- can the unknown variables have units (given via units of limits or start point) -> yes...
- need the epsilons have units as well? -> yes, of course...
...but something is clearly broken, somewhere

Indeed most of my problems were caused by my wrong assumption of epsilon being a tolerance to the unknown variable to be solved for. Obviously it is a tolerance to the function. I remember that we had a discussion on the subject if we should have tolerances to variables and function values and how to specify them. For now I shall assume that all implemented Solvers assume function tolerances.
The question of function vs. expression remains open.
Martin
Wrote
Are the solvers supposed to work with units? -> yes...
- can the unknown variables have units (given via units of limits or start point) -> yes...
- need the epsilons have units as well? -> yes, of course...
Thanks for clarifying, now I made some progress.
I still fail to specify systems of equations correctly. Any idea what is wrong?
I like the feature of the roots() function that you can specify an equation with RHS and LHS. As I understand the solvers in the plugin do not allow that type of specification. Ok, it is allowed but then the solution is any set of unknowns that render the equations unsatisfied (boolean equal giving 0).
Would that be difficult to implement (perhaps by internal transformation to standard form)?
AS 7-7Bisection.sm (99 KiB) downloaded 102 time(s).
Martin
Bisections_testing.sm (29 KiB) downloaded 102 time(s).
WroteThanks for clarifying, now I made some progress.
I still fail to specify systems of equations correctly. Any idea what is wrong?
I like the feature of the roots() function that you can specify an equation with RHS and LHS. As I understand the solvers in the plugin do not allow that type of specification. Ok, it is allowed but then the solution is any set of unknowns that render the equations unsatisfied (boolean equal giving 0).
Would that be difficult to implement (perhaps by internal transformation to standard form)?
I think the issue involving the massive solver it's something related with multiple convergence criterions; I need to investigate...
As a general rule, input bounds (or initial guess) have the same unit of unknown; so if you use a dimensionless unknown, you must input dimensionless bounds. What's the unknown, x or D? Basically D=f(x) it's a parametric variable, so the parameter (x) it's the unknown. Look the symbolic evaluation of your input function to check this (see the attachments).
The RHS/LHS function was in my goals from the beginning; working with DataExchange export features I've understand how to do it, will be implemented ASAP... Unfortunately, the code of the plugin is currently as a Dr. Frankenstein creature, so it will take some time to restore the order and then introduce new features.

WroteThe Bisection test file in the plugin docs is outdated (examples have the now removed iterations argument). I attached a corrected version.
Martin
Thank you very much :d
best regards,
w3b5urf3r
AS%207-7Bisection.sm (107 KiB) downloaded 96 time(s).
thanks again for the help. Now I can take advantage of the unit capabilities of your plugin at least for scalar equations. That already renders the solution of my example quite lean. No need for dimensionless variables any more.
Martin
I am again running into problems with equation solving. I never can exclude wrong operation but these seem like bugs.
Broyden and HRE.B do not handle zero starting values
Brent fails to solve a linear equation.
Martin
AS 3-26 solvers.sm (200 KiB) downloaded 102 time(s).
WroteHello w3bsurf3r,
I am again running into problems with equation solving. I never can exclude wrong operation but these seem like bugs.
Broyden and HRE.B do not handle zero starting values
Brent fails to solve a linear equation.
Martin
Hi Martin,
Yes, Broyden can't be solved with units if you use a null initial guess... In SMath Studio the 0 value have no units by default, I've already mentioned this behavior writing the first UoM() snippet function (I'm not sure if this is related to some SMath feature or it's a simple lack).
I can improve the function looking for units inside the 2nd error parameter (if any), but nothing more... As for now you can use a small number (f.e. 10^{-15}*'mm)
About Brent I see an "Units don't match" error, I need to investigate...
Thanks again for your testings
w3b5urf3r
Wrote
Yes, Broyden can't be solved with units if you use a null initial guess... In SMath Studio the 0 value have no units by default, I've already mentioned this behavior writing the first UoM() snippet function (I'm not sure if this is related to some SMath feature or it's a simple lack).
Hi w3bsurf3r
wondering why this problem obviously does not affect Newton Raphson, I came to the conclusion
The unit of measurement of the unknown can be obtained by dividing the unit of measurement of the function at x=0 by the gradient at that point. This works as long as
- the gradient wrt the unknowns can be generated symbolically
- the gradient is defined and nonzero at x=0
In fact, nothing else than dividing f by it's gradient is done by NR, such that the mentioned conditions should be more or less also the conditions for applicability of NR.
Martin
WroteHi w3bsurf3r
wondering why this problem obviously does not affect Newton Raphson, I came to the conclusion
The unit of measurement of the unknown can be obtained by dividing the unit of measurement of the function at x=0 by the gradient at that point. This works as long as
- the gradient wrt the unknowns can be generated symbolically
- the gradient is defined and nonzero at x=0
In fact, nothing else than dividing f by it's gradient is done by NR, such that the mentioned conditions should be more or less also the conditions for applicability of NR.
Martin
You're absolutely right!
However (IMHO) the native units support for zero values in SMath would be very appreciable

EDIT: previews
[albumimg]59[/albumimg][albumimg]58[/albumimg][ALBUMIMG]67[/ALBUMIMG]
[ALBUMIMG]68[/ALBUMIMG][ALBUMIMG]88[/ALBUMIMG][ALBUMIMG]111[/ALBUMIMG]
[ALBUMIMG]112[/ALBUMIMG]
Wrotecan't be solved with units if you use a null initial guess... In SMath Studio the 0 value have no units by default, I've already mentioned this behavior writing the first UoM() snippet function (I'm not sure if this is related to some SMath feature or it's a simple lack).
In general, 0 is more than just a real number or place holder representing, in this case, an empty set. When it comes to systems with units, 0 is actually a chameleon with universal units (in the same way that type O blood is for universal donor). It can be handled by either treating each 0 as a function that transforms the number unitless 0 into a 0 with units of its surrounding factors as appropriate for the calculation, or by changing the rules of the uses of units as programmed into smath so that units associated with 0 (whether present or not) are completely ignored and all unit determinations are made by use of units provided by all non-0 factors.
WroteIn general, 0 is more than just a real number or place holder representing, in this case, an empty set. When it comes to systems with units, 0 is actually a chameleon with universal units (in the same way that type O blood is for universal donor). It can be handled by either treating each 0 as a function that transforms the number unitless 0 into a 0 with units of its surrounding factors as appropriate for the calculation, or by changing the rules of the uses of units as programmed into smath so that units associated with 0 (whether present or not) are completely ignored and all unit determinations are made by use of units provided by all non-0 factors.
I agree with your logic

However I hope that in future the numeric optimization can preserve the units for zero values

Davide, I saw your recent previews and assume that there is a new version on the way, thus this post may be irrelevant. If not, I am ready to provide details on the problems.
WroteIs the plugin expected to work under 0.96? I get just errors in type conversion.
Davide, I saw your recent previews and assume that there is a new version on the way, thus this post may be irrelevant. If not, I am ready to provide details on the problems.
Yes, there's a new version on the way, but requires time

There are no irrelevant posts for me... could be that I have already solved the problem, as well as no; feel free to post any issue

In the handbook I have screenshots, where the Bisection function has no precision argument. That does not seem to work now. And I must admit that I didn't keep track with which version that image was generated.
WroteDon't know, where to start, perhaps first making sure I have the current version of the plugin. Can you confirm that 1.0.4657.20187 is current? I got it from the link in the wiki plugin page and re-installed it in the course of trouble-shooting today.
In the handbook I have screenshots, where the Bisection function has no precision argument. That does not seem to work now. And I must admit that I didn't keep track with which version that image was generated.
Ah, yes.... this is because the screenshot is made with the latest BETA version

Quote- solver Bisection(...) revisited (the number of iterations is no longer required, as reported by adiaz) (previous BETA - no changes);
best regards,
w3b5urf3r
WroteHowever (IMHO) the native units support for zero values in SMath would be very appreciable
![]()
I'm agree. Do you have an exact example (which requires no additional plug-ins) where I can see an issue?
Regards.
Wrote
Ah, yes.... this is because the screenshot is made with the latest BETA version
The issue was indeed in mixing plugin versions. Now everything is red-free and consistent with the handbook. 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...)
Martin
-
New Posts
-
No New Posts