jasondavies

The "doubt" seems to have been refuted here:

http://motls.blogspot.cz/2012/11/superstringy-compactificati...

Ah, good. The title is meant to be an homage to the original source of the idea.

My Spanish is somewhat rusty so I didn't know it also meant boss. :)

Thanks, it should handle resizing better now.

I hadn't realised this before making it, but one interesting pattern is that the number in between twin primes is always abundant, if greater than 6.

It's reasonably simple to prove using the fact that every twin prime pair except (3, 5) is of the form (6n − 1, 6n + 1).

Great tip for using Perl/Python-compatible regex syntax:

  nnoremap / /\v
  vnoremap / /\v

This will save me a lot of time. Thanks, Steve!

It also reminds me of http://www.jasondavies.com/hamming-quilt/ where the Hamming distance is used.

See http://www.jasondavies.com/wordcloud/ for a version that uses JavaScript and canvas for bitmap-based collision detections.

I've updated the colours now, is that better?

Older Android versions don't support SVG (used to render the axes), but it should work in Ice Cream Sandwich.

Got inspired and it now supports Float64Array. :)

For sorting numbers, you might also want to look at Radixsort.js, which takes O(n) time, although it isn't in-place like quicksort:

https://github.com/jasondavies/radixsort.js

I haven't finished implementing the Float64Array version, but it beats everything else I've compared it with even for relatively small sizes e.g. my benchmark is 65,536 floats and it's already around 2.5x faster than native sort (using Node.js)! Admittedly, Float32Array vs. native sorting of 64-bit floats is not a fair comparison, but you could argue that many applications would get away fine with 32-bit floats anyway. :)

Seems to be working fine for me.

I occasionally get gzipped data back from Wikipedia (even though I explicitly set Accept-Encoding in the proxy) - I think it's due to their intermediate caches not respecting the Vary headers. I plan on adding gzip support soon to rectify this, but until then, you can get around it by adding ?foo to the end of the custom URL.

Thanks!

Yeah, I'll definitely try the randomised greedy algorithm when I get time, I think it should be fairly straightforward now that I have the sprite collision primitives in there.

No problem at all if you want to reimplement in another language, the license is BSD: https://github.com/jasondavies/d3-cloud/blob/master/LICENSE

I'm guessing it will be blazingly fast using the bitwise operations in C/C++. :)

Thanks!

Yes, I've thought about using invisible silhouettes, which presumably is how http://www.tagxedo.com/ works. The placement algorithm might be a bit different though, perhaps starting at the centroid of available areas and so on. I think it would work better to have a smaller pool of words and allow reuse, or alternatively they could be sized randomly (perhaps with some weighting).

The sprite collision code could certainly be reused for this, though!

Thanks!

Minor correction: I implemented hierarchical bounding boxes separately, as per Jonathan Feinberg's paper, but they turned out to be slower in all the cases I tried (even large words and areas). I was also using a quadtree to cut down the number of comparisons with previously-placed words.

In my version, once a word is placed, I copy it to the relevant position in a large sprite representing all the words placed so far. So placing a new word means it only needs to be compared with the candidate area of the large sprite, rather than multiple comparisons with all previously-placed words.

I'd like to try a hierarchical sprite version, where you compare against coarse-grained sprites first of all. This would essentially be a quadtree. The implementation would be a bit trickier because I'm also compressing blocks of 32 1-bit pixels into 32-bit integers, which also helped with performance.

I think this is destined to eventually replace their plugin-based version at http://maps.nokia.com/ - at least for WebGL browsers.

Presumably this is a precursor to replacing their 3D plugin version at http://maps.nokia.com/ - at least for browsers that support WebGL.

It uses a stereographic projection: http://en.wikipedia.org/wiki/Stereographic_projection

I think what you're referring to is also known as stereoscopy.

Original paper (no paywall): http://obs.rc.fas.harvard.edu/turnbaugh/Papers/Reshef_Scienc...

If you don't have Silverlight you can probably use:

mms://proedvid.stanford.edu/videocontent/knuth/musings/111208/111208-knuth-500.wmv

It seems to work in mplayer.

Cool, I might add this to bloomfilter.js if I get a chance: https://github.com/jasondavies/bloomfilter.js

Even at a rate of 1 name per second, this would take almost 11.5 days to read out all the names non-stop. Is there some kind of time limit for this kind of thing?

The other possible clue is that they seem to have added "The challenge continues" to the home page sometime in the last few days e.g. see http://www.guardian.co.uk/media/2011/dec/01/gchq-computer-ha... for how it looked on or before 1st Dec.

That's an interesting idea. Unfortunately it looks like you can comply with all the rules in his banks section by having an 8-digit password, which is conveniently the number of digits in a birth date.

So presumably they don't currently optimise for mutual incompatibility. Quick, file a patent. :)

Wow, this is amazing! Much more detailed than my own interactive Bézier curves demo:

http://www.jasondavies.com/animated-bezier/

Computing Bayesian network probabilities using BDDs sounds interesting. Are there any references for this, or do I have to wait in suspense for the lecture? :)

Looks like they're using some kind of sunflower phyllotaxis for placement. Especially obvious when you zoom in.

Ported to HTML5 canvas: http://www.jasondavies.com/animated-quasicrystals/

Finally, SVG support for Android handsets!

See this long-standing issue: http://code.google.com/p/android/issues/detail?id=1376 where their stated reason for leaving out SVG was to save 1MB of space in the WebKit image size.