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 (15kb) downloaded 15 time(s).

Edited by user 06 June 2017 20:23:10(UTC)  | Reason: added additional information

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.

Edited by user 06 June 2017 20:22:39(UTC)  | Reason: Not specified

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

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"