Talk:Implementations/Archive 1

Missing Historical Data

There is a good chance that no one cares, but the reference Geohashing Coordinate Calculator will not work for several valid dates. I think some just havent been copied from the previous day, but some may have just been missed. I've put a list of those dates up, delete it if you'd like. --ZorMonkey 14:20, 24 May 2008 (UTC)

FunkyTuba regenerated the data, using a more complete source, so there shouldn't be any more days missing. Do let me know if you find more. Zigdon 08:34, 26 May 2008 (UTC)

xkcd.com/geohashing Problems?

Hey - I can't get to [1], and none of the graticules' maps are working - is this just me, or the rest of the world, too?

Yes, irc.peeron.com is currently down (as of 20080523 11pm PDT), I know, I'm trying to get hold of someone who can do something about it. Zigdon 07:29, 23 May 2008 (UTC)

Why is the the xkcd.com/geohashing redirecting to irc.peeron.com anyway, shouldn't it be moved to xkcd? I think too many active graticulees are melting the server. --Opspin 08:07, 23 May 2008 (UTC)

it's working again!

Difference between the comic and the generator

Zigdon, xkcd:

The hash in the comic for 2005-05-26-10458.68 starts with db9318........

Here's debugging info for the map page's calculation of http://irc.peeron.com/xkcd/map/:

Graticule: (37, -123) - (38, -122)
Market open on 2005-05-26 = 10458.68
MD5(2005-05-26-10458.68 ): 357e5cac889681628fdd754c1a235919
Split: 357e5cac88968162, 8fdd754c1a235919
offset = 0.20895938122029104, 0.5619729338451526
37.20895938122029 -122.56197293384515

On my machine: $ md5 -s "2005-05-26-10458.68"
MD5 ("2005-05-26-10458.68") = db9318c2259923d08b672cb305440f97

Any idea what's going on here? Is that an extra space on the end there, Zig?
--FunkyTuba

   I've found a bunch of opening values at http://irc.peeron.com/xkcd/map/data/
   with carriage returns on the end, which I dont think were being stripped out before
   hashing. The website went down before I could fully confirm though.
   --ZorMonkey 11:49, 23 May 2008 (UTC)

That was indeed the case, fixed now. Zigdon 14:07, 23 May 2008 (UTC)

bug in reference implementation

The reference implementation is biased against results in the .0..., .0... range. This seems to be because the code that converts a hash string to a fraction stops dividing as soon as the remaining characters are all false (zeros.) This division should probably happen a fixed number of times, instead. 76.121.107.210 17:26, 21 May 2008 (UTC)

Good catch, fixed Zigdon 18:18, 21 May 2008 (UTC)

Great! I also noticed another issue with the perl script -- the page you're retrieving the DJIA value from does not currently have the value for today, so the script is accidentally using the value for yesterday instead. this page is not currently showing a value for 5/21, which the script expects to be there. 76.121.107.210 20:04, 21 May 2008 (UTC)

True - the cron job on the server doesn't get the data from that page, so it's not an issue there. For the sample.pl, perhaps I'll edit it to use a different page if you're trying to load the coords for today. -- Zig. 159.153.4.51 05:15, 22 May 2008 (UTC)

The comic is also a bit vague about exactly how the hex value is converted to a decimal value. One would assume from the description that the hex value is simply converted straight to decimal (FF -> 255) and then appended to the lat/lon coordinates; the reference implementation, however, shows that the hex number is instead converted as a decimal fraction (0.FF -> 0.99609375). This latter approach inherits all of the accuracy problems inherent in converting between decimal and hex/binary fractions. Can't do much about that now except whine, I guess. Ooh, and a cheese platter? Mine's the chunk of reggiano parmesan, thanks. -- gnomon

Yes, the comic states you take the hex as a fraction. Not 'abcdef' but '0.abcdef'. What accuracy problems? you can describe any number between 0 and 1 to the nearest 1/2**16. That translates to about 5 feet or so? Or am I missing something? Zigdon 23:54, 22 May 2008 (UTC)

