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?
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.
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.
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.
My user base are not the sharpest tools in the shed - so I need to do as much logic as I can in the business rules.
> 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.
> 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.
> 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?
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.
Last edited by markd220; Dec 1st, 2008 at 4:46 pm.
Either the thread starter or a moderator has marked this thread as solved. You can most likely trust the responses and answers given. There is most likely no reason for any further responses to be posted here. If you have a related question, please start a new thread in this forum instead.
This thread is more than three months old
No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.
Previous Thread in Computer Science Forum Timeline:Loop rules - Case
Marked Solved 
Offline 
