test.assert_equals(amort(5.6, 133555, 60, 53), "num_payment 53 c 2557 princ 2464 int 93 balance 17571")

I kept failing this due to rounding - my int was 94

very similar to what I did

this is what I did as well!

other than spacing, this is what I did!

I didn't put a # sign, I just left it blank...

My solution as well...

Other than putting tail on the left of the ==, this is what I did!

Other than using d for digit instead of c, this is what I did!!!

No - there is no cost overhead for calling len twice... technically, there is more overhead for storing a new variable in memory to hold a value that is already in memory...

I had actually asked about this on the learn python reddit a couple months ago... and I was informed that part of the arr variable is its length - its already stored in memory as part of the list, so when you call len(list), its just accessing that variable...

And while it's negligible, the new variable that you create (l) is actually simply duplicating a value already stored in memroy...

that was my TIL that day!!!

+1 Clever!!!

I did almost the same thing... I used a list to hold the fib #s... but looking at yours, I realized that you don't need the list to store the past numbers in the sequence!

i did this as well (using sum of consecutive integers)! Only I didn't use max(arr) as the length of arr was already one of the #s needed in the calculation!

i did this as well (using sum of consecutive integers)! Only I didn't use the l variable, as len(arr) is already 'attached' to the arr variable, so its the same as looking up l...

i did this as well (using sum of consecutive integers)! Only I didn't use the l variable, as len(arr) is already 'attached' to the arr variable, so its the same as looking up l...