Thread: Convert dms to dd

Hello,

I'm using the Pacific C for MS-DOS, v7.51 compiler from HI-TECH software. A function I wrote previously on the Microsoft Visual C++ 6.0 Professional Edition does not output the correct results.

Code:

   #include <stdio.h>
   #include <math.h>
                 
   double dms(double);   /* Convert deg.mmss to decimal degrees */

   main()
   {
   }

   double dms(double dd)
   {
      double dms = 0, mind = 0, secd = 0;
      int hr = 0, min = 0, sec = 0;

      dms = dd;
      hr = (int) dms;
      min = (int) ((dms - hr) * 100 + 1.e-6);
      sec = (int) (dms * 10000 + 1.e-6) % 100;
      mind = (double) min / 60;
      secd = (double) sec / 3600;
      dd = hr + mind + secd;

      return dd;
   }

The inclusion of "+ 1.e-6" was suggested to me because when I executed the function on the Microsoft compiler the results weren't always correct. I was told the "+ 1.e-6" would add some "junk" to the output. Now, when I execute the same code on the HI-TECH compiler, I do not get the correct results.

Examples:

Input Output Should Be

36.5212 36.86555556 36.87000000

45.0000 44.98555556 45.00000000

Merci,

Jacques

Your program needs to call the function!

To get more help, include your input and print statements.

Thanks very much for responding to my post! If you would add a variable containing the double 36.5212 and call the function in your compiler you would see what I am talking about. I don't know if this problem is unique to the Pacific C compiler or what.

I don't have that compiler, so I can't say if it's a compiler problem.

I'm not that familiar with radian to degree conversion, but in checking it out, I see equations like this:

"
Because it is the case that 1 deg = pi rad/180 and 1 rad = 180 deg/pi, we have the following conversion rules.

* To convert from degrees to radians, multiply degrees by (pi rad)/(180 deg).

* To convert from radians to degrees, multiply radians by (180 deg)/(pi rad).
"

But when I look at the math in your function, I see "happy feet" type math. Lots of dancing around, including a "fudge" factor, "just because...".



If you google "degree to radian", you'll get a whole page of hits. I'd recommend using another algorithm for the conversion, entirely. One with real clarity and definitely no "fudge factors".

Good luck.

Originally Posted by Adak

I don't have that compiler, so I can't say if it's a compiler problem.

I'm not that familiar with radian to degree conversion, but in checking it out, I see equations like this:



But when I look at the math in your function, I see "happy feet" type math. Lots of dancing around, including a "fudge" factor, "just because...".



If you google "degree to radian", you'll get a whole page of hits. I'd recommend using another algorithm for the conversion, entirely. One with real clarity and definitely no "fudge factors".

Good luck.

He's not trying to convert gradians to degrees.

I think that what he's trying to do is like this:

angle = 40.4559
would be 40 degrees, 45 minutes, 59 seconds

and then convert that to decimal

that would be:

40,76638.

Thanks Adak and Govalant for the replies! I wrote the above code because I couldn't find what I needed in the <time.h> library. I figured a dms to dd conversion and visa versa would be in there. I then thought about converting a number to a string and picking it apart into substrings. Since I'm just a neophyte programmer I didn't know how to do that.

If you get a working solution to this, please post it. I'm curious as to how you solve this problem. I work on surveying programs, so this particular problem, although not great, is problematic enough to where I created my own data structure and routines just to get around it. Anyway, I suggest using floor() instead of casting to get your integer parts since in some cases it might round up.

I think the problem lies in the way a float or double is represented so when you multiply by 100 expecting to move the decimal place a couple of places then get the integer part, you don't always get the expected result. In calculators, they use bcd (binary coded decimal) to get around this problem, and it seems to work. The thing with the strings might work.

Hope you get it working.

This is getting more interesting by the day! "Lay of the land" is my favorite surveying term! All kidding aside, I wrote the dms function because it was part of a horizontal curve solver program for land surveying. I wrote the function w/o the extra + 1.e-6 tacked on and checked a lot of conversions on my HP-48 calculator. I did not always get the correct results. I showed the dms function to a former CS professor and she suggested I add the + 1.e-6. All of the conversions were correct then. If anyone would like the dd function or the horizontal curve solver program please let me know. I'll be happy to post it!

Originally Posted by JacquesLeJock

and checked a lot of conversions on my HP-48 calculator.

This is interesting. I do exactly the same thing. When in doubt, I get out the 48!

Also, I wish I had a CS professor to confer with. Lucky guy.

Originally Posted by Salem

If you want to maintain accuracy, then you need to read the value into a better data structure (not a float) in the first place.

Just because you can lazily read 36.5212 into a float doesn't mean it's the right thing to do.

Code:

struct posn {
  int deg, min, sec;
};

Then carefully pick apart you input to assign 36, 52 and 12 to the respective members of the struct.

Good advice, thanks Salem. I do very little programming with floats. I only tested the program on three values, so anyone running it should give it a lot more testing and make the changes mentioned above.

Thanks again Adak and also Salem for your posts.