Summer Labview Challenge 2

[Bpk9p4]

The challenge is to create a change machine

Part 1
You have an item that cost X and you are given X amount of money. The program will need to give back the correct amount and least amount of dollars and coins

Example: You have a basketball that cost $10.23 and they give you $20. You will need to give them back 1 five dollar bill, 4 one dollar bills, 3 quarts, 2 pennies

Inputs:
1) Cost of Item
2) Amount Paid
Outputs:
1) Number of $20
2) Number of $10
3) Number of $5
4) Number of $1
5) Number of Quarters
6) Number of Dimes
7) Number of Nickels
8) Number of Pennies

Part 2:
Same as above but you only have a limited number of each denomination however you still need to give the correct amount of change. If you cannot give back the correct amount you will need to give a fault and notify the clerk

Example: You have a basketball that cost $10.23 and they give you $20. However you only have 2 quarters. You will need to give them back 1 five dollar bill, 4 one dollar bills, 2 quarts, 2 dimes, 1 nickel and 2 pennies

Inputs:
1) Cost of Item
2) Amount Paid
3) Amount of $20
4) Amount of $10
5) Amount of $5
6) Amount of $1
7) Amount of Quarters
8) Amount of Dimes
9) Amount of Nickels
10) Amount of Pennies

Outputs:
1) Number of $20
2) Number of $10
3) Number of $5
4) Number of $1
5) Number of Quarters
6) Number of Dimes
7) Number of Nickels
8) Number of Pennies
9) Cannot give back the correct change

If you have any questions please feel free to ask them and post your result on here. Thanks

[Owen Busler]

This is my solution to part 1... Im not so sure how to handle part 2.

http://postimg.org/image/nkqro4gxd/

[Ari423]

Originally Posted by Bpk9p4

The challenge is to create a change machine

Part 1
You have an item that cost X and you are given X amount of money. The program will need to give back the correct amount and least amount of dollars and coins...

Here's my submission for Part 1. I converted the change to an integer to ensure nothing less than 1c and to get rid of floating point errors. This was the simplest solution I could come up with, but I'm interested in seeing if anyone can one-up me



Part 2 coming soon...

[Bpk9p4]

nice work. I look forward to seeing your answer to part 2

[Jonathan L.]

Here is part 1.

I came across a strange LabVIEW bug while I was doing this. If you remove the "Workaround" code and put in the basketball example you will see it outputs only one penny.

Part 2 coming soon.

[GuyM142]

This is my solution to both parts

[Ari423]

Here is my submission to part II. It's similar to part I, except each time it adds how much of that type it's missing back into 'the pot'. At the end, I added a feature that calls the vi from part I to see what the minimum amount of extra change would be needed to make change correctly (the input wire is "paid" and "price" is left at the default of 0). I only had a brief chance to test the program, but I believe it works. If anyone finds a problem with it, please let me know.

[Greg McKaskle]

The strange bug happens because by the time you have made it to the penny calculation, the remainder is no longer a full two cents. If you display it with about 15 digits of precision, it is truly just a bit below, so the node returns almost a full penny as a remainder. This is largely due to the fact that floats cannot store base ten fractions precisely. The mixup rounds the value so that the small cumulative error resets. A different fixup would be to convert the initial value to units of pennies instead of dollars.

Greg McKaskle

[Jonathan L.]

Here's Part 2.

Originally Posted by Greg McKaskle

The strange bug happens because by the time you have made it to the penny calculation, the remainder is no longer a full two cents. If you display it with about 15 digits of precision, it is truly just a bit below, so the node returns almost a full penny as a remainder. This is largely due to the fact that floats cannot store base ten fractions precisely. The mixup rounds the value so that the small cumulative error resets. A different fixup would be to convert the initial value to units of pennies instead of dollars.

Greg McKaskle

Thank you for explaining. So is this something that can be fixed by NI or just a quark in programming? I remember there was something similar last year with the equal function but that seems to have been fixed.

[Mark McLeod]

Originally Posted by Jonathan L.

Thank you for explaining. So is this something that can be fixed by NI or just a quark in programming?

That's due to how computer hardware in general works.
Part of programming is understanding the underlying computer implementation, and this is just one of the quirks or limitations.

[Ari423]

Originally Posted by Mark McLeod

That's due to how computer hardware in general works.
Part of programming is understanding the underlying computer implementation, and this is just one of the quirks or limitations.

It is a limitation in the imementation of floating point numbers (like doubles or singles). If you convert the dollars to cents by multiplying by 100 and then cast that as an integer, the problem will go away because integers do not have that problem.

[Mark McLeod]

Take a look at the Wikipedia article on floating point representation for a description of the issue we face:
https://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conversion _and_rounding

For example, the decimal number 0.1 is not representable in binary floating-point of any finite precision; the exact binary representation would have a "1100" sequence continuing endlessly: e = −4; s = 1100110011001100110011001100110011...,

When rounded to 24 bits this becomes
e = −4; s = 110011001100110011001101,
which is actually 0.100000001490116119384765625 in decimal.