Metric vs Imperial, 30 years later
-
@PJH said:
@zolf said:
and uses pounds when receiving packages.
Pound-mass or Pound-force?Pound-currency.
True story: A few months ago I was in London on a business trip. On my last day I had a few hours to kill before heading back to the airport, so I was strolling around Oxford St. I wandered into Selfridges, where Gordon Ramsay happened to be doing a book signing. I checked out the book but decided it wasn't worth the £25 cover price with the dollars-to-pounds exchange rate being what it was. So I snapped a few photos of the chef and went on my way.
When I got home I showed my wife the pics and told her I didn't buy the book "because it was 25 pounds." She said, "Wow, why was it so heavy?"
-
@joelkatz said:
No, it's not the case. You are the only person in the world who finds this confusing. Everybody else has no difficulty implying the level of accuracy from context. When a person says they're "6 feet tall", other people have no difficulty infering the implied error bars.
In any event, if you were right, pretty much the whole world would be a WTF, since almost nothing permits you to enter error bars on your data.
Nobody is saying that a qualitative margin of error can't be inferred from the manner in which some measurement is communicated, but you are conflating the concepts of accuracy and precision. 10 cm with a 10% margin of error is identical to 3.937" with a 10% MoE. I thought people learned this in high school general science at the very latest.
We all understand your basic premise, that the printed phrase "10 cm" implies that somebody took a very rough measurement, and "3.937 inches" implies that somebody took a very precise measurement, but (a) you absolutely cannot infer a specific MoE and range of valid values from that, (b) computer systems don't assume anything about "significant digits", and (c) none of this matters unless you completely ignore context.
As I mentioned earlier, most systems that handle conversion of this nature have to record the original unit, so it's still easy to ascertain that the original measurement was approximate. In addition, in the context of a shipping system, it frankly does not matter whether 3.937" is a precise measurement or a rough measurement. It's just not important, unless you're right at the threshold of a price increase, in which case you'd want to inform the customer regardless ("Please note that 125 cm is very close to the 50" tier, and if it turns out to be 127 cm or more then we have to charge extra").
-
@cconroy said:
Gordon Ramsay {publicity}
Not even worth 25p or 25 seconds.
Money well not spent.
@cconroy said:
When I got home I showed my wife the pics and told her I didn't buy the book "because it was 25 pounds." She said, "Wow, why was it so heavy?"
Um. Did she really say that? Ya, know, given the circumstances, and such....
-
@PJH said:
What cconroy failed to mention is that his wife is stupid. Maybe he assumed you'd figure this out, given that all women are stupid.@cconroy said:
When I got home I showed my wife the pics and told her I didn't buy the book "because it was 25 pounds." She said, "Wow, why was it so heavy?"
Um. Did she really say that? Ya, know, given the circumstances, and such....
-
@Aaron said:
As I mentioned earlier, most systems that handle conversion of this nature have to record the original unit, so it's still easy to ascertain that the original measurement was approximate. In addition, in the context of a shipping system, it frankly does not matter whether 3.937" is a precise measurement or a rough measurement. It's just not important, unless you're right at the threshold of a price increase, in which case you'd want to inform the customer regardless ("Please note that 125 cm is very close to the 50" tier, and if it turns out to be 127 cm or more then we have to charge extra").
If someone enters 10 cm, 4 inches could be a price break point. So you have two choices:
1) Always fail when someone enters the wrong units.
2) Sometimes fail when someone enters the wrong units, when the conversion puts you close to a price break point.
Those are the two choices. Sometimes 1 may be better, sometimes 2 may be better. But there are strong reasons to prefer choice 1. For example, a person facing a system that takes choice two may fix problems as they appear. They enter "10cm" and it works, so they leave it that way. But then, if a new pricing tier is added, orders that used to process just fine now fail. It may well be preferable to insist that units be in the form needed at the end, so that things don't switch between working and failing.
There is no WTF. Refusing to convert (and having to either sometimes fail or sometimes do the wrong thing) is a valid implementation choice. If the conversion has to be done somewhere, and it is possible to push it closer to the source of the measurement, that is usually better.
-
She did say that, but after a few funny looks and "um"s she realized what I meant, and we had a good laugh about it.
Then she made me a sandwich.
-
@joelkatz said:
If someone enters 10 cm, 4 inches could be a price break point. So you have two choices:
1) Always fail when someone enters the wrong units.
2) Sometimes fail when someone enters the wrong units, when the conversion puts you close to a price break point.
I choose option (3): don't fail. I don't know where you come up with this garbage. It sounds like you created one of these lousy designs and are desperately trying to justify it.
There are numerous ways for systems to handle units and conversions without ever having to fail. Refusing to convert is not an implementation choice at all, it is an architecture and design choice, and it is only a valid one if the specs clearly say that it is - otherwise you'd want to assume that the system is supposed to do what one would actually expect it to do.
Pushing extra work onto users that the system is completely capable of doing on its own is rarely a smart choice. I can just imagine having to fill out some form that insisted on me entering my weight in kg and my height in cm and refused to accept anything else. My response would almost certainly be "No thanks, I'll take my business elsewhere". And remember, this is coming from a Canadian, not an American; I don't have any problem with metric units in principle.
-
@Aaron said:
My parents refer to all temperatures in Fahrenheit. Drives me crazy because I always have to do the conversion.
I drive people crazy by misinterpreting that...
Other guy: "Man, it's like forty degrees out here."
Me: "Must be nice. It's pretty cold over here."
(Where "here" is on the order of eight feet. Or a little over two metres.)
-
@Aaron said:
@joelkatz said:
If someone enters 10 cm, 4 inches could be a price break point. So you have two choices:
1) Always fail when someone enters the wrong units.
2) Sometimes fail when someone enters the wrong units, when the conversion puts you close to a price break point.
I choose option (3): don't fail. I don't know where you come up with this garbage. It sounds like you created one of these lousy designs and are desperately trying to justify it.
There are numerous ways for systems to handle units and conversions without ever having to fail. Refusing to convert is not an implementation choice at all, it is an architecture and design choice, and it is only a valid one if the specs clearly say that it is - otherwise you'd want to assume that the system is supposed to do what one would actually expect it to do.
Pushing extra work onto users that the system is completely capable of doing on its own is rarely a smart choice. I can just imagine having to fill out some form that insisted on me entering my weight in kg and my height in cm and refused to accept anything else. My response would almost certainly be "No thanks, I'll take my business elsewhere". And remember, this is coming from a Canadian, not an American; I don't have any problem with metric units in principle.
Okay, so since you know how to do it, tell me how to do it. If your automated system receives a measurement of 10 cm from another automated system and 4 inches is a price break point, how do you not fail?
Also, you seem to have missed that nothing was pushed onto users but onto the source of the data. That is, the implementors chose to force the source of the data to convert it rather than converting it at the endpoint. This is a measurement inside an XML object sent from one system to another. The implementation choice was this -- if some system must convert, should it be the sender or the recipient? They chose to push the conversion closer to the source, which is a common best practice.
-
@versatilia said:
Both shipping companies I've integrated with reckon they will accept distance units of 'cm' or 'in' and weight units of 'kg' or 'lb'.
WTF? How much would it cost me to ship a 2 pound package 30 inches, then?
-
@joemck said:
@versatilia said:
Both shipping companies I've integrated with reckon they will accept distance units of 'cm' or 'in' and weight units of 'kg' or 'lb'.
WTF? How much would it cost me to ship a 2 pound package 30 inches, then?
'£5 (five foot-pounds), naturally.
-
@Aaron said:
Okay, so since you know how to do it, tell me how to do it. If your automated system receives a measurement of 10 cm from another automated system and 4 inches is a price break point, how do you not fail?
10 cm is less than four inches, so you charge the lower price. 11 cm is more than four inches, so you charge the higher price.
No more precision than that is needed.
-
I'm disappointed - nobody has even mentioned the speed of the reference frame in which the measurements were taken. After all, if I measure a box as 10 cm long but am traveling at 0.5c relative to another frame, do I tell the other frame that I've got a box 10cm long or 8.66cm long*?
(I'm doing length contraction from memory, so that number might not be correct, but you get the idea...)
*Yes, I realize that if you slow the box down so it is useful in the other frame they should measure the same "10cm". Assuming the deceleration doesn't squish the box, of course.
-
@WayneCollins said:
@joelkatz said:
Don't blame poor Aaron for joelkatz' silliness.Okay, so since you know how to do it, tell me how to do it. If your automated system receives a measurement of 10 cm from another automated system and 4 inches is a price break point, how do you not fail?
10 cm is less than four inches, so you charge the lower price. 11 cm is more than four inches, so you charge the higher price.No more precision than that is needed.
-
@joelkatz said:
Okay, so since you know how to do it, tell me how to do it. If your automated system receives a measurement of 10 cm from another automated system and 4 inches is a price break point, how do you not fail?
The first thing you do is assume that the price break points themselves are 100% accurate with "infinite" precision. Then you convert the price break point to the input units. 4" = 10.16 cm. Threshold is higher than the input value, so you charge the lower price. Check tolerance, see that the input value is within 1.57% of tolerance, kick off a warning to the customer or shipping clerk that the measurement is within (for example) 2% of a tier, and that additional charges may apply if the measurement is found to be incorrect when the boxes come in for shipping and a real, accurate measurement is taken. Easy peasy.
Note that if the system uses high enough precision internally (double-precision float or fixed[4] is generally sufficient) then it does not matter in which direction you do the conversion. However, if you are concerned about rounding errors, then you convert the quantities that are known to be most accurate and/or precise whenever possible instead of the uncertain ones.
The issue isn't one of conversion, it's one of measurement. You have the same problem if you have a price break point at 4" and a customer gives you a measurement of 4". Is it exactly 4"? Is it maybe a little less? A little more? Either way, you need to be aware of the fact that this is very close to a price break, and either way, you need to take another measurement yourself when you actually get the box.
Also, you seem to have missed that nothing was pushed onto users but onto the source of the data. That is, the implementors chose to force the source of the data to convert it rather than converting it at the endpoint. This is a measurement inside an XML object sent from one system to another. The implementation choice was this -- if some system must convert, should it be the sender or the recipient? They chose to push the conversion closer to the source, which is a common best practice.
Users don't know or care what a data source is. No amount of technical nitpicking alters the fact that you have created more (unnecessary) work for somebody. No doubt it is a common practice, but that does not make it a good one and certainly not "best". The "sender" is a human and the "recipient" is a computer, therefore, the recipient should always do the conversion. In any transaction between a human and a computer, the computer should do as much work as can be done practically.
And once again, the I/O of a system is an architectural choice, not an implementation choice. If you believe it to be an implementation choice then I would have to assume that you are either a cowboy coder or junior-level programmer who is ignorant of architecture. Either way, you should probably cut your losses in this debate and move on.
-
@Aaron said:
The first thing you do is assume that the price break points themselves are 100% accurate with "infinite" precision. Then you convert the price break point to the input units. 4" = 10.16 cm. Threshold is higher than the input value, so you charge the lower price. Check tolerance, see that the input value is within 1.57% of tolerance, kick off a warning to the customer or shipping clerk that the measurement is within (for example) 2% of a tier, and that additional charges may apply if the measurement is found to be incorrect when the boxes come in for shipping and a real, accurate measurement is taken. Easy peasy.
In other words, the system should do exactly what it did. It detected that a unit mismatch could cause the wrong tier to be selected and asked the origin to do the conversion so that it could pick the right tier. The only difference between your solution and its is that your solution would require human intervention and its solution did not.
@Aaron said:
The issue isn't one of conversion, it's one of measurement. You have the same problem if you have a price break point at 4" and a customer gives you a measurement of 4". Is it exactly 4"? Is it maybe a little less? A little more? Either way, you need to be aware of the fact that this is very close to a price break, and either way, you need to take another measurement yourself when you actually get the box.
No, you don't. The systems are specifically designed so that price break points don't cause that problem in their native unit of measurement. For example, if a reported break point is 4 pounds, it's actually more like 3.5-4.5 pounds. So long as you don't introduce additional error from conversion, the "error" in the price break point is sufficient to ensure the package will be accepted.
@Aaron said:
Users don't know or care what a data source is. No amount of technical nitpicking alters the fact that you have created more (unnecessary) work for somebody. No doubt it is a common practice, but that does not make it a good one and certainly not "best". The "sender" is a human and the "recipient" is a computer, therefore, the recipient should always do the conversion. In any transaction between a human and a computer, the computer should do as much work as can be done practically.
This is a transaction between two computers. It's an XML query. Read the OP.
-
@pscs said:
PS - road signs also measure shorter distances in yards. (They can't use metres, or the 'm' abbreviation would be ambiguous).
Ehhh?
m = meters
km = kilometers
mi = miles
yd = yards
That's how signs are done on this side of the ocean... :)
-
@shepd said:
That's how signs are done on this side of the ocean... :)
That's true, but if you've ever been on the M1...London 113m
(that's miles.)
The U.S. has an easier system:
Washington 8
(also miles)
