Question

I took a break from the ps3d problem and started on the ps4 stuff while I got my head straight. All my functions seem to work right and give the right answers. Can anyone take a look at the code and offer any criticisms towards the style?

Here's the code;

http://codepad.org/eyh4hQHJ

Thanks,

-Ian I took a break from the ps3d problem and started on the ps4 stuff while I got my head straight. All my functions seem to work right and give the right answers. Can anyone take a look at the code and offer any criticisms towards the style?

Here's the code;

http://codepad.org/eyh4hQHJ

Thanks,

-Ian @MIT 6.00 Intro Co…

Answer 1

In nestEggFixed, it's clever how you append to the list using slicing. However, you could just use account.append(value) to append values. That's much clearer.

You could also pre-allocate account to be a list of the right length, then assign to each index. account = [0]*years

Answer 2

(My comment about list.append applies to the other functions, too.)

In nestEggVariable I'd probably say "for i in len(growthRates)" because you're using the index in multiple ways. I'd probably name iters "year". And "i" is not a good name for a growth rate.

So here are the choices

year = 0
for rate in growthRates:
# calculation using rate and year
year += 1

for i in len(growthRates):
rate = growthRates[i]
# don't have to maintain a separate loop variable anymore

In the second example I wouldn't be too fussy about indexing the account list with i. i is a traditional loop variable, so readers will know what it means. To be clearer you could name it "year".

This same comment applies to postRetirement.

Answer 3

I like your test code. It looks very familiar. ;)

As a general concept, testing floats for equality is a dangerous proposition. I know they give the exact float values generated by the straightforward implementations of the functions, but you can see that they're not exactly what a human would expect from doing the calculations by hand (or calculator).

I won't get in to how floats are stored; there are resources on the web that discuss that. Suffice to say, they're not exact. Therefore, when comparing floats it's safer to check that their absolute difference is smaller than some small value (like 10^-6, or some value that takes the relative sizes of the values into account). So something like math.abs(a-b) < 10**-6.

But the code for this is much more convoluted than the simple == comparison you're using. So I do not suggest you make that change. It's overkill for this problem set. Just be aware of the issue.

Answer 4

Yep, its like he mentioned in the lecture. I thought about that as I was writing the test code, but knowing the exact answers meant I could and get away with it. Taking the problem set one step further, is there a way to display these values as something that people would expect, i.e. for i in account; i = i with 2 digits of precision?

Thanks for the append tip, I figured there was a less verbose way to get there, but it worked none-the-less. Confusing to look at it though. I was also considering a way to preallocate the list but my solution was much less elegant than the simple method you used, so I skipped it.

Once again, thanks for the tips, I appreciate it.

Answer 5

If you want to print a float you can do that with a format string:
print "%1.2f" % (6.499995)
Should print 6.50.
The documentation for print should explain all the format strings. It's kind of like a mini-language by itself, so I'm not going to try to explain it all here.

You might also be able to round a value to a more user-friendly value. round() is a built-in function that rounds a float to a specified number of decimal places. That will work if there is a float value close to or equal to the desired value. 0.1 is the quintessential example of a value that doesn't have an exact binary float representation. If you add 0.1 to itself 10 times (don't just multiply by 10) you'll end up just shy of 1. But if you round the result it'll be == to 1 (even if you round it to 15 decimal places).

Floats seem like they can take on any real value, but they can actually only represent certain *discrete* values. When you tell python you want a certain float value, it will find the one closest to the value you want. It might be the exact value you want. So if you do a test like "0.1 == 0.1" that will be reliably True, even though neither value is what you or I think of when we think of 0.1.

I guess what I'm getting at is that if the values in account are the closest floats to the real values, then you'll just get those values back. If they're slightly off because of accumulated calculation error, and a better float approximation exists, then rounding will get you the best float available. So, use round().