Interesting Links for 21-06-2017

[andrewducker]

Edinburgh's Ross Bandstand designs shortlisted

(tags: design music edinburgh )

A Neural Network Turned a Book of Flowers Into Gorgeous Dinosaur Art

(tags: dinosaurs plants ai pretty )

Amazon Prime Wardrobe lets you try on and return clothes free

(tags: Amazon clothing )

Older fathers have geekier sons

(tags: geek age fatherhood children )

Sherlock's Mark Gatiss and Steven Moffat to get their teeth into Dracula

(tags: Dracula tv StevenMoffat bbc )

The story of music is the story of humans

Are there any other animals that dance? Because "song" seems reasonably common in some senses, but rhythm seems specific to humans
(tags: music humans prehistory )

I had never heard of deck prisms. Ingenious idea.

And copied cheaply in poor areas nowadays using a plastic bottle full of water
(tags: lighting history glass Technology )

Gangs of aggressive killer whales are shaking down Alaska fishing boats for their fish

(tags: fish sharks usa )

The Philosophy Force Five vs the Scientismists

(tags: comic science philosophy funny )

Maze converted to Spanning Tree (nice visualisation/animation)

(tags: visualisation animation trees )

She May Be The Most Unstoppable Scientist In The World

(tags: yemen women science war )

If people can see an immediate payoff they'll take it, even if it means they make less in the long term

(tags: money psychology games information )

It's reading posts like this that make me feel much more secure in my competence as a programmer

I remember a job interview where the interviewer handed me a page of printout from halfway through a program, and asked me to explain it. I said "Well, this is a loop, and it's doing something with a 'salary' variable, and calculating tax in some way, but it's calling off to a function that's not on this page, so I'm not sure what. I'm sorry, I can't tell much more than that, what am I missing?" And they said "You're the fourth person I've interviewed for this coding job, and the first one who wasn't lying about being able to program."
(tags: programming fail OhForFucksSake )

Man sent home from work for wearing shorts in over 30°C heat comes back in a dress

(tags: clothing gender heat )

The world's oldest still-used bridge

(tags: architecture history bridge greece )

US Supreme Court Says You Can't Ban People From The Internet, No Matter What They've Done

(tags: usa law freespeech internet )

Queen's Speech summary: Bill-by-bill at a glance

(tags: politics uk Conservatives )

Comments

[jack]

I think that's the important thing. Knowing that an associative array is O(ok) and looking through an array is O(terrible) is the amount of knowledge you need in practice.

Most programmers never need to actually design an algorithm of this sort.

[simont]

Knowing that an associative array is O(ok) and looking through an array is O(terrible) is the amount of knowledge you need in practice

And don't forget the third clause, that looking through an associative array is O(godwhatareyouevendoing).

[jack]

:)

I wonder what the worst factors of unnecessary overhead are. There's plenty of examples of being O(n^2) when you could have been O(n) (surprisingly easy to do). And of being O(n) when you might be (1) as in these examples (when you really should notice something amiss).

I was also wondering if anyone's accidentally written a random-indexing (ie. generate a random number, if it's the desired index continue, else repeat), although that wouldn't have a worse complexity than a loop for a single index, even though it's clearly worse.

[simont]

A colleague of mine spotted a bug yesterday in a piece of test automation, in which a specification of a list of test cases had contained some tiny easy-to-miss lexical error (I forget exactly what, but something along the lines of putting an operator inside rather than outside a critical pair of parens) and as a result two long sublists of test cases had been fed to the Cartesian product operator instead of the concatenation operator.

It was only two lists being combined, fortunately, but the same sort of typo could just as easily have done the same thing to n lists, which would have turned a more or less linear amalgamation into an exponential one.

(Though I suppose the worse it gets, the more likely you are to actually notice when you investigate why the test system seems to be spending forever running indistinguishable variants of the test suite in question. Perhaps the real limiting factor on this question is not 'how egregious a consequence can you imagine for a trivial code error?' but 'how egregious a consequence can you imagine going undetected for some reason?'.)