Comments URL: https://news.ycombinator.com/item?id=14263923

Points: 1

# Comments: 0

Marginally related: on cs.CL the other day was "Punny Captions: Witty Wordplay in Image Descriptions"[0]. A mashup of these two projects would bring us that much closer to the dream of Social Media In A Box.

[0] https://arxiv.org/abs/1704.08224

Importantly, if you remove the restriction of the input list being "exactly 256 items", then the method is still quadratic.

A linear-time algorithm for this would copy each input character exactly once, which is effectively what the method based on array.tostring() does.

The chunk size of 16 is not as significant as the technique of constructing+concatenating chunks, although it is optimal for input length 256. In general I think you'd want a chunk size about the square-root of the expected input length, to minimise the number of copied characters.

EDIT: maths

Concatenating strings of length M and N is linear in O(M+N), because that's how many characters you're copying.

Number of characters copied if you construct a string of length N by concatenating one character at a time

  = (0+1) + (1+1) + (2+1) + (3+1) + ... + ((N-1)+1) + (N+1)
  = (N +1)*N / 2

  = (0+16) + (16+16) + (32+16) + ... + ((N-16)+16)
  = 16*(0+1) + 16*(1+1) + 16*(2+1) + ...
  = 16 * (N/16 +1)*(N/16) / 2
         ^^^^^^^^^^^^^^^

Note that you also have the cost of constructing the chunks each time, which becomes the dominant cost if you have too many chunks.

In general, if you have a length kM string which you construct from k chunks of length M, the number of characters copied

  = M * (k+1)*k / 2  +  k * (M+1)*M / 2

BTW: dodecahedron is the solid object, dodecagon is the 12-sided polygon. D&D style dice as currency would be pretty awesome but it might make it difficult to resolve dilemmas using pocket change.

Almost seems (too? as a consequence?) that he was lacking a type of curiosity, whether as an existing character trait, or something that developed from having to periodically use all his wiles to obtain the means of survival when surveilling the cabins.

Comments URL: https://news.ycombinator.com/item?id=13874483

Points: 16

# Comments: 3

Certainly! Synthesis rather than reformatting (or, more commonly, regurgitation). Analysis and abduction are more than just "put it in your own words". More useful too.

There is something of a rush on at the moment to generate chat-bots to replace FAQs. Every Slack/Fleep/Blern/Crank channel appears to have five or six memoisation bots. Seems to be largely a solved problem!

When we can start having bots that can be sensibly interrogated for a summary (or even a "hey, you've been away for several hours: here's the key points"), we can finally abandon the chatrooms and let the generative bots flood them with abductive content, and the precis bots can then ping you every couple of weeks when something important comes up.

If instead we use abductive inference, we might seek the simplest and most likely explanation given our universe of observations. Sherlock Holmes was a big fan of abduction!

Much of real-world reasoning is abductive to a greater or lesser extent. There is a well-known joke about some motley band of engineers, logicians, mathematicians, statisticians, etc etc catching a train through the Highlands. They see a black sheep, the engineer says "look, all sheep in Scotland are black!", the statistician says "no, you can't say that – just that MOST sheep in Scotland are black", another says "no, we can only say that at least ONE sheep is black", another says "no, it's only black on at least one side", then the one you're stuck next to at the party says "you're all wrong, we can only say that at least one sheep in Scotland is black on at least one side at least some of the time". The last statement is fully deductive; the rest of them are abductive, and more-or-less useful.

That said, RMS's stuff is showing up in a few posts today, and framing as a moral issue is certainly a large part of his standard toolkit. Considering any situation from an ethical viewpoint tends to make my eyes roll and skin crawl (ooh, the moral dimensions of public hygiene? yes please!), but appealing to hearts and minds is pretty basic old-school rhetorical technique.

If nothing else, coming from a technical background, it's occasionally useful to come at the problems from a different, squishier, direction.

The whole presentation was plagued by gremlins; the substance begins with Sönke Iversen's part of the talk around 13:45.

JPEG comments exist for the same reason that EXIF tags exist – it's handy to store metadata alongside the image data, it gets copied around when the file gets copied, the tags can be transferred if the image gets re-encoded. There are enough error recovery mechanisms built into browsers that one could likely make a polyglot by just abusing the data segment, maybe even while crafting a legitimate standards-compliant JPEG.

Ultimately, bytes are bytes! Interpreting them with a variety of content types can give a variety of results, so keep it in mind.

[0] Resynchronisation / recovery from bit errors is one of the explicit motivations behind the design of Unicode encodings, so the browsers get a pass from me on this one. It's almost certainly possible to craft a suitable JPEG using legitimate code points anyway.

