posted 2 years ago

- 1

I need to create a program that converts a given amount of money to change. Here is the program that I came up with:

What I want to know is, is this the best implementation of such a program (for a beginner that is)? Given the limitations of floating-point arithmetic, is this the best way to handle converting a given sum of money to its equivalent change?

What I want to know is, is this the best implementation of such a program (for a beginner that is)? Given the limitations of floating-point arithmetic, is this the best way to handle converting a given sum of money to its equivalent change?

posted 2 years ago

No.

No. And

Tip 1: Use

An alternative is to use

Tip 2: If you need to

Tip 3: Don't include divisions in your "denomination" variables. Just keep them as constants in pennies.

Tip 4: You shouldn't need any division. This is basically a

HIH

Winston

- 1

Miles Davis wrote:What I want to know is, is this the best implementation of such a program (for a beginner that is)?

No.

Given the limitations of floating-point arithmetic, is this the best way to handle converting a given sum of money to its equivalent change?

No. And

*well done*for working out that FP is likely to cause problems (you'd be surprised how many beginners don't). +1.

Tip 1: Use

*pennies*internally for ALL your denominations, since it's the smallest unit you deal with. That allows you to keep everything as integers.

An alternative is to use

`BigDecimal`, but the class is quite clumsy and may distract you from your basic problem.

Tip 2: If you need to

*accept*a number like "49.99" as input,

__convert__it to pennies

*immediately*.

Tip 3: Don't include divisions in your "denomination" variables. Just keep them as constants in pennies.

Tip 4: You shouldn't need any division. This is basically a

*subtraction*exercise.

HIH

Winston

"Leadership is nature's way of removing morons from the productive flow" - Dogbert

Articles by Winston can be found here

posted 2 years ago

If you know how to use loops and arrays you might also want to look at how you can write a solution which stores the denomination values and names in parallel arrays and iterates over the arrays calculating how many of each denomination is required to make up the total amount. Once you've done this with parallel arrays see if you can get rid of the parallel arrays eg use a single array of Denomination objects.

posted 2 years ago

Don't like parallel arrays; they are non‑object‑oriented programming and potentially error‑prone. It is much more object‑oriented to create a Coin enumerated type and iterate it.

Hint: if you put the large denominations first, you can simply iterate the values() array in order.

Hint: if you put the large denominations first, you can simply iterate the values() array in order.

posted 2 years ago

Like Winston says, it's not the "best", but in my opinion it's not a bad first try. At least you converted everything to integers right at the beginning, and keeping the dollars and the cents in separate variables isn't a bad idea. Although your names for those variables aren't the most obvious names.

I had to look at all those % calculations for quite a while before I realized they worked, but I guess they do work. Kind of neat in one way. However there's a programming principle called "DRY" which stands for "Don't Repeat Yourself" and your code definitely repeats itself. The others have already alluded to other ways to solve the problem, but it's helpful to think about how the process works before jumping in. And in these days when people pay with credit and debit cards and all kinds of other non-cash payment methods, and when the register tells the cashier exactly how much change to give back, nobody has any experience in making change any more, neither cashiers nor customers.

So here's the process:

Give out $100 bills until you owe less then $100.

Give out $50 bills until you owe less than $50.

Give out $20 bills until you owe less than $20.

Give out... okay, you get the picture. But this is repeating myself in a big way. So you'd write a loop to encapsulate that repeating logic:

For each denomination X (from largest to smallest): give out X until you owe less than X.

That's all you need. Notice that separating dollars from cents doesn't appear in this logic, so doing that is going to complicate things. Value all your denominations in cents (e.g. a $5 bill is worth 500 cents). And also notice that "you owe" in the description of what to do implies that you have to keep track of how much you owe as you give out currency.

I had to look at all those % calculations for quite a while before I realized they worked, but I guess they do work. Kind of neat in one way. However there's a programming principle called "DRY" which stands for "Don't Repeat Yourself" and your code definitely repeats itself. The others have already alluded to other ways to solve the problem, but it's helpful to think about how the process works before jumping in. And in these days when people pay with credit and debit cards and all kinds of other non-cash payment methods, and when the register tells the cashier exactly how much change to give back, nobody has any experience in making change any more, neither cashiers nor customers.

So here's the process:

Give out $100 bills until you owe less then $100.

Give out $50 bills until you owe less than $50.

Give out $20 bills until you owe less than $20.

Give out... okay, you get the picture. But this is repeating myself in a big way. So you'd write a loop to encapsulate that repeating logic:

For each denomination X (from largest to smallest): give out X until you owe less than X.

That's all you need. Notice that separating dollars from cents doesn't appear in this logic, so doing that is going to complicate things. Value all your denominations in cents (e.g. a $5 bill is worth 500 cents). And also notice that "you owe" in the description of what to do implies that you have to keep track of how much you owe as you give out currency.