## ultrapuggy 2 years ago Hi, The solution to #2 for Problem set # 1 seems incomplete. I could be wrong, but it doesn't test for if the monthly payment needs to be reduced. Also I'm getting vastly different numbers from the answer key using the test case. I tested it in Excel and my program matches that though. Can anyone look at my code? Thanks a lot.

1. ultrapuggy

It's the uncommented portion of the attached file. I know I should clean my code up a bit, seems a bit redundant...but the logic is: I'm checking for the initial guess being larger vs smaller (bisection guessing). If it is too small, I go to the first chunk of code. If it is too large I go to the second. Note, I did make sure to add interest PRIOR to any deductions as the professor specified. Excel checks out as well. I will attach.

2. ultrapuggy

Attached Excel with the 1200 Balance, .18 example

3. ultrapuggy

I also noticed he didn't make it pay in increments of 10 in his attached answer sheet, or check for a payment that is too large.

4. ultrapuggy

Attached problem set for ease of use.

5. deerbane

I'm not on that problem yet. I am having problems with a syntax error in the second one. Let me get there and then I will be able to give you a more informed guess.

6. medicrobosn

Were you able to get the first portion of code to work properly before diving into the bisection search? I am getting ready to transform my working code into the faster bisection method today.

7. Hellvince

In fact, you dont use bisection search in your answer. You use upper and lower bound to make an educated guess at the beginning "MinPay = round((High + Low)/2.0, -1)" but after that you keep adding or substracting 10\$ if the initial guess is too high/too low. Using bisection search means you make a guess using predetermined bounds, and you modify these upper/lower bound once you calculated the balance with the guess. If the guess is too high ( = balance is negative), you set the upper bound to be the current actual guess. Vice versa if the current guess is too low ( = balance is still positive) it becomes the lower bound. Then, the next time your loop is executed, the guess should be based on these new upper/lower bounds. It will allow you to progressively pinpoint a reliable guess. Now you just have to deal with guess precision : when do you think the guess is precise enough to be kept.

8. bwCA

strategically placed print statements are a great way to 'debug' your code. http://dpaste.com/1324113/ the while loops that run thru 12 months of payments - you probably shouldn't round at each iteration. you could greatly simplify your code: if you just start with a minpay of \$10 then you won't have to worry about decreasing it - this change would get rid of almost half your code and possibly make it easier to read and debug. your solution is definitely not working