Question

PS1, rounding problem. (with code)

I had a rounding problem for the values in PS1, so I searched and found about the DECIMAL module and it's quantize function.

I then rewrote my code to get the same results as in the solution, but there still is a difference. Is DECIMAL the way to go?

my code is here:
http://pastebin.com/ghg0vrDr

thanks

Answer 1

rounding error wasn't likely the problem - there isn't enough computation for even 3-decimal accuracy to blow it off. It actually seems fine without the decimal import:
balance: 100000.00
credit rate: .15
min pay .12
after 12 months, the balance due = 33326.866 which seems reasonable, and looked
fine each step of the way. What data have you run it on? I've worked the problem set
but can't locate it now.

Answer 2

you could also consider using the "round" function:
round(3.14159, 2) #rounds to 2 decimal places
>>>3.14

Answer 3

I had tried the 'round' function and it also gave a difference, this is why I searched for another option. Decimal seemed to address this exact problem.

Here is a link to PS1, where you can compare the values.
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00sc-introduction-to-computer-science-and-programming-spring-2011/unit-1/lecture-4-machine-interpretation-of-a-program/MIT6_00SCS11_ps1.pdf

Here is a list of where it goes wrong, the differences are the same either with round or with Decimal. (myValue vs officialValue) :
month 6 - principal paid : 15.74 vs 15.73
month 7 - principal paid : 15.68 vs 15.69 (also here, cents are missing)
month 10 - remain. balance : 4642.38 vs 4642.37
month 11 - principal paid : 15.47 vs 15.48
month 11 - remain. balance : 4626.9_ vs 4626.89
month 12 -principal paid : 15.42 vs 15.43
month 12 - remain. balance : 4611.48 vs 4611.46
Results - remain. balance : 4611.48 vs 4611.46
Results - total amount paid : 1131.11 vs 1131.12


the code for the 'round' option can be found here : http://pastebin.com/WbcHU0mZ
the code for the 'Decimal' option can be found here : http://pastebin.com/rMUJWe4Q

Am I being too picky? These differences would add up on the long term, so something is wrong, but what?


thanks

Answer 4

Here is a link to DECIMAL for those interested

http://docs.python.org/2/library/decimal.html

Answer 5

oddly enough, i'd trust the accuracy of your result over the one given -
float is accurate to (it looks like) 10 decimals - x.xxxxxxxxxx
a few multiplies and divides won't effect the second decimal place.
their answer for month 2 is 4950.13 - you get 4950.125. yours is actually more
accurate - you can check it by hand. (thanks for linking to problem set - )

Answer 6

I forgot to say, I use the initial values of the problem

Outstanding balance on your credit card: 4800
Annual credit card interest rate as a decimal: 0.2
Minimum monthly payment rate as a decimal: 0.02

This brings Snark's values in question 'their answer for month 2 is 4950.13 - you get 4950.125.

I tried with $5000 -0,2%-0,02% and I get 4950.17 for month 3... (I guess these are the values snark used)

is it possible that the result could vary depending on the computer used???

thanks

Answer 7

I actually wouldn't even worry about the discrepancy of a few cents due to the lack of exactitude of floating point numbers.

Answer 8

i used 5000.00, .18, and .02 : maybe i misscopied the problem?
i think what they are doing is saying 11.041 is over 11.04 and so,
thinking like a banker, they will call it 11.05

Answer 9

Ok, but then, what data type would be used to get truly accurate values?

Also btw, I tried comparing my code with the solution they post on the page here : http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00sc-introduction-to-computer-science-and-programming-spring-2011/unit-1/lecture-4-machine-interpretation-of-a-program/

but all I get is a prompt window (black DOS box) to run the program. How can I see the code from there?

thanks again

Answer 10

the floats are very good - 10 decimals - you are certainly getting it right to at least 8
decimals (computers are good).

Answer 11

Try
right-click->edit with IDLE
to open the file

Answer 12

And yeah, floating point numbers are good up to 8 digits, but this calculation involves many floating point numbers in its course, which can lead to an error in the 2nd decimal place.

Answer 13

very few, actually. what, 1 multiply or 2 per step? it really won't effect the second decimal.

Answer 14

'Try right-click->edit with IDLE to open the file'

tried this on the page
tried this on the download link
tried this in the prompt window
tried this on the downloaded file
tried this in a new page in IDLE
tried this in the program in IDLE

I'm never offered the 'edit with IDLE' option...

I'm a little bit of a beginner at this, it seems obvious, but...

Answer 15

Sorry, got it.

my downloaded files were not extracted...

Answer 16

thanks for all the answers