home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.sys.mac.advocacy      Steve Jobs fetishistic worship forum      120,937 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 119,373 of 120,937   
   Marian to Alan Browne   
   Re: Apple trolls like Alan Baker are so    
   20 Dec 25 13:48:52   
   
   XPost: misc.phone.mobile.iphone   
   From: marianjones@helpfulpeople.com   
      
   Alan Browne wrote:   
   > On 2025-12-19 10:40, candycanearter07 wrote:   
   >   
   >> Never trust a float for anything that requires precision.   
   >   
   > Silly statement.   
   >   
   > If you understand the structure of the float (IEEE 754) as implemented   
   > in your programming language and OS then analyzing the _resolution_ of   
   > the floating value and the resultant _precision_ of the result (2 things   
   > that many programmers ignore) then float is fine for many (if not all)   
   > things requiring precision.   
   >   
   > As I stated in another post, Python (and many C) programmers seem quite   
   > lazy in this respect and so liberally use 64 bit float where 32 would   
   > do.  Or even 16.  So much excess resolution pretty much guarantees   
   > conservation of information in most cases with a reasonably large number   
   > of operations.  (akin to having a 500HP engine where 200HP is much more   
   > than adequate).   
   >   
   > A key point is understanding the effect of operations on the _precision_   
   > of an operation and the order of operations on variables and the result   
   > that conserve information and _precision_ and not merely _resolution_   
   > which itself is a characteristic of the "instrument" (in this case CPU   
   > registers and memory and not a guarantee of _precision_ in the result).   
   >   
   > Implementing precision operations as integer values with some assigned   
   > resolution to LSB (say: LSB = 0.001 metres) is NO different if the order   
   > of operations is not carefully designed to conserve actual _information_   
   > in a sequence of operations.   
      
   To keep this thread on the concept of answering WHY Apple's precision is   
   what it is when they store my BSSID (or anyone's BSSID) in their highly   
   insecure yet very public easily accessed WPS database, I'm not disputing   
   Alan Browne's explanation of floating-point behavior or the distinction   
   between resolution and precision.   
      
   My main point about Apple's highly insecure yet very public WPS database is   
   much narrower and has nothing to do with whether Python uses 32-bit or   
   64-bit floats, or whether IEEE 754 is appropriate for numerical work.   
      
   What I am showing is simply the raw form in which Apple stores these   
   coordinates in the WPS database. The database uses ten-digit integers that   
   convert into latitude and longitude values with several decimal places.   
   That is the precision of the stored data, regardless of whether the   
   underlying measurements are accurate to that level.   
      
    Enter the BSSID (or q to quit): 00:18:f8:c1:4a:65   
      -----------------------------------------------   
      === Lookup started at Sat 12/20/2025  4:18:02.21 ===   
      BSSID: 00:18:f8:c1:4a:65   
      
      Searching for location of bssid: 00:18:f8:c1:4a:65   
      
      BSSID: 00:18:f8:c1:4a:65   
      Raw latitude integer: 3245990371   
      Raw longitude integer: -9381384277   
      Latitude (degrees): 32.459904   
      Longitude (degrees): -93.813843   
      
      BSSID: 02:aa:a0:e3:5f:38   
      Raw latitude integer: 3245890808   
      Raw longitude integer: -9381494903   
      Latitude (degrees): 32.458908   
      Longitude (degrees): -93.814949   
      
      BSSID: 44:1c:12:99:23:58   
      Raw latitude integer: 3245909881   
      Raw longitude integer: -9381492614   
      Latitude (degrees): 32.459099   
      Longitude (degrees): -93.814926   
       ... and so on ...   
      
   The technical question I am raising is why an access point that is both   
   hidden and marked nomap appears in the database at all. To any precision!   
      
   The number of decimal places is not the main issue, although it could be   
   indicative of how the system works by knowing WHY it's what it is.   
      
   The main privacy issue is that the access point was collected and stored   
   despite explicit opting out signals not to include it. That is a privacy   
   concern, not a floating-point concern.   
      
   I am focusing on the behavior of the database and the implications for   
   users who expect nomap and hidden SSIDs to prevent this kind of collection.   
      
   The integer format and the float conversion are just the mechanism that   
   reveals the underlying data; they are not the core of the problem I am   
   pointing out. address it directly.   
      
   Despite Alan Baker ridiculing the precision, it is what Apple made it to   
   be. So what we need to understand is WHY Apple made it to what it is.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca