Trying to find the roots of an equation of the form: x = a + e^(-x), but it has large values for the various constants and my results are inconsistent with what I find from other methods. Can someone give me some insight, please? I started by programming my own Newton-Raphson Method and got the 3.41491918157116*10^17 answer, so I started exploring other methods and got nowhere different. WolframAlpha results are 1.37638*10^19, as well as some other javascript-based Newton's Method calculators I found through Google.

EDIT: Well, clearly something must be wrong. Just occurred to me to check the result I got from WolframAlpha in SMath: f(1.37638*10^19)=-2.33471817396532*10^19. So I still have no idea if my equation even has a solution...
EDIT2: Playing around more, this must be a floating point resolution issue; this is the closest I can get to a zero:
f(3.41491918157117457999999999999999*10^17)=4860.33403506286
f(3.41491918157117458*10^17)=-6956.71907669237

Also, I can't seem to plot this function in SMath, either.

Thank you for any help someone can provide!

Ozone Solution.sm (14 КиБ) скачан 31 раз(а).

1. I get a solution from BDQRF [known very robust]
2. Also the plot of f(x) ... [size before plotting !!!]
Does it make sense ? Sorry: I hate unit before hand.
3. the all system is working [FindRoots agrees with BDQRF]

Jean

Ozone Solution jmG.sm (13 КиБ) скачан 53 раз(а).

Wrote

1. I get a solution from BDQRF [known very robust]
2. Also the plot of f(x) ... [size before plotting !!!]
Does it make sense ? Sorry: I hate unit before hand.
3. the all system is working [FindRoots agrees with BDQRF]

Jean

Ozone Solution jmG.sm (13 КиБ) скачан 53 раз(а).

Thank you; what are the parameters of BDQRF? Very confused with the documentation, and your use of (..., 0, 0.1). I thought those were for epsilon and maximum iterations?
EDIT: Answer is found here: https://smath.info/svn/public/plugins/NonlinearSolvers/Primitives/Root%20Finding%20Methods/BDQRF.cs
trySolve(Term[] function, Term[] bound_P1, Term[] bound_P2, Term[] epsilon_fx, Term[] epsilon_Δx, int maxIterations, bool showSummary, bool saveSummary, ref Store context)

Is there any way to improve the resolution, or am I just at the limits of the double-precision floating-point?
EDIT: Previous forum posts indicate otherwise.

Wrote

Thank you; what are the parameters of BDQRF? Very confused with the documentation, and your use of (..., 0, 0.1). I thought those were for epsilon and maximum iterations?
EDIT: Answer is found here: https://smath.info/svn/public/plugins/NonlinearSolvers/Primitives/Root%20Finding%20Methods/BDQRF.cs
trySolve(Term[] function, Term[] bound_P1, Term[] bound_P2, Term[] epsilon_fx, Term[] epsilon_Δx, int maxIterations, bool showSummary, bool saveSummary, ref Store context)

Better you look below for documentation; code entry point is accidentally close to the high-level function, but in general this is not guarantee

Activebook (Tools > Plugins... Interctive books - Online Gallery > Interactive SMath Handbook)




For plotting issues, I suggest to scale down the values (f.e. plot f(x)/10^19 or something similar)

Thank you; what are the parameters of BDQRF ? Very confused with the documentation, and your use of (..., 0, 0.1).
I thought those were for epsilon and maximum iterations ?

ANSWER: generally, solving is by trial/error, much simplified from a graph, especially if the graph runs in
the negative domain. If you have an answer, it should be accurate enough to restrict the upper limit just a
little bit above the first result. As well, if there is only one result, you restrict the lower limit a
little bit below. If you have no graph, and if you use the "solve" bloc, the error message "No real root"
simply means the upper limit is below the result. In that case, the solver can't "navigate" and fails.
Increase the upper limit.

Is there any way to improve the resolution, or am I just at the limits of the double-precision floating-point ?

ANSWER: accuracy depends upon the "crossing angle". The FindRoots interprets =0 as if it would be fnct(x):=0
The "solve" bloc will reject 0 ... you have to code f(x) =[equality] fnct(x). Any solver will range from rough
result to 15 decimals. It has nothing to do with 32/64 floating point, 32 bits floating accommodates > 15 D.

I'm not familiar with BDQRF ... it just happened it did well in your document.

Welcome studio 271. Cheers ... Jean

I appreciate the input, thank you. I saw the tooltips, but it was hard to parse what it was telling me to use as parameters.

I am not saying I NEED to have the extra floating-point precision; in fact, it wouldn't change my result enough to pursue this further. But to be petty... it would make a difference and allow a more precise result in my case. :d

SMath got me the results I needed, and I appreciate all the work you fine folks have put into this software!

Wrote

But to be petty... it would make a difference and allow a more precise result in my case.

64 bit floating will change nothing in your result, why ?
The solvers [whichever one Smath offers] compute function(s).
Most if not all functions are approximated from "Normalized" rational fractions.
Very many are built-in in small computers, Smath borrows them from hyper fast
machine code. Those built-in have 21 raw decimals. Numerical unstability make
them uncertain between 18 ... 21 [Cody Junior]. CAS systems consider 17 true
decimals and only 15 are displayed for results, to take into account combined
functions in formulae.
For higher accuracy, approximations are built from ChebyShev 25 decimals of
almost perfect numerical stability. Those Chebyshev run on "Big Blues"
[don't take my word here as Gospel], but take a bit more than 3 times to compute
because of the volume of arithmetic operations. On the other hand, your 15 decimals
sanity check with common 15 D reference Abramowitz & Stegun.

The solver "roots" is a much different one. Please, visit "Samples" few days ago,
"Iterate on canvas", download the work sheet "Mach"