the decimal piece ends up being .4954, and this is repeatable.....it is always .0002 off from the expected value. I progressively printed out an evaluation of that statement and it maintains the correct value until I add the arguments in front of the plus sign. What could be going wrong with this? The calculation for latitude works fine....just the longitude is the problem.
1000000 doesn't look much like an int. 1000000UL does, on the other hand, look like an unsigned long.
http://snippets-r-us.com might be able to help you. We can't verify that latit1, latit2, longit1, and longit2 are what you say they are (properly NULL terminated arrays of chars).
Intermediate variables, and Serial.print() statements, might help.
Well I figured out where the problem is but I am not sure how to fix it. To be honest, for this application this level of precision is ridiculous but it still just bugs me that it is coming out like this. Basically, these two lines:
f = atof(longit1);
Serial.println(f, 4);
result in the output:
7406.0000
and
f /= 100.00;
longdegrees = (int)f; //isolate degrees
Serial.println(longdegrees);
Time to look into fixed-point long int or long long int.
Or if you want kilometers to 6 places them work in millimeters and save the decimal point for displays only. That will save you from a lot of work and confusion while keeping the digits exact down to whatever unit you use.
No. You are performing floating point arithmetic. The 5.9998 value is perfectly reasonable.
Print out f to 6 decimal places, after you divide it by 100.0, to see that.
Ahh.....74.059997. So is there some fix or is this just something we all accept if we insist on working with floating points (and are too lazy to learn fixed point math)?
KeithRB:
"Working with floating point is like moving piles of sand. Every time you move one you lose a little sand and pick up a little dirt."
LOL
OK, this might be a old well known phrase for some, but I've never heard it before and it sums up my experience and limited knowledge of floating point math. My rule is to just say no to FP in a arduino setting unless it's limited to having to receive numbers from some external source that you can not do anything about.
Just because the gcc compiler offers some functions, doesn't mean you have to use them or if they are even useful in a arduino environment.
I got it from Kernigham and Plauger: "The Elements of Programming Style", first copyrighted in 1974. Most of the examples are in FORTRAN and PL/1! But it is still a great read about, well, programming style. They really pick on Daniel McCracken*.
They actually present the quote as from a "wise programmer". It is easy to find the quote in the book since the index lists "floating point numbers as sandpiles" 8^)
*For those that don't know, anyone who learned FORTRAN in the '70s and '80s probably used a text by McCracken.
Our FORTRAN book at Drexel had WAT4/WAT5 in the title. Must have been derivative.
Not that I had the $ to stay anyway. Punched the cards, waited for printouts, learned damned little.
When I got a TI-56 in Jan 78 I learned more in the 1st month than that semester at Drexel. I learned for example how badly I wanted indirect addressing! LOL! Got that in the TI-59.