0

When I input .41 in outputs 4 but when I input lets say 23, it gives me a crazy number, and glitches out

Code:

/**
* greedy.c
*
* My name
* My email address
*
* Give the least number of coins needed to pay
*/

#include <stdio.h>
#include <cs50.h>
#include <math.h> 
#include <ctype.h> 

int main(void)
{
float b;
do 
        // prompts the user for an input
        {
        printf("Hello, how much change is owed?: ");
        b = GetFloat();
        }
    while(b<0);

    int q = 25;
    int d = 10;
    int n = 5;
    int p = 1;
    int x; 
    int count = 0;

    int balance = round(b*100);
    printf("%i\n", balance);
   // substracts quarters from balance 
   do
   {
    x = balance/q;
    count = count + x;
    balance = balance - (q*x);  
   }
   while(b >= q);

   // substracts dimes from balance 
   do
   {
   x = balance/d;
   count = count + x;
   balance = balance - (d*x);
   }
   while (b >= d);

   // substracts nickles from balance 
   do
   {
   x = balance/n;
   count = count + x;
   balance = balance - (n*x);
   }
   while (b >= n);

   // substracts pennies from balance 
   do
   { 
   x = balance/p;
   count = count + x;
   balance = balance - (p*x);
   }
   while (b >= p);

   //prints out outcome
   {
    printf("The least number of coins needed is: %i\n" , count);
    printf("The bal after coins paid is: %i\n", balance);
   }  
}
0

You probably should be using "while" logic rather than "do... while" logic. Otherwise I speak from personal experience when I say strange things will happen. However, your bigger problem is that you should be running your logic based on the question, "is the remaining balance a higher monetary value than this coin denomination's monetary value?" You are basing your logic on the question, "is the total number of dollars I was originally given a bigger number than the cent value of this coin denomination?" Note that the relation between the second set of options is static--at no point will a quarter be worth more or less than 25 cents, and at no time will a historic event (say my receiving $20 which I need to make change for) change. They are matters of tautology, and as far as the computer understands 25 somethings is more somethings than 20 somethings. It has no way of assessing somethings unless you give it specific good methods for relative valuation. You have to be very careful to always compare apples to apples.

You can make "do... while" logic work. I did in under 40 lines for my solution, which works for everything I've tried (about 180 random floats between .01 and 10,000) but you have to be very careful, and rely on a specific quality of c int division to prevent over-payment. Specifically that when you divide two integers, c throws out the decimal place by default (so if a value is < 1, but >0, c will return a value of 0). Just understand that you are actually using more cpu cycles than you would otherwise need.

| improve this answer | |
0

The problem lies is the do....while loop. Taking your test case 23 as input, let's see how your program behaves. First, the integers q,d,n,p are initialized to 25,10,5,1 respectively. After printing the 'balance' we enter your first while loop. Now, the value of 'b' is 23 and that of 'q' is 25. The condition states that keep running the loop until 'b >= q', which in our case can be written as '23 >= 25'. Clearly the condition is not satisfied and the loop terminates after just one cycle.

Now, we're onto your second loop which says keep running till 'b >=d'. The value of 'b' hasn't changed, so let's see what happens in our case. The condition 'b>=d' can be written as '23 >= 10' which is true. Since you haven't written something that decrements the value of 'b', you've just created an infinite loop.

My suggestion to solve this glitch would be to get rid of all the do...while loops.

| improve this answer | |

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .