If one wants to solve the system over the reals, then NSolve
solves it without trouble, ignoring the warning message.
op = {7.34*10^-10 == (167 (1 + 1.38/x)^-y)/200000000000,
4.1*10^-10 == (167 (1 + 6.7/x)^-y)/200000000000};
sol = NSolve[op, {x, y}, Reals]
NSolve::ratnz: NSolve was unable to solve the system with inexact coefficients. The answer was obtained by solving a corresponding exact system and numericizing the result. >>
(* {{x -> -24.3072, y -> -2.20574}} *)
op /. sol
(* {{True, True}} *)
Solve
works, too. If you Rationalize
the system, you get exact solutions, but probably that is irrelevant, since the coefficients are inexact.
I expect other solutions over the complexes, if they exist, will be difficult to obtain.
Update: The numerics behind the warning message
Note that the message is not an error but just a warning. Researchers who haven't had a course in or otherwise studied numerics sometimes do not appreciate its importance. The message is not considered an error per se, because the uncertainty in the inexact coefficients, which translates to uncertainty in the solution, does not automatically mean the solution is useless. The warning is there notify the researcher of the issue, and it is up to the researcher to determine whether the issue is significant.
We can use the OP's equations as an example. Let us suppose that the non-integer coefficients are known to the digits presented and that the error of measurement is at most one-half in next digit. Here is a function that will convert them to the appropriate Accuracy
:
setAccuracyToDigits[x_Real] :=
With[{me = MantissaExponent@x},
SetAccuracy[x, StringLength@ToString[First@me] - Last@me - 2 - Log10[0.5]]]
Example:
setAccuracyToDigits[7.34*10^-10]
Through[{Accuracy, Precision}[%]]
(*
7.34*10^-10
{12.301, 3.16673}
*)
We can convert the OP's equation to one representing its presumed accuracy as follows:
opacc = op /. x_Real :> setAccuracyToDigits[x];
opacc /. x_Real :> FullForm[x] (* for viewing *)

Below are a couple of solutions using FindRoot
. The roots differ by what seems quite a lot, but each satisfies the system opacc
-- that is, the differences of the two sides of the equations are less than the error indicated by the precision/accuracy of the equations and roots.
s1 = FindRoot[opacc, {x, -100}, {y, -4}, WorkingPrecision -> Precision[opacc]]
opacc /. %
(*
{x -> -25., y -> -2.2}
{True, True}
*)
s2 = FindRoot[opacc, {x, -23}, {y, -2}, WorkingPrecision -> Precision[opacc]]
opacc /. %
(*
{x -> -29., y -> -2.6}
{True, True}
*)
We can estimate the uncertainty in a solution {x, y}
using calculus. First we replace the inexact coefficients by paramters C[i]
to get a general system gen
. Then thinking of the general system in terms of the roots of a function ${\bf F}({\bf X}, {\bf C})$, where $\bf X$ represents (x, y}
and $\bf C$ the vector of inexact coefficients, we can solve the system
$${\partial \bf F \over \partial \bf X} \cdot \text{uncertainty}({\bf X})
= {\partial \bf F \over \partial \bf C} \cdot \text{uncertainty}({\bf C})\,.$$
We represent the uncertainty dC
in $\bf C$ with Interval
.
Module[{cnt = 0},
gen = op /. Equal -> Subtract /. x_Real :> C[++cnt]]
jacC = D[gen, {Cases[gen, _C, Infinity]}] /. First@sol;
jacX = D[gen, {{x, y}}] /. First@sol;
csub = Thread[Cases[gen, _C, Infinity] -> Cases[op, _Real, Infinity]];
dC = Interval[{-1, 1} #] & /@ Cases[opacc, x_Real :> 10^-Accuracy[x], Infinity];
errX = LinearSolve[jacX /. csub, (jacC /. csub).dC]
(*
{C[1] - (167 (1 + C[2]/x)^-y)/200000000000, - general system
C[3] - (167 (1 + C[4]/x)^-y)/200000000000}
{Interval[{-5.65675, 5.65675}], Interval[{-0.548501, 0.548501}]} - dX = {dx, dy}
*)
What we see is that the differences between the two solutions and the NSolve
solution are well within the maximum error estimate errX
:
{x, y} /. {s1, s2, First[sol], s1} // Differences
(* {{-4., -0.4}, {4.4155, 0.39097}, {-0.444272, -0.0157774}} *)
But the important thing to observe is that if the two two-digit coefficients are really only known to two digits, then the solution is not known very precisely -- with up to almost 25% error! Surely an error that large must be taken into account.
Rationalize
on your equations to circumvent that immediate error, but then you will find thatSolve
is unable to solve your equation anyway. I think you should look into numerical solutions, e.g. usingFindRoot
. $\endgroup$ – MarcoB Oct 24 '15 at 19:57