At vero eos et accusamus et iusto odio dignissimos ducimus qui blanditiis praesentium voluptatum deleniti atque corrupti quos dolores et quas molestias excepturi sint occaecati cupiditate non provident, similique sunt in culpa qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio cumque nihil impedit quo minus id quod maxime placeat facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.
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.
you could also consider using the "round" function: round(3.14159, 2) #rounds to 2 decimal places >>>3.14
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
Here is a link to DECIMAL for those interested http://docs.python.org/2/library/decimal.html
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 - )
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
I actually wouldn't even worry about the discrepancy of a few cents due to the lack of exactitude of floating point numbers.
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
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
the floats are very good - 10 decimals - you are certainly getting it right to at least 8 decimals (computers are good).
Try right-click->edit with IDLE to open the file
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.
very few, actually. what, 1 multiply or 2 per step? it really won't effect the second decimal.
'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...
Sorry, got it. my downloaded files were not extracted...
thanks for all the answers