I have a database of gps coordinates in the format below.
177508867:34660765
177508977:34660701
177508895:34660777
These are displayed in the OEM software as below
S 32 13.9235, E 115 50.8867
S 32 13.9299, E 115 50.8977
S 32 13.9223, E 115 50.8895
Does anyone recognise the format and know the formula for converting them to get the shown result.
A couple years ago I posted the example above in a forum(I can't remember where) and someone recognised it immediately and posted the formula.
Since then I had a catastrophic hard drive failure and lost my project and the explanatory notes.
Thanks in advance,
Simon
Answer was provided to me from another forum a couple of days ago.
Split the numbers at the colon.
First number is the Easting or Longitude, second is the Northing or Latitude.
Subtract the Northing number by 54,000,000 and divide by 600,000.
Subtract the Easting number by 108,000,000 and divide by 600,000.
Multiply the decimal by 60 to get the decimal minutes.
Thanks to Andre.
Related
Is this the 1 billionth ugly/hamming number?
62565096724471903888424537973014890491686968126921250076541212862080934425144389
76692222667734743108165348546009548371249535465997230641841310549077830079108427
08520497989078343041081429889246063472775181069303596625038985214292236784430583
66046734494015674435358781857279355148950650629382822451696203426871312216858487
7816068576714140173718
Does anyone have code to share that can verify this? Thanks!
This SO answer shows a code capable of calculating it.
The test entry on ideone.com takes 1.1 0.05 sec for 109 (2016-08-18: main speedup due to usage of Int instead of the default Integer where possible, even on 32-bit; additional 20% thanks to the tweak suggested by #GordonBGood, bringing band size complexity down to O(n1/3)).
It gives the answer as ((1334,335,404),"6.21607575556559E+843"), i.e.
21334 * 3335 * 5404 ≈ 6.21607575556559 * 10843.
(coincidentally, only two last digits in the fractional number above are incorrect).
This also means, of course, that there are 404 zeroes at the end of this number, and that it has 844 digits in total. So no, the number you show isn't it.
Exact answer:
6216075755565244861630816332872072003947056519089652706591632409642337022002753141824417540777256732780370172616615291935540418620025524916729500086831454711313694078635504004160312872951788703647948382456091072701600790562071797590306654765882256990391763887850141154482249915927439184562828227449023750262318234797192076792208033475638322151983772515798004125909334741121595323950448656375104457026997424772966917441779406172736975588556800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Can someone explain this question?
What is decimal value of the sum of the following 5-bit two's complement numbers? 10010+10101
Two's complement numbers are added together by doing binary arithmetic.
10010 +
10101 =
00111
Like normal numbers you carry the digit to the next place if you hit two ones at the same time while adding.
To interpret two's complement numbers, you have to understand that the first bit represents a value of 2^0, the second 2^1, the third 2^2, the fourth 2^3. This pattern extends for 32 and 64 bit numbers naturally. The final bit in 5bit two's complement represents -2^4.
Multiplying these values with the bits we came up with we have:
-0*2^4 + 0*2^3 + 1*2^2 + 1 *2^1 + 1*2^0
This value is 4 + 2 + 1 = 7. If we looked at the decimal value of 10010 we'd see its equal to -2^4 + 2^1 = -16 + 2 = -14. 10101 comes out to -11.
So the computer is saying that the sum of (-11) + (-14) is 7. This is because of overflow where we ignored the fact that the final bit should have had a 1 carry over into the next column. Giving a finite representation this is the best we can do.
The overflow is characterized by a bunch of neat properties since the representation we have is an Abelian group, a mathematical construct. It's outside the scope of the question but you should certainly understand them. Just google overflow.
Also, most answers are going to be curt since it's a basic topic that google could solve and StackOverflow gets enough questions as is. Make sure to check google and search StackOverflow before asking questions!
10010=2^4+2^1=16+2=18
10101=2^4+2^2+2^0=21
22+18=39
^=power
Here is my question :
If we have the following value
0.59144706948010461
and we try to convert it to Single we receive the next value:
0.591447055
As you can see this is not that we should receive. Could you please explain how does this value get created and how can I avoid this situation?
Thank you!
As you can see this is not that we should receive.
Why not? I strongly suspect that's the closest Single value to the Double you've given.
From the documentation for Single, having fixed the typo:
All floating-point numbers have a limited number of significant digits, which also determines how accurately a floating-point value approximates a real number. A Single value has up to 7 decimal digits of precision, although a maximum of 9 digits is maintained internally.
Your Double value is 0.5914471 when limited to 7 significant digits - and so is the Single value you're getting. Your original Double value isn't exactly 0.59144706948010461 either... the exact values of the Double and Single values are:
Double: 0.5914470694801046146693579430575482547283172607421875
Single: 0.591447055339813232421875
It's important that you understand a bit about how binary floating point works - see my articles on binary floating point and decimal floating point for more background.
When converting from double to float you're also rounding. The result should be the single-precision number that is closest to the number you are rounding.
That is exactly what you're getting here.
Floating-point numbers between 0.5 and 1 are of the form n / 2^24 where n is between 2^23 and 2^24.
0.59144706948010461... = 9922835.23723472274456576... / 2^24
so the closest single-precision floating-point number is
9922835 / 2^24 = 0.5914470553...
I have a value range, say the iPhone screen size 480x320. I have a position that may be outside the range, let's say the position's x coordinate is 600 for example.
In order to adjust the x coordinate to its on-screen position I can do: 600 - 480 = 120
But when the value is greater than two times 480 I'd have to run a loop, subtract 480 until the resulting number is below 480.
I know there's an optimization to this problem revolving around division/modulo but I just can't find a good answer (or question) related to this. Mainly because I can only guess possibly helpful search phrases.
I'm feeling sick today and for the live of me I can't wrap my head around it. I'd welcome any pointers, even a "close as duplicate".
PS: this is for Objective-C but any language will do.
You are looking for the modulo operator. The solution for the case of a width of 480 is:
x % 480
Modulo will guarantee that the resulting value is between 0 and 479.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Trouble with floats in Objective-C
I have broken this problem down to about as simple as i can get it. Feel free to try the same thing and tell me if you get the same error and what solution you might have. I have already tried it on several computers.
float total = 200000.0f + 154196.8f;
NSLog(#"total: %f", total);
The output is:
total: 354196.812500
If anyone has any sort of logical explanation, feel free to share it.
I'd suggest you brush up on your floats
http://www.altdevblogaday.com/2012/05/20/thats-not-normalthe-performance-of-odd-floats/
If you need higher precision use a double.
Additionally http://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2/
See What Every Programmer Should Know About Floating-Point Arithmetic for all the deep understanding. The short answer is that all floating point representations have limitations on their precision, and that things that can be expressed in a small number of digits in decimal may not be expressible in a small number of digits in binary (and specifically not in floating point formats).
Note that while double can improve things, it is no panacea. It is quite common to have small rounding errors, even with double. You may easily get 1.99999999 when you expect 2.
Hint:
long double total = 200000.0 + 154196.8;
NSLog(#"total: %Lf", total);
On my machine prints the correct value.
A 32 bit floating point has a 23 bit mantissa, the closest value is 0.5+0.25+0.125.
You should use more bits to get the correct representation.