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.
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.
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.
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.
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.
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.
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