I'm a beginner in Mathematica. I'm trying to solve :

  7.34*10^-10 == (167 (1 + 1.38/Subscript[V, BI])^-M)/200000000000
    4.1*10^-10 == (167 (1 + 6.7/Subscript[V, BI])^-M)/200000000000
    Solve[{eq21, eq22}, {Subscript[V, BI], M}]

I received the following message:

Solve::inex: Solve was unable to solve the system with inexact coefficients or the system obtained by direct rationalization of inexact numbers present in the system. Since many of the methods used by Solve require exact input, providing Solve with an exact version of the system may help. >>

Solve[{7.34*10^-10 == (167 (1 + 1.38/Subscript[V, BI])^-M)/
  4.1*10^-10 == (167 (1 + 6.7/Subscript[V, BI])^-M)/
   200000000000}, {Subscript[V, BI], M}]

Is my system solvable or do I use correctly Mathematica? In this case, do you have ideas for solving my system?

Thank you for your help!

  • $\begingroup$ You can use Rationalize on your equations to circumvent that immediate error, but then you will find that Solve is unable to solve your equation anyway. I think you should look into numerical solutions, e.g. using FindRoot. $\endgroup$ – MarcoB Oct 24 '15 at 19:57
  • $\begingroup$ Try writing your in exact number as rationals, I.e., 7.34 as 734/100. $\endgroup$ – Sjoerd C. de Vries Oct 24 '15 at 19:58


I got rid of the subscript (perhaps not needed but I try to avoid them) and switched to lower case symbols (a general good practice).

eq1 = 7.34*10^-10 == (167 (1 + 1.38/vBI)^-m)/200000000000
eq2 = 41/10 == (167 (1 + (67/10)/vBI)^-m)/20

Your code will work if you set the domain of the answers to Real.

sol = Solve[{eq1, eq2}, {vBI, m}, Reals]

Solve::ratnz: Solve was unable to solve the system with inexact coefficients. The answer was obtained by solving a corresponding exact system and numericizing the result. >>

(* {{vBI -> -24.3072, m -> -2.20574}} *)

If you run into more difficult problems I suggest trying Reduce. It tends to be a bit more robust than Solve.

| improve this answer | |
  • $\begingroup$ I believe there is a factor of 10 difference between the OP and your equations. In particular, using f[a_,x_,y_]:=167 (1+a/x)^-y and multiplying 200000000000 (2 $\times 10^{11}$) to both sides of original equations yields LHS values 146.8 and 82 respectively. In your case you yield 14.68 and 8.2. For your case, NSolve[{f[1.38, x, y] == 14.68, f[6.7, x, y] == 8.2}, {x, y}, Reals] yields {{x -> 0.00189391, y -> 0.368826}}, and similarly for FindRoot. Using 146.8 and 82 yields MichaelE2's answer. $\endgroup$ – ubpdqn Oct 25 '15 at 4:01
  • $\begingroup$ @ubpdqn Thank you for catching this (it's a full time job keeping me honest). When I reviewed the answer I discovered that the only change required was to set the domain of the variables to Reals. $\endgroup$ – Jack LaVigne Oct 25 '15 at 13:35
  • $\begingroup$ we all make mistakes. A colleague remarked to me a long time ago if we haven't made half a dozen, usually trivial, mistakes by lunch time we haven't worked hard enough or we've lost insight...this site has always struck me as people playing and helping...the former joyous and the latter noble...with rarer darker aspects :) $\endgroup$ – ubpdqn Oct 25 '15 at 13:41

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]]]


Through[{Accuracy, Precision}[%]]
  {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 *)

Mathematica graphics

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.

| improve this answer | |
  • $\begingroup$ FYI see my comment on Jack LaVigne's answer. I got same result as you and believe that there is (minor) factor of 10 "error" in Jacks's problem specification which occurred with desire to make more tractable. You kept the equations unchanged. $\endgroup$ – ubpdqn Oct 25 '15 at 4:03
  • $\begingroup$ @ubpdqn Thanks. I noticed the discrepancy, but I got confused about which was correct. Then I found a simpler approach, which had to be right, and I posted. I thought I'd come back and check Jack's answer again after I got some sleep. :) $\endgroup$ – Michael E2 Oct 25 '15 at 14:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.