 |  |  |  |  |  |  |  |
Weight Conversion Storage
Please support our Computer Science advertiser: Learn about neural networks and artificial intelligence.
Thread Solved |
I have a problem and need some ideas. I have an app that lets the user enter in weights in different units and I need a way to store the data so the total weight gets taken in the end (or at least gets close)
One screen the user can enter 700lbs.
Another screen the user can use that 700lbs but enters it in Metric Tons (0.317). The loss of precision is killing me because the conversion back to lbs is 698.865.
I need the back end to "know" they really mean 700lbs. Are there any cool techniques that I'm not thinking of?
Thanks,
MD
One screen the user can enter 700lbs.
Another screen the user can use that 700lbs but enters it in Metric Tons (0.317). The loss of precision is killing me because the conversion back to lbs is 698.865.
I need the back end to "know" they really mean 700lbs. Are there any cool techniques that I'm not thinking of?
Thanks,
MD
•
•
Join Date: Dec 2005
Posts: 5,850
Reputation: 
Solved Threads: 749
What do you get if you
- divide by 10
- take the integer part
- multiply by 10
- divide by 10
- take the integer part
- multiply by 10
I have seen this problem before. I would advise
(a) Never round up/down until the end.
(b) It is tempting to count the large number significant bits in the input data e.g. if the user enters 3.45 lb + 12.3 oz. And then say round to 3 sig.fig. but you will annoy more users than not.
(c) It is better to round to +/- 2 + log_e(items_added) of the lowest significant number. E.g in the example above the SLN is 0.1 oz so you get a +/-0.25 oz.
spread into the base units.
In short that worked for me, but it depends on your user base.
If this is a scientific user base, you are less and less able to round numbers and you head from biology to physics.
(a) Never round up/down until the end.
(b) It is tempting to count the large number significant bits in the input data e.g. if the user enters 3.45 lb + 12.3 oz. And then say round to 3 sig.fig. but you will annoy more users than not.
(c) It is better to round to +/- 2 + log_e(items_added) of the lowest significant number. E.g in the example above the SLN is 0.1 oz so you get a +/-0.25 oz.
spread into the base units.
In short that worked for me, but it depends on your user base.
If this is a scientific user base, you are less and less able to round numbers and you head from biology to physics.
I've tried the simple power of 10 tricks and that still didn't help me solve the underlying problem.
In the db, I store everything in lbs. So the MT conversion from .317 that the user entered needs to get saved, but there isn't a good way in the business rules to figure out that the precision was lost because of the user.
Thanks for the tip though.
In the db, I store everything in lbs. So the MT conversion from .317 that the user entered needs to get saved, but there isn't a good way in the business rules to figure out that the precision was lost because of the user.
Thanks for the tip though.
•
•
•
•
Originally Posted by StuXYZ 
I have seen this problem before. I would advise
(a) Never round up/down until the end.
(b) It is tempting to count the large number significant bits in the input data e.g. if the user enters 3.45 lb + 12.3 oz. And then say round to 3 sig.fig. but you will annoy more users than not.
(c) It is better to round to +/- 2 + log_e(items_added) of the lowest significant number. E.g in the example above the SLN is 0.1 oz so you get a +/-0.25 oz.
spread into the base units.
In short that worked for me, but it depends on your user base.
If this is a scientific user base, you are less and less able to round numbers and you head from biology to physics.
Thanks
•
•
Join Date: Dec 2005
Posts: 5,850
Reputation:
Solved Threads: 749
> I've tried the simple power of 10 tricks and that still didn't help me solve the underlying problem.
Well how accurate do you want the tonnes to pounds to be?
At 3 decimal places, each 1/1000th of a tonne is about 2 pounds.
So for example, 0.318 would be 701.0628, which on the face of it seems closer. Would that be rounded to even 700 as well?
I showed you 'truncate' in the hope that you might figure out 'round' for yourself.
But first, you need to decide what to round to, based on an input of decimal tonnes. If it isn't the nearest 10lb, then perhaps maybe 20 or 50.
If someone orders a tonne of sand, they're not going to be measuring it with a spoon when it's delivered.
Well how accurate do you want the tonnes to pounds to be?
At 3 decimal places, each 1/1000th of a tonne is about 2 pounds.
So for example, 0.318 would be 701.0628, which on the face of it seems closer. Would that be rounded to even 700 as well?
I showed you 'truncate' in the hope that you might figure out 'round' for yourself.
But first, you need to decide what to round to, based on an input of decimal tonnes. If it isn't the nearest 10lb, then perhaps maybe 20 or 50.
If someone orders a tonne of sand, they're not going to be measuring it with a spoon when it's delivered.
•
•
•
•
Originally Posted by Salem
> I've tried the simple power of 10 tricks and that still didn't help me solve the underlying problem.
Well how accurate do you want the tonnes to pounds to be?
At 3 decimal places, each 1/1000th of a tonne is about 2 pounds.
So for example, 0.318 would be 701.0628, which on the face of it seems closer. Would that be rounded to even 700 as well?
I showed you 'truncate' in the hope that you might figure out 'round' for yourself.
But first, you need to decide what to round to, based on an input of decimal tonnes. If it isn't the nearest 10lb, then perhaps maybe 20 or 50.
If someone orders a tonne of sand, they're not going to be measuring it with a spoon when it's delivered.
The rounding has to be exact. I need the app to know if the user entered .317 that what the really mean is 700lbs. I don't think I can solve this problem with a rounding technique. It'll have to be logic written with rules on the back end business rules. I don't like writing this kind of logic, but it is a requirement of the app. I have put a lot of thought into this problem, but ultimately it comes to bad UI design -- unfortunately, I do not have the power to change that.
Thanks to everyone for the help.
•
•
Join Date: Dec 2005
Posts: 5,850
Reputation:
Solved Threads: 749
> The rounding has to be exact. I need the app to know if the user entered .317 that what the really mean is 700lbs.
So what are the next (and previous) "exact" values?
Like .340 is 750 lb?
Would .316 be rounding that to something more "algorithmic" in nature, rather than some "de-facto" answer?
So what are the next (and previous) "exact" values?
Like .340 is 750 lb?
Would .316 be rounding that to something more "algorithmic" in nature, rather than some "de-facto" answer?
Let me quickly give a little background:
The app is an inventory program. They can preenter some info such as - I receive 700lbs. When they start removing inventory they enter in MetricTons. If the user enters .317 then there is still inventory of 1.134826lbs. There should be no inventory left when I'm done.
I've got something working now and I'm running through some samples. I'm taking the delta of the remaining inventory and factoring that back into the user-entered amount.
orig = (700/2204.622) 'preentered / conversion factor
r = round(orig,3) 'round to 3 because that is the max the user can enter
diff = (r - orig) 'get the delta of the rounded
v = .318 - ((.318/r) * diff)) * 2204.622
That seems to work. And all I have to do is in inverse of the formula to get the display UI to work correctly. This actually is changing the value before its saved to the db. I'll keep checking to see if I can poke holes in this logic.
The app is an inventory program. They can preenter some info such as - I receive 700lbs. When they start removing inventory they enter in MetricTons. If the user enters .317 then there is still inventory of 1.134826lbs. There should be no inventory left when I'm done.
I've got something working now and I'm running through some samples. I'm taking the delta of the remaining inventory and factoring that back into the user-entered amount.
orig = (700/2204.622) 'preentered / conversion factor
r = round(orig,3) 'round to 3 because that is the max the user can enter
diff = (r - orig) 'get the delta of the rounded
v = .318 - ((.318/r) * diff)) * 2204.622
That seems to work. And all I have to do is in inverse of the formula to get the display UI to work correctly. This actually is changing the value before its saved to the db. I'll keep checking to see if I can poke holes in this logic.
Last edited by markd220; Dec 1st, 2008 at 4:46 pm.
 |
