Re: Tutorial: Query the Apple database with Python for your access point BSSID
Paul <[email protected]>
| Newsgroups | alt.comp.os.windows-10,alt.internet.wireless,alt.comp.microsoft.windows |
|---|---|
| Organization | A noiseless patient Spider |
| Message-ID | <[email protected]> |
On Thu, 12/18/2025 4:43 PM, Winston wrote: > Marian <[email protected]> posted both: >>> Longitude: -93.81759643000001 > ... >>> Longitude: -93.81759643000001 > > and: >> Does anyone have any idea why the highly insecure Apple WPS database >> contains GPS entries to this illogically numerous set of decimal places? > > Probably just the result of a 64-bit (double) floating point calculation > that they didn't bother to round off. > -WBE > It could be a closest-representable-number problem. You should really code a thing like this up. Use the GMP library to do the multiply of mantissa and exponent part. I've only used this once, and not for floats. You can code for C or C++ and doing it in C++ is slower (for the temporary copies of numbers the code makes, and when there are a lot of digits in play). The C++ code is easier to read (unlike the C you write in that case). https://en.wikipedia.org/wiki/GNU_Multiple_Precision_Arithmetic_Library You're right, that the double looks like a reasonable candidate to contributing to the problem. Just need a better calculator to see how close it is to an exact representation. https://gregstoll.com/~gregstoll/floattohex/ -93.81759643 Single Mantissa ExponentContribution 0xc2bba29b 1.465899825 0961304 64 ? 0xc2bba29c 1.465899944 30542 64 ? 0xc2bba29d 1.465900063 5147095 64 ? Double Mantissa ExpC 0xc05774537ffa0b48 1.465899944 2187497 64 -93.81759642999998 0xc05774537ffa0b49 1.465899944 21875 64 -93.81759643000000 <==== need more careful conversion 0xc05774537ffa0b4a 1.465899944 2187501 64 -93.81759643000001 1.4658998250961304 * 64 = \ 1.46589994430542 * 64 = \___ Need a calc that takes that many digits 1.4659000635147095 * 64 = / to verify the single precision representation "?" My Microsoft "calc" gives "Invalid Input". ******* It's sloppy workmanship :-) We knew that much before investigating. If your input numbers coming from somewhere are eight digits after the decimal, then the tool output should also be eight digits or so. Printing that many extra digits is silly, as the database collecting these numbers, isn't "doing math" on them. It is just storing a GPS coord as reported (from NMEA message) and puking it back out on demand. Paul