tfm

The idea is to reduce the amount of redundant copying of characters: you end up doing a few more concatenations in the outer loop, but the concatenations in the inner loop are of short strings.

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

Number of characters copied if you construct a string of length N by concatenating a chunk of length 16 each time

  = (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
         ^^^^^^^^^^^^^^^

This is where the "technique" comes in: although the algorithm is still quadratic you're effectively moving a constant factor out the front.

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

... which (rounding and integer constraints aside) is minimised for M = k, i.e. when the chunk size is the square root of the input length. Hence, for input length 256 we take chunk size 16.

Yes, but with the caveat that you'll be running interpreted .py using a cross-compiled Python executable, rather than Python compiled to Android bytecode. Kivy itself (the project that spawned p4a) is a full cross-platform library for UI development; for any heavy computational lifting you'd want to farm it out to a C API library and import it the usual way, modulo some p4a recipe incantations.

Fortunately the domain name is rather less ambiguous and primed me for the weak pun. I'm ... glad(?) that the wordplay survived the marketeering sessions and civil service vetting.

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.

The bit that really stood out for me: """ He was never once bored. He wasn’t sure, he said, that he even understood the concept of boredom. """

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.

> This is why I think the ability to ask good questions is a better indication of understanding and intelligence than the ability to generate answers.

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 we're limiting ourselves to deductive reasoning, then yes – the facts as stated do not give enough information to deduce that Greg must be white.

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.

In this particular case it could be argued that Google's unofficial "don't be evil" motto explicitly framed this as a moral issue. Tongue-in-cheek, to be sure, but certainly an appeal to happy squishy emotions.

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.

Lena handled it very gracefully. She gives a very quick synopsis of what her part of the talk would have been around the 41 minute mark.

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

Inasmuch as there is blame to be apportioned in this case, it's due to JavaScript / ECMAScript having broad definitions of acceptable variable names, and (arguably[0]) the fact that browser JS implementations will generally accept arbitrary 8-bit data within multiline comments, rather than the strict Unicode code units specified by ECMAScript.

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.

Alas, there's no guarantee that the order of key/value pairs within an object will be preserved (not even within JS anymore!). But that's okay, we can always reformat the ordered data as an array or write a custom parser ... oh.

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!

Perhaps it was determined by trial and error! Or maybe the earlier oven iterations happened to get lucky. We don't know that embedding a flyscreen on the door of the food chamber was necessarily the look that people would have gone for!

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.

Official local datum is GDA94, which is usually within about a metre of WGS84. /me pats pocket protector

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.