Similar Threads
- memory management in wndows 2000 (Windows NT / 2000 / XP)
Other Threads in the Computer Science Forum
- Previous Thread: Loop rules - Case
- Next Thread: Kochcurve code is not working?
| Thread Tools | Search this Thread |
You need to join our community in order to build your list of favorite forums. You can visit the forum index for a listing of all forums.
Latest Computer Science Posts
- Today's Posts
- Unanswered Threads
Related Forum Features
ai algorithm algorithms amazon assignment assignmenthelp assignments battery bigbrother binary bittorrent bletchleypark blogging bomb business codebreaker compiler computer computers computerscience computertrackingsoftware connect conversion csc data dataanalysis dataintepretation development dfa dissertation dissertations dissertationthesis dissertationtopic ebook employment energy extensions floatingpoint foreclosure foreclosuresoftware fuel gadgets geeks givemetehcodez government graphics hardware history homeowners homeworkassignment homeworkhelp humor ibm idea ideas internet ipod itcontracts jobs kindle laser laws linkbait lsmeans mainframes marketing mining mobileapplication msaccess nano networking news os p2p piracy piratebay principles programming rasterizer sam-being-cute sas science security simulation software spying sql stephenfry study supercomputer supercomputing sweden technology textfield turingtest two'scompliment uk virus warehouse ww2