Actually, that would be 1/(16^16) for 16 fractional hex digits, which translates to something on a microscopic scale. --Tim P 22:18, 23 May 2008 (UTC)

"I'm sorry, our measurements show you missed the meetup by one ten-thousandth of an angstrom."

"Only because I was moved when you measured me!"

--Xkcd 16:36, 24 May 2008 (UTC)

Cookie/Bookmark?

Is it possible to set one's browser to always start at a certain point when viewing the geohash calculator? The first time I visited it (when I was at home in Berkeley), it started out zoomed to my home graticule. Now that I'm at my parents' (in Los Angeles), it defaults to the Boston graticule. I don't know if this is something to do with our respective internet providers or if something has changed with the mapping program, but it would be great if there were an option to default the map to the current view (whatever that may be). If there's already something that I'm missing, someone can just enlighten me. Thanks!!! Darcy 02:15, 26 May 2008 (UTC)

Yes, that would be useful. Done. Zigdon 06:56, 26 May 2008 (UTC)

Awesome, thank you! Darcy 16:24, 26 May 2008 (UTC)

Mapping tool appears borken (5/25/2008)

My test case:

Go to Mapping tool.
Zoom out a few, to see the US West coast.
Center-up on Santa Cruz (if you don't know where that is, use San Francisco.)
Zoom in a few, to get a nice view.
Press UPDATE button. (Btw, I'm on Safari, on Mac OS-X/Leopard-latest.)

EXPECTED: A map-pin and coordinates that you can review. ACTUAL: Pin & coordinates flash for a brief moment, then map recenters on Boston, with information gone.

NOTE: Things all worked fine yesterday and the day before (5/23-24.)

Aside: Is there a "bug reporting system", or is this it? :)

Thanks! Ted 18:55, 25 May 2008 (UTC)

I can't seem to reproduce this in FF or Safari on OSX 10.4.11. Does safari have a javascript error console where it might be logging the error? Zigdon 19:10, 25 May 2008 (UTC)

As far as bug reporting, this is one way, a better was is to come into IRC and talk to me there. Go to http://mibbit.com, select "foonetic" from the pulldown server, and #geohashing for the channel. Zigdon 19:10, 25 May 2008 (UTC)

The Perl reference implementation

I've been playing with the Perl reference implementation, and as I'm in Australia, I found it annoying to deal with its poor 30W capability. So I "fixed" it. Perhaps.

<snip> I updated the sample.pl to have a '-e' flag. If you run it with it, it will report the values according to the 30W rule:

$ ./sample.pl 2/1/08
Downloading DJIA from google: http://finance.google.com/finance/historical?cid=983582&startdate=Jan+25,+2008&enddate=Feb+01,+2008
DJIA opening for 2008-02-01 is 12638.17
Date: 2008-02-01, DJIA: 12638.17
MD5(2008-02-01-12638.17): 917a4419e1345e42569bad9fa5ef5a17
Split: 917a4419e1345e42, 569bad9fa5ef5a17
Fractions: 0.5682718814070582, 0.3383129610792229

$ ./sample.pl -e 2/1/08
Adjusting for 30W
Downloading DJIA from google: http://finance.google.com/finance/historical?cid=983582&startdate=Jan+24,+2008&enddate=Jan+31,+2008
DJIA opening for 2008-01-31 is 12438.28
Date: 2008-02-01, DJIA: 12438.28
MD5(2008-02-01-12438.28): ec6464f6d4d0da51c0c8fe874be8601c
Split: ec6464f6d4d0da51, c0c8fe874be8601c
Fractions: 0.9234068968406207, 0.7530669288934475

Zigdon 21:36, 26 May 2008 (UTC)

Thanks --Psud 10:58, 27 May 2008 (UTC)