Why does my code output answers in log?
20 views (last 30 days)
Show older comments
Kevin Juan
on 11 Sep 2020
Commented: Kevin Juan
on 12 Sep 2020
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)))])
2 Comments
KSSV
on 11 Sep 2020
You are solving for n..n occurs in the power...so obviously you will get log right? Read the log definiton.
Accepted Answer
Asad (Mehrzad) Khoddam
on 11 Sep 2020
Use
double(solve([1000000==300*((((1+0.08/12)^(n+1)/(0.08/12)-1)))]))
to solve this financial problem (interest rate)
0 Comments
More Answers (1)
KSSV
on 11 Sep 2020
Remember:
10 Comments
Walter Roberson
on 11 Sep 2020
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.
See Also
Categories
Find more on Numbers and Precision in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!