Anyone good at math? I don't recall the rules for decimal accuracy. The database usually takes fuel economy values in tenths. Does that mean that the overall median is accurate to tenths? Remember that the median car has its mileage value calculated as a weighted average.

 

No, it doesnt, it COULD be acurate to the hundredths or maybe more. I'm not sure the forumal that you use for the median, but the signifigant figures that you end up w/ should be equal to what you start with unless you add/subtract allong the way.

 

There's only one formula for median that I know of. Take the middle value or if there's an even number, the average of the middle two.

There's just 1 significant figure for sure for each car. That's why I'd think we can be accurate to 1.

 

The entire business of precision can be rather non-intuitive ... :-)

My car is reported as 51.5 in the GH DB, but is 51.355 by my arithmetic. I take the lifetime odometer reading at last fill-up / the sum of fill-up amounts (recorded to 3 digits after the decimal on each tank. My mileage has a precision error of 1/miles traveled; the gas consumption 1/1000. Since I have traveled over 1000 miles, the gas consumption becomes the major source of error -- ergo, 1/1000.

Off-hand I would guess the error in the GH DB is due to summing the rounded tanks, which introduces cumulative error. I agree with you that it is not much greater than 0.1 mpg lifetime, because the rounding errors on each tank tend to cancel themselves out over time.

 

Tanks aren't rounded. The numbers you see are rounded, but the numbers in the database are carried out many decimal places.

 

If you post the actual code the DB performs to calculate lifetime mpg, I'll be able to comment further.

 

For the sake of security and originality, I can't post the actual code. But, I obviously know exactly how it works.

Overrides just accept whatever figure the member provides, which is in tenths for mileage and ones for distance.

When it's tank by tank, the input is usually tenths and ones again unless they use the gallons>mileage converter. In that case, there's insignificant rounding (7 places?) and the mileage figure is stored as an extended decimal. The tank averages are weighted based on distance [(d1*m1)+(d2*m2)+(d3*m3)]/(m1+m2+m3) and the final car's mileage is stored with the same long decimal.

 

I am a bit confused what "typical" inputs are, but assuming it is tank miles and gallons ..

Lets start with two tanks:

miles____Gallons
1000__________9.999
1000__________9.900

The precision of a tank distance is 1/1000, the tank filling 1/10000. End precision is always the least precise measurement involved, so the best we can do is 1/000. If we calculate

2000/19.899, we get 100.5 +/- 0.1 (0.1/100 is 1 part per thousand)

Now we'll calculate by your code:
Tank one is 1000/9.9. MPG is 101.010
Tank two is 1000/9.9 MPG is 101.010

Weighted average gives 101.0 +/- 0.1 (0.1/100 is 1 part per thousand)

So, your maximum theoretical imprecision is about 0.7. In practice you are nowwhere near that, of course, since I took extreme tank numbers.

You cannot improve upon the precision of the data entered, but I suggest you keep 3 digits after the decimal in your data inputs and intermediate calcs rather than discarding it, if your wish is to improved precision. Display of one digit after the decimal is surely enough.

More to the point (sorry for the lousy pun), I am not clear why the roundabout method to compute lmpg. Total miles/ total tank fill-ups seems less compute intesive. You still have to keep all the precision you are given for best results.

 

Eric, again let me emphasize that the database does not round actual values - only the display. You're also assuming that everyone inputs miles and gallons. In reality, I believe most input miles and miles per gallon. That's also the way the database was initially created. Miles per gallon by the display is always [that I know of] provided to the tenths. Tenths, then, is what we must assume tank decimals to be.

The reason why I don't calculate cars by miles/gallons is because miles and miles per gallon are the values stored for the reason stated above. It doesn't make a mathematical difference, as nothing the user inputs is ever rounded.

There is also the additional error of the car's display value and/or the gas pump's inaccuracies. These can only be assumed and estimated. So, when calculating error, one would have to find the error for each car (somehow) and then incorporate that into the error for each model. I have no idea how that could be achieved, but then again I just took my first statistics course this year.

 

How's this for ironic? I took my statistics AP national exam this week and think I did well, yet I can't answer a very basic statistics question: what's the difference between standard deviation and standard error? I know standard error is sd/(n)^(1/2) but which is appropriate when describing the mileage data? I have sd being calculated now, but should it be error?

I'm thinking it should be error, as this takes into account the possibility for bias in the data and uses the sample size in the calculation. Boy, I hate stat.