# Why does Mathematica struggle with solving this equation?

Consider the evaluation of the following expression

In[20]:= Reduce[ 1000 * 1.0609^t == 1500, t]

During evaluation of In[20]:= Reduce::ratnz: Reduce was unable to
solve the system with inexact coefficients. The answer was obtained by
solving a corresponding exact system and numericizing the result. >>

Out[20]= C[1] ∈ Integers &&
t == -16.9154 (-0.405465 + (0. + 6.28319 I) C[1])


I was expecting just 6.858618708478822 as the solution.

-
Try Reduce[1000*1.0609^t == 1500, t, Reals]. You still get an error - which you get with NSolve as well, but you get the right result. FindRoot is better with numerical results if you kinda know where to search (the case here). – gpap Feb 7 '13 at 14:30
Yes, you get the result but the error looks scary. I don't understand why 'Reduce was unable to solve the system with inexact coefficients' Does anyone have any insight – WalkingRandomly Feb 7 '13 at 14:33
I think Reduce is close to giving you the correct answer because -16.9154*-0.405465=6.85862, but for some reason it can't get rid of the complex value (0+2PiI). I would report this to Wolfram as a bug. – Cassini Feb 7 '13 at 14:33
Difficult to say exactly what the difficulty was, but in Mathematica's numerical model, machine-precision numbers are considered not to be exact quantities. This makes it difficult to decide if two values are equal, or whether something is exactly zero or not if machine numbers are involved. The solution it finds for this problem is to convert the machine-precision values into rationals, which are treated as exact. Strictly speaking, machine precision numbers are rationals, so you can do this yourself if you wish using SetPrecision[..., Infinity], which will avoid the message. – Oleksandr R. Feb 7 '13 at 14:49
@DavidSkulsky the rounding is not perfect but Reduce is giving an answer that is very close to t == -(((2*I)*Pi*C[1] - Log[3/2])/(-52*Log[2] + Log[4777868844677359])), which seems to produce exactly 1500 when substituted into the original equation for C[1] any integer. Can we remove the [bugs] tag? – Oleksandr R. Feb 7 '13 at 15:19

Using Solve I get the exact same result as you noted in the last sentence.

Solve[1000*(1.0609^t) == 1500, t]

-
Yes but when you do that, Mathematica says "Solve::ifun: Inverse functions are being used by Solve, so some solutions may not be found; use Reduce for complete solution information. >>" – WalkingRandomly Feb 7 '13 at 14:31

As a workaround, you could always solve the equation symbolically, then replace the symbols with your constants:

Reduce[a*b^t == c, t] /. {a -> 1000, b -> 1.0609, c -> 1500}


Result:

C[1] ∈ Integers && t == 16.9154 (2 I π C[1] + Log[3/2])


And Simplify[%] returns:

C[1] ∈ Integers && t == 6.85862 + (0. + 106.283 I) C[1]

-
This seems to be what the message is telling you MMA is doing. If the problem was the message, Quiet seems a simpler way to achieve the same – Rojolalalalalalalalalalalalala Feb 7 '13 at 21:24
@Rojo this is not really the same thing. I personally prefer nikie's approach: consider for instance arbitrary precision numbers for which you also care about their uncertainty. The answers you get by letting Reduce handle things by itself are rather different to those obtained by substituting into the exact solution. – Oleksandr R. Feb 7 '13 at 23:05

If you re-express your problem in terms of reals:

Reduce[1000. 1.0609^t == 1500., t, Reals]


you will get

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

t == 6.85862

Mathematica is not "struggling" with your equation. The message is simply FYI -- to tell you that, for this equation, it prefers to work with exact quantities rather than inexact quantities (reals). If you find the message annoying, you can turn it off:

Quiet@Reduce[1000. 1.0609^t == 1500., t, Reals]


t == 6.85862

-
I would be wary of dismissing the message so easily. It is not produced with, for example, Reduce[{9.2 x + 3.1 y == 4.7, 2.8 x - 7.1 y == 6.0}, {x, y}]. As I mentioned in my comment above, I believe it indicates that difficulties were encountered in deciding conclusively whether two quantities were equal given the presence of inexact numbers. The fact that Reduce had to resort to solving a related problem, rather than the one actually posed to it, is presumably not something that one would usually wish to disregard. – Oleksandr R. Feb 7 '13 at 22:51
@OleksandrR. I did intend to suggest the message should be ignored, but I thought that the OP ought to be made aware that it could be suppressed. – m_goldberg Feb 8 '13 at 2:46
I know that you can suppress messages. The message does not say Reduce prefers to work with exact quantities, it says unable. This implies, to me at least, that there is an issue or, put another way, that Mathematica has struggled. – WalkingRandomly Feb 8 '13 at 10:30
I was sufficiently interested to blog about this. walkingrandomly.com/?p=4813 if anyone is interested. – WalkingRandomly Feb 8 '13 at 16:43
@WalkingRandomly In your blog you seem that suggest that the double precision's inability to express 1.0609 exactly causes the problem... But solving 1.75^t = 1.5 in Mathematica still yields the warning message, while both 1.75 and 1.5 can be expressed exactly in double precision. – user58955 Dec 7 '14 at 4:55
N@Reduce[Rationalize[1000 1.0609^t == 1500, 0], t, Reals]


Result (with no errors/warnings thrown):

t == 6.85862


Rationalize[#, 0] will generate a rational version of all numbers in an expression within machine precision. Note that if you remove the N@ you can see the analytical solution:

t == (Log[2] - Log[3])/(2 (2 Log[2] + 2 Log[5] - Log[103]))


For fun, I added a bunch of random numbers to the expression, and Mathematica handles it like a champ:

Reduce[Rationalize[1000 1.0609916516846514894109^t == 1500, 0], t, Reals]

t == (Log[2] - Log[3])/
(4 Log[2] + 2 Log[3] + Log[11] + Log[127] +
Log[173] + Log[1861] - Log[68716865519])

-