Unit Converter Widget can't do simple math....

[yg17]

I was messing around with the Unit Converter and it can't do some simple math operations. The example I found was converting miles/hr to miles/min. Have it convert 60mph to mpm. The math should be 60/60=1, but instead, the answer is .999something. This has got to be a bug I assume? I couldn't imagine a G5 processor not being able to calculate what a number divided by itself is.

It also gives similar results for easy calculations like 30/60, 120/60, ect, which should be .5 and 2, instead its a long decimal.

 

[Phatpat]

I haven't gotten a chance to play around with it, but I've always assumed it would just be faster to do unit conversions in google. Using the mouse is a pain...

 

[jamdr]

Yeah, Google does awesome unit conversion. I couldn't get through engineering school without it. As far as inaccurate floating point numbers, this came up not to long ago with regards to the calculator in OS X. I'm not sure what the problem is in this case, because it seems a number divided by itself should not introduce any rounding errors in the calculation. Oh well, just use Google.

 

[shane1]

Floating point rounding error

I was messing around with the Unit Converter and it can't do some simple math operations. The example I found was converting miles/hr to miles/min. Have it convert 60mph to mpm. The math should be 60/60=1, but instead, the answer is .999something. This has got to be a bug I assume? I couldn't imagine a G5 processor not being able to calculate what a number divided by itself is.

It also gives similar results for easy calculations like 30/60, 120/60, ect, which should be .5 and 2, instead its a long decimal.

This is likely because the widget is using "floating point" arithmetic to do its calculations. The way computers represent decimal numbers lets them represent a wide range of very precise numbers, but can introduce rounding errors, as you're seeing. I apologize for the overly technical link, but basically, the results of some floating point calculations just don't come out as exact whole numbers, even with they mathematically should.

 

[csubear]

This belongs to the land of floating point numbers.

Floating point numbers are approximations, most the the time very good approximations. But there are some numbers that simply can not be expressed as floats.

Proof:

The set to all floating point numbers is infinite.
A floating point number stored in a computer has a finite set of bit to represent number.
It is impossible to express all member infinite set in a finite representation.

Or something like that.

 

[benbondu]

Rounding errors or not, 10^-4 accuracy isn't that great. I can't see how the conversion of mph to mpm can be more than one calculation. My guess is that the convertor is multiplying by the inverse of 60 rather than dividing by 60. (given the lack of correct digits of the answer, the stored value of the inverse of 60 probably isn't very accurate)

What I don't get is why they bothered showing 8 decimal digits since you can obviously only trust half of them at most. Apparently not a lot of effort was spent on this widget.

But.... having said that, it doesn't really matter. No one is going to be doing any scientific research with this thing. 4 correct digits is good enough for me. I'd never use the rest even if they were right.

 

[MisterMe]

Rounding errors or not, 10^-4 accuracy isn't that great. I can't see how the conversion of mph to mpm can be more than one calculation. My guess is that the convertor is multiplying by the inverse of 60 rather than dividing by 60. (given the lack of correct digits of the answer, the stored value of the inverse of 60 probably isn't very accurate)

What I don't get is why they bothered showing 8 decimal digits since you can obviously only trust half of them at most. Apparently not a lot of effort was spent on this widget.

But.... having said that, it doesn't really matter. No one is going to be doing any scientific research with this thing. 4 correct digits is good enough for me. I'd never use the rest even if they were right.

I agree that all displayed digits should be correct. The fact that they are not betrays a bit of sloppy programming. There are algorithms which ensure the accuracy of all displayed digits in the result. In the case at hand, most people wouldn't care if the conversion had been from 79 miles/hr to mile/min. That said, it is also important that we accurately describe the extent of the inaccuracy. In the conversion, 60 miles/hr is displayed as 0.99997152 miles/min. This represents an error of 2.848 X 10^(-5) for accuracy nearly 4 times as great as you stated.