Quote:
|
I never figured that MPGuino would be used to do this sort of fine measurement.
|
Well, then now is a good time as any to roll out this potato: I need your routine to calculate mileage down to the ten-thousandth, which will result in resolution of about a foot. (In my car, technically, 6.7 inches, which is actually good to display to the foot; based, sort of, on the 2x sampling principle).
Why? Not sure -- but it had its genesis in me measuring how far apart the monorail support poles are in downtown Seattle. I think they are 60 feet. Once you start looking at short distances in the car you'll be shocked how hard it is for humans to estimate linear distance in a car, while vertical distance remains easy. This is true even while stopped, but I'm sure it's a psychological by-product of driving.
I view an odometer as a threshold event, one that should never round. I'm open to being convinced otherwise, but the math is simple enough: number - (number % .000x) x being the digits to be thrown away and not used for rounding.
Once I can call numbers down to the .0001, I can easily add math that does this:
miles - (miles % .01) * (milesIdx * 5280) = (a number between 0 and 53, inclusive). Then I can render miles as 52.25 miles, 48 feet. At 53 feet (well, 52), then it'd be 52.26 miles, 0 feet. I suppose 52.259 miles and 0-5 feet, but you get the idea. I'll also fool around with 52 miles, 1368 feet, but that'll probably not be pleasing to look at.
Also, I know from experience it's not as pleasant to render feet above certain speeds, primarily due to movement of the output based on single vs. double digit feet, but also it's patently ridiculous to want feet or centimeters at highway speeds. Again, easy for me to code using if/then.
That said, a quick question: Are conditional if/then statements computationally efficient?
Meters can use .0001 and that's a perfectly human way to view centimeters. Or we leave them at 001 and show meters. cm and inches both would jump since .0001 < ticks / milesIdx, but that's OK.