I don't see any reason to include parsing directives in JSON either, but it's a wild world out there and people do all sorts of strange things. Seems that a few of those folks were working at Yahoo and made the mistake of letting Doug see their code when JSON was in prototype phase, so no JSON comments for anyone. Whoops!

Now of course there are statutory "radiation leakage" limits in most markets. One might easily imagine that engineers would take a few goes at implementing the Ezy-Look-Into oven sketched by the folks over at industrial design, measure the emissions levels with thinner wire screens, and shrug it back with several binders full of readings. When experiment and theory are in disagreement, the product manager is unlikely to fund too much research into picking apart Maxwell's Other Equations. Given the known configurations for "good enough" microwave shielding, presumably the design team gets to sign off on a suitable colour instead of insisting on mechanically-etched glass impregnated with nanowires.

I think the idea here though is that the underlying terrain has scooted around a bit in the last twenty years, so a new datum would save on the need to print new maps and update the databases containing trig points and such. New coordinates can be labelled as explicitly aligned to the new datum, get some versioning happening.

Unfortuately it seems impossible to confirm this, because the Geoscience Australia website does not appear to make any reference to this purported new effort that's been making the rounds of late. New website layout, maybe their CMS is broken.

I don't think though that Niantic have much of a moral hazard to consider here. Looking at what's purchasable in the Pokémon store, there's nothing that would be attractive to anyone who was able to virtually wander the world at all hours from the comfort of their couch, especially since anything that can be bought with cash money could be obtained using coins earned in-game. If a player's motivation in spoofing was to "catch 'em all" by whatever means necessary, it seems unlikely that they'd draw the line at restocking from Pokéstops along the way.

Comparing with the dark side of Ingress, there is a ludicrously well-organised black market economy offering purchases for every in-game commodity – all, of course, completely against the T&Cs, all completely abhorred by legitimate players, but all offered with consummate professionalism (think of the slick ransomware scammers offering a support number). Niantic don't see any of that cash. It is likely to have had a major impact on their design decisions for the PoGo store, and the game in general. If, for instance, there is no way to trade items between players, then it severely limits the options for a parallel economy.

The two major categories of cheatifying in Ingress are falsifying one's location and multi-accounting. There's precious little that can be done about the latter, so Niantic focus on banning players that appear to be "spoofing" their location.

Given the wealth of different devices and playing scenarios, immediate detection of GPS spoofing is infeasible. Things like WiFi router locationing idiocy (or even just dodgy GPS antennae) play havoc with the utopian dream of perfect positioning every time. If a player performs actions seconds apart that are separated by thousands of miles then the game temporarily ignores them, but after some time in the naughty corner they can resume play.

Hardy spoofing detection instead depends on longer-term profiling. Ingress has a similar API to Pokémon Go – JSON chunks (rather than protobuf) over HTTPS, most fields out in the open – but each request from the app includes a monolithic "clientBlob" containing device characterisation. The format of this has been (presumably) reverse-engineered by a few hardy souls but it is certainly closely-protected Niantic knowledge. We could safely assume that it's a proprietary blend of signal strengths, gyroscope readings, touch events and timings, secret herbs and spices etc.

The clientBlobs lend themselves to offline processing. There are conceivably servers continuously trawling through a backlog looking for tell-tale patterns of bad behaviour, but it also provides an audit trail if a particular player is suspected of spoofing. Occasionally Niantic indulges in mass purges, which presumably follow from a new cheat detection heuristic being run on all the collected data for some period. These "ban waves" have a reputation for penalising unusual device configurations (the most recent major wave appeared to target, amongst other things, players with modified Android variants that might mask GPS falsifying code, including cheaper Chinese knock-offs, and Jolla phones running Sailboat).

Occasionally during major Ingress gaming events – so called "XM anomalies" – there is some level of human supervision to quickly identify and remedy clearly-fraudulent player behaviour, but for day-to-day operations it seems that account termination, so-called "hard bans" and shorter-lived "soft bans" are entirely automated, and based on offline player data analysis.

Getting back to the New Cruelty: the clientBlob was not part of Ingress's initial implementation; for a while after it was introduced was ignored, and then it became mandatory. A similar opaque chunk of data is included in the Pokémon Go requests, so we should look forward to its imminent deployment when Niantic scrape together enough Pokécoins to buy a few new servers for batch processing. At that time these convenient APIs won't have long to live.

Comments URL: https://news.ycombinator.com/item?id=11914606

Points: 2

# Comments: 0