Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   NI LabVIEW (http://www.chiefdelphi.com/forums/forumdisplay.php?f=182)
-   -   Summer Labview Challenge 2 (http://www.chiefdelphi.com/forums/showthread.php?t=137804)

Bpk9p4 07-21-2015 04:23 PM

Summer Labview Challenge 2
 
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 07-21-2015 07:32 PM

Re: Summer Labview Challenge 2
 
This is my solution to part 1... Im not so sure how to handle part 2.

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

Ari423 07-21-2015 09:19 PM

Re: Summer Labview Challenge 2
 
1 Attachment(s)
Quote:

Originally Posted by Bpk9p4 (Post 1490864)
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 :D

Attachment 19224

Part 2 coming soon...

Bpk9p4 07-23-2015 02:49 PM

Re: Summer Labview Challenge 2
 
nice work. I look forward to seeing your answer to part 2

Jonathan L. 07-23-2015 05:03 PM

Re: Summer Labview Challenge 2
 
1 Attachment(s)
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 07-23-2015 05:25 PM

Re: Summer Labview Challenge 2
 
1 Attachment(s)
This is my solution to both parts

Ari423 07-23-2015 08:16 PM

Re: Summer Labview Challenge 2
 
1 Attachment(s)
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.

Attachment 19227

Greg McKaskle 07-23-2015 10:38 PM

Re: Summer Labview Challenge 2
 
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. 07-24-2015 10:42 PM

Re: Summer Labview Challenge 2
 
1 Attachment(s)
Here's Part 2.

Quote:

Originally Posted by Greg McKaskle (Post 1491171)
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 07-24-2015 11:07 PM

Re: Summer Labview Challenge 2
 
Quote:

Originally Posted by Jonathan L. (Post 1491245)
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 07-24-2015 11:24 PM

Re: Summer Labview Challenge 2
 
Quote:

Originally Posted by Mark McLeod (Post 1491246)
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 07-25-2015 08:47 AM

Re: Summer Labview Challenge 2
 
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

Quote:

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.



All times are GMT -5. The time now is 06:06 PM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi