Why does my code output answers in log?

I am trying to solve the linear equation listed below. The output is mathematically correct, however it is written in log form which wastes time since I have to recalculate again. Is there any option to ensure that outputs are in decimal notation? Or is this a mistake in the code?

syms n
solve([1000000==300*((((1+0.08/12)^(n+1)/(0.08/12)-1)))])

[KSSV]

You are solving for n..n occurs in the power...so obviously you will get log right? Read the log definiton.

[Kevin Juan]

The said problem is actually from the book "A Guide to MATLAB for Beginners and Experienced Users", where the code used is

solve(1000000 = 300*((((1 + (0.08/12))^(n + 1) - 1)/(0.08/12)) - 1)')

Slightly different than mine since the book is quite outdated, however the code from the book displays a decimal output. Why is that?

Answer 1

[Asad (Mehrzad) Khoddam]

Use

double(solve([1000000==300*((((1+0.08/12)^(n+1)/(0.08/12)-1)))]))

to solve this financial problem (interest rate)

Answer 2

[KSSV]

Remember:

[Asad (Mehrzad) Khoddam]

The solution is symbolic and contains log function. Using double function, we can show the deimal value of the solution

[KSSV]

Yes..you are right..... double/ vpasolve can be used. I was wondering is op worried why log has come into picture.

[Kevin Juan]

So the solution is symbolic since the variables are also symbolic? If that is the case, should I remove the syms variables and make it so that n is not symbolic?

[Walter Roberson]

In order to make it so that n is not symbolic, you will need to create an anonymous function that accepts n, and you would fzero on that function. Something like

fzero(@(n) 300*((((1+0.08/12)^(n+1)/(0.08/12)-1))) - 1000000, rand)

[Kevin Juan]

can't we just do this?

solve(['1000000==300*((((1+0.08/12)^(n+1)/(0.08/12)-1)))','n'])

[KSSV]

No you cannot solve like that.

[Kevin Juan]

I see. Do you mind providing me with a simple example? Let's say I want to solve for

x^2-2*x=4

I've been searching all over for the correct format but the examples are way too technical for me. My current reference book "A guide to MATLAB for beginners" has a lot of solve examples like

solve('xˆ2 - 2*x - 8 = 0')

but I don't think they work now as the book is outdated.

[KSSV]

syms x
eqn = x^2-2*x-4==0
s = solve(e)

OR

p = roots([1 -2 -4])

[Walter Roberson]

Passing in a character vector directly to solve() used to be permitted, but has not been permitted for the last few releases. Now it is recommended that you construct the equation symbolically first, like

syms n
solve(1000000==300*((((1+0.08/12)^(n+1)/(0.08/12)-1))), n)

If you do this, you will get the log() form.

You can also use str2sym:

solve(str2sym('1000000==300*((((1+0.08/12)^(n+1)/(0.08/12)-1)))'),str2sym('n'))

This will give a numeric form directly for this particular set of values (but with other coefficients might give the log form.)

But notice that you have floating point values, 0.08, in your equation. Remember that in science, when you write 0.08 then you are designating some number, exact value unknown, that is between 75/1000 (inclusive) and 85/1000 (exclusive). Since the exact value being designated by 0.08 is unknown, it does not make sense to use solve(), since solve() is for calculating closed form indefinitely precise solutions whenever practical, and it does not make sense to expect indefinitely precise solutions when the inputs are not indefinitely precise.

You might at first think that "obviously" 0.08 is 8/100 exactly, but:

>> fprintf('%.999g\n', 0.08)
0.08000000000000000166533453693773481063544750213623046875

Binary double precision cannot exactly represent 1/10, for the same mathematical reason that 0.3333333333333333 is not exactly 1/3 . Will the symbolic processing happen to convert the 0.08 to exactly 8/100, including when you have the 0.08/12 ? Maybe, maybe not... in some contexts it will, in some contexts it will not. It is a category mistake to use solve() with equations that have floating point constants.

What should you do then? This:

syms n
vpasolve(1000000==300*((((1+0.08/12)^(n+1)/(0.08/12)-1))), n)

vpasolve() looks for approximate solutions, not for exact solutions. In some cases involving functions with very steep gradients, vpasolve() can lead to incorrect solutions. vpasolve() can also lead to incorrect solutions for functions that approach 0 without reaching 0, with vpasolve() telling you there is a solution in a region where no solution actually exists. So vpasolve() is not intended for perfect solutions... but if you wanted perfect solutions then you should not be using floating point.

[Kevin Juan]

All right. Thanks a lot for the info! The book did not elaborate capabilities and limitations on functions very well, so your input is very useful.