Home
Beware of the Train [entries|archive|friends|userinfo]
pozorvlak

[ website | My Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| My moblog Hypothetical, the place to be My (fairly feeble) website ]

Modularity and the Schlemiel the Painter problem [Jan. 5th, 2008|10:32 pm]
[Tags|, , , ]

Suppose we have an algorithm whose performance (in some axis) is worse than linear - quadratic, say. The example that I'm thinking of is concatenation of lots of strings using the Schlemiel the Painter algorithm. Suppose we want to perform this calculation on a lot of data. The best thing to do, of course, is to find a better algorithm or some way of reducing the amount of data we need to consider, but that's not always possible. There's another general technique that's often helpful in situations like this: we split the data up into smaller chunks, perform the calculation for each chunk separately, then combine the results. For the Schlemiel example, suppose we want to concatenate mn strings, and that this will take k(mn)^2 steps. We split it up into m blocks of n strings, concatenate each block, and then concatenate the results, for k(m^2 + m(n^2)) = km(m + n^2) steps, an improvement on the original. We could improve further by chopping it up again, and again, until we end up with a trivial problem. I remember working this technique out for myself a few years ago (while trying to do exactly this - in my defence, I was constrained by available libraries). I felt almost as pleased with myself as I did when I discovered bubble sort for myself at the age of ten or eleven - we live and learn...

Anyway, I claim that this is what we're doing when we write modular code.

It's received wisdom that bug count grows more than linearly with number of lines of code - I've heard quadratic growth quoted, which makes some sort of sense since bugs often arise from unforeseen interactions between different bits of code, but I think that's maybe a bit excessive. So we can apply the analysis above to the process of writing software. "Choosing a better algorithm" might correspond to using a better development process, like XP or something, or maybe using some technique that makes the bug rate lower (test-driven development, strong typing, formal QA process, take your pick). Reducing the amount of data corresponds to, well, writing the program in fewer lines. But these aren't always possible, so we're back to chopping the data up into smaller pieces. Which we do, obsessively (if we're any good at all, that is). We split up applications into processes. We split up programs into modules. We split up modules into subroutines. We split up state into objects. All the time, we're fighting the super-linear behaviour of bug count: by keeping each part small, we reduce the number of bugs in each part; and the sum of bugs in the parts plus the bugs arising from unforeseen interactions between parts should be less than the number of bugs that would have been included if we'd written the program all in one chunk.

Of course, this isn't the only reason we write code modularly: modularity allows for code reuse, which reduces the amount of code we need to write (technique 2), and eliminates copy-and-paste bugs (technique 1). But I think good programmers write code that they never intend to reuse in a modular fashion anyway, and the reason they're doing this is, fundamentally, because they're optimising for low bug count by splitting up their data into chunks.
link2 comments|post comment

A thought [Nov. 17th, 2007|08:15 pm]
[Tags|, ]

You can't spell "patriot" without "riot".

You can't spell "team" without "tea", either...
link6 comments|post comment

Debugging teddies [Oct. 11th, 2007|11:21 am]
[Tags|, , ]

Perhaps you've had this experience:

You have a problem, which you've bashed your head against for ages. You can't see what to do about it. Finally, you decide to ask a friend, or email the lecturer, or put it up to your boss, or whatever. You get hold of him/her, and start explaining your problem. But by the time you're halfway in, the very act of explaining your problem forces you to clarify it in your own mind, and the solution becomes obvious to you. You drift off, mid-sentence. "Sorry," you say, "I've just seen what to do. Sorry to bother you."

Your friend was acting as a debugging teddy. The term comes from a university computer room back in the Dark Ages of computing which kept an actual teddy bear for this purpose: you were required to explain your problem to the teddy before you were allowed to ask an actual human being. At the startup where [info]totherme and I used to work, we had a talking Yoda doll. But Master Yoda wasn't so good, precisely because he could talk and not just act as a sounding-board for your own thoughts: at one point, Management discovered that Master Yoda had been making major architectural decisions, and replaced him with a life-size cardboard cutout of Buffy the Vampire Slayer.1

1 She had business cards and everything. "Buffy Summers, [company] Ltd. Pensions Advisor (stakeholder)".
link11 comments|post comment

Stop! Health and Safety! [Sep. 9th, 2007|11:57 pm]
[Tags|, , ]

Another sketch idea.

CIVILIAN is attempting to do something perfectly normal and unobjectionable: drink a cup of tea, or put a stamp on a letter, or tie his shoelaces. Enter JOBSWORTH.

JW: Oi! You can't do that here!
Civ: What? Why not?
JW: Health and Safety. You could [suffer totally ridiculous accident] and then we'd be liable.
Civ: That's totally ridiculous!
JW: Health and Safety.
Civ: Who came up with that rule?
JW: I can't tell you that. Data Protection.
Civ: Look, I'm just trying to [drink my tea/etc]. I'm not going to hurt myself, or sue anyone. Why can't you let me carry out this perfectly ordinary action in peace?
JW: Health and Safety. We can't go around making exceptions for everyone.
[Enter Man in Black, speaking in ringing voice, poss. with American accent.]
MiB: Stop! Agent Mogridge, HSE. [shows badge]
JW: HSE?
MiB: Yes, the Health and Safety Executive: making the world a healthier and more safeful place. I'm here to tell you that there is absolutely no Health and Safety justification for this ridiculous rule. You, sir, are sullying the good name of Health and Safety when you falsely invoke it as a weapon in your petty war of vengeance against Humanity. You are a disgrace to the office you hold, and the organization you represent. [Turns to CIVILIAN. Gracious.] Allow me to apologise for this cretin. You may drink your tea, Sir, and may God smile on your endeavours.
[CIV drinks the tea, and suffers precisely the accident that was predicted. This should be as large and physical as possible, involving comic pratfalls, slips, running off stage with killer bees in hot pursuit, etc.]
[Beat.]
MiB: Oooh, nasty.
link9 comments|post comment

Theatrical remix [Aug. 29th, 2007|12:19 pm]
[Tags|, , , ]

Thought for a sketch, to be performed near the end of a show:

A guy walks on, looking/acting like a DJ. He walks over to a set of decks at the side of the stage, pulls out some records, inspects a couple, puts one on. Another actor walks on and starts performing part of one of the previous sketches. The DJ shakes his head and takes the record off. The second actor exits quickly. The DJ selects another record and puts it on. I'm sure you see where this is going... actors come on and start performing another sketch. The DJ's digging this, and starts headbanging slightly to a beat only he can hear. He starts scratching the records, with a predictable effect on the actors ("You can't get a colon ZZZRP can't get a colon ZZZRP can't get a WAKAWAKA colon pregnant, darling"). Then the DJ takes out another record, and starts mixing... the dialogue from the two (three? more?) previous sketches is layered together, Arcadia/Play on Words-style, revealing new and unexpected hidden comedic meanings. Or possibly just makes no sense, but in a comedic manner.

[Theatre 2.0?]

Of course, the fun really starts when he takes out the record labelled "DJ sketch"...
link8 comments|post comment

Type warnings [Aug. 19th, 2007|12:09 am]
[Tags|, , , , , , , , ]

Here's something that occurred to me the other day: consider ( duck-typed languages like Python )

OK, so far so standard. Now, most duck-typed languages are dynamic, which means that we only try to determine if bar has a spoffle method at runtime, and die with an error message when it doesn't (possibly after trying some error recovery, e.g. by calling an AUTOLOAD method or similar). But it occurred to me that in simple cases (which is to say, the majority), we could work out most of this stuff statically. For each function definition, see what methods are called on its arguments. Recurse into functions called from that function. Now, each time a function is called, try to work out what methods the arguments will support, and see if that includes the interface required by the function. Issue an error if not. Thus we get the code reuse benefits of duck typing, and the correctness benefits of static checking. If the static checking is slowing down your development cycle too much, drop back to fully dynamic checking, and only run the static checks on your nightly builds or something.

This also cleared up something else I'd been vaguely wondering about. In his splendid Drunken Blog Rant Rich Programmer Food, Steve Yegge says
Another problem is that they believe any type "error", no matter how insignificant it might be to the operation of your personal program at this particular moment, should be treated as a news item worthy of the Wall Street Journal front page. Everyone should throw down their ploughshares and stop working until it's fixed. The concept of a type "warning" never enters the discussion.
I'd wondered at the time what a type warning would mean. When is a type error mild enough to only warrant a warning? Here's one idea: a type warning should be issued when it cannot be proved that an argument to a function implements the interface that function needs; a type error should be issued when it can be proved that it doesn't.

This all seemed very interesting, and struck me as potentially a fun and reasonably easy hacking project, at least to get something workable going. But if it's occurred to me, it has probably occurred to someone else, so I asked the Mythical Perfect Haskell Programmer if he was aware of any work that had been done on static duck-typed languages. "Oh yes," he said, "O'Caml's one." Buhuh? Really? Well, that's O'Caml moved a couple of rungs up my "cool languages to learn" stack...
link23 comments|post comment

Weighty matters [Jul. 25th, 2007|11:36 pm]
[Tags|, ]

I've put on about a stone and a half in the last couple of years (that's about 20lb to the USians, and 10kg to the SI-users), and it's having all the usual negative effects - half my trousers don't fit any more, there are whole classes of stretches that I can't do any more because the fat gets in the way, and, worst of all, my mother's started commenting on the size of my tummy every time I go and visit. So I decided it was time to lose some weight now before it gets any worse - we tend to run to fat in my family.

Partly on a recommendation from someone ([info]johnckirk?) but mostly because I liked the name, I read John "AutoCAD" Walker's free book The Hacker's Diet ("How to lose weight and hair through stress and poor nutrition!"). I've found it interesting and entertainingly-written, though much of it's undoubtedly old hat to a lot of you. Anyway, here's a ( summary )

It all sounds pretty sensible and straightforward to me. The real test, of course, is whether I'll manage to stick to it, lose the weight, and then keep it off. As Larry Niven reminds us, in one of the corollaries to his seventeenth law, telling friends about your diet won't make you thin, and buying a diet cookbook won't either. But I have the boundless optimism born of total lack of experience.

Apologies in advance to the Two Shaders: I will undoubtedly be rather tiresome on this subject, and hopefully I'll be stinky and halitotic to boot :-)
link33 comments|post comment

Internal and external martial arts [Jul. 25th, 2007|03:55 pm]
[Tags|, , , , ]

One of the more useful ways of classifying martial arts is into external and internal, sometimes known as hard and soft. External martial arts (like karate and taekwondo) emphasize the actual mechanics of punching and kicking (or blocking, or throwing, or grappling), whereas internal martial arts (like aikido and tai chi) are more abstract, focusing on things like listening, blending, and the flow of energy (chi, or ki, or ache, or ... if it helps, remember that this isn't energy in the physicist's sense, but something else with the same name. Like the physicist's energy, it's an abstract, derived concept, but that doesn't mean it isn't useful). I'll quote [info]totherme here:
Of course tai chi is a martial art - the energy abstraction exists to facilitate martial application - but we learn it for its own sake - like learning to add numbers rather than learning to add apples. Apples are a great example, but they miss the point - if you add numbers then you can add bananas too :)
I've studied just enough martial arts to be extremely wary of making broad generalisations, so I'll hedge a bit and say that the ultimate aim of most established martial arts is to produce internal martial artists, which is to say those who intuitively understand the concepts taught by the internal styles (or possibly the deeper concepts behind them - the Tao that can be named is not the true Tao, of course). The difference is in the approach, and the stations you pass through on the way. Hard styles present you with a series of examples of correct technique, and leave you to deduce the underlying principles yourself; soft styles try to teach you the principles, and leave you to work out many of the fine details. Both approaches can produce both internal martial artists, and extremely effective fighters - believe it or not, tai chi can be very dangerous in experienced hands! It's notable that many arts seem to evolve towards internality as they age - karate's thought of as an external style, but it's much more internal now than it used to be. This progression is clearest in the history of aikido, which developed towards being an internal style as its founder progressed towards being an internal martial artist.

This distinction can be useful to bear in mind as an analogy. You sometimes hear mathematicians talk about "hard" and "soft" geometry, which strike me as similar in some ways to hard and soft martial arts - hard geometry has lots of coordinates, lots of differential forms, lots of linear algebra, whereas soft geometry is more abstract and topological. [info]totherme and I were discussing our respective ways of thinking about programming a while ago, and found this helpful in reaching some understanding: whereas the training I've received has all been about how to do specific things, his CS degree has taught him more explicit versions of what I (sometimes, unreliably) do in my head - things like proof of code correctness by invariants. Internal versus external, in other words - the Oxford CS course attempts to do the Tai Chi thing to hacking.

This is also one way of looking at category theory (I think this makes Attempt To Explain My Thesis No. 3...). An awful lot of modern pure mathematics is implicitly categorical, but this can be hard to see because the details get in the way. Category theory attempts to extract the deeper principles from a large variety of techniques, and make it explicit, so it becomes easier to learn them (or work them out on-the-fly). Actually, this is how mathematics works in general: by identifying the implicit principles that underly things and making them explicit so you can think about them in their own right, thus (hopefully) making the original problem easier.
linkpost comment

Starting points for thought [Jun. 26th, 2007|02:29 pm]
[Tags|, , , , , , ]

The APL Lesson: If all your problems can be solved with short programs, it doesn't matter how hard it is to write or maintain long ones.

Smith's (First) Law: Any sufficiently large test suite for a program written in a dynamic language will contain an ad-hoc, informally-specified, bug-ridden, slow, patchy implementation of half of the Haskell type system.

Yegge's Axiom of Size: Large systems suck. This rule is 100% transitive. If you build one, you suck.
link23 comments|post comment

Computers are useless; they can only give you answers [Jun. 12th, 2007|02:43 pm]
[Tags|, , , ]

Here's something that's been bugging me for a while: why are computers useful?

A bit of an odd question, you might think, and I'm going to need to explain some background. First, you need to know that there are problems that computers can't solve, even in principle. A classic example is the halting problem: given a program and its input, can you predict whether or not the program will terminate? Alan Turing showed that it's impossible to write a program that will do this correctly in all cases. A co-worker of mine was once asked to do precisely this by a client...

Next, you need to know a bit about infinity, and ( the surprising behaviour of infinite sets )

Armed with this knowledge, we can see that Turing didn't need to exhibit an actual example of an uncomputable problem: he could have shown that some problems are uncomputable much more easily. Consider the following problem: you have some subset X of the natural numbers. X might be the set of even numbers, or the set of prime numbers, or the set of perfect numbers, or the set of Fibonacci numbers, or something like that. You want to write a program which will accept a number as input, and output "Yes!" if the number is in X, and "No!" if not. Now, by a close relative of Cantor's diagonal argument, there are uncountably many subsets of the natural numbers. But every program in your favourite programming language is a finite sequence chosen from an alphabet of finitely many symbols, so there can only be countably many programs! Hence, there must be some subsets X for which there is no such program. [I'd like to thank Jeff Egger for introducing me to this argument]. In fact, it's much worse than that - if you were to pick a subset at random, the probability that it would be computable would be 0. Not 1%, or 0.01%, or 0.000000001%, but actually zero. You need to be quite careful about how you define probability for this statement to make sense, but it's true. [Edit: having discussed this with an actual analyst, it turns out the truth is more complicated than I'd thought. There may be reasonable ways to define the probability measure on the space such that the probability of computability is non-zero. However, there is at least one way of defining a probability measure such that my statement is true - see my reply to [info]benparker below.]

This seems like quite a contrived and artificial problem, but it's not really: lots and lots of useful problems can be re-stated in this form, with a judicious choice of X. We're not worried about how efficient the solution would be, only that one exists; hence, if the "subset of N" form of the problem is incomputable, so was the original form.

Hence my original question: why are computers useful? If the probability of a computer being able to answer our questions is zero in theory, how come they are so useful in practice? My former colleague aside, most of us don't need to worry about computability in our day-to-day coding: we can pretty much assume that there is a solution to our problem, and that finding it is the hard part.

I don't really know the answer, but it seems to me that it must have something to do with approximations. We're finite creatures, and we're usually happy with finite answers - we'll approximate an infinite decimal to one with ten (or thirty, or five hundred, or at most a few billion) decimal places, we'll just ask for the first few elements of an infinite sequence, we'll approximate the movement of continuous fluids by thousands of discrete chunks, and so on. This can lead to errors and problems, but usually these can be dealt with or lived with. Also, since we're finite, we're only capable of creating a finite amount of data for our computers to search through and manipulate. If we restrict the problem above to finite subsets of the natural numbers, the picture becomes a lot better: now there are only countably many subsets to choose from. We might still have probability zero, but it's not enforced in the way it was before.

In practice, as I said, the probability of their being a useful computable approximation to our original problem seems to be near to 100%. This strikes me as something close to miraculous. Is this just a mirage? Do we not encounter uncomputability because we subconsciously shy away from it, just as 19th-century scientists largely failed to notice the ocean of nonlinearity that they were swimming in? Or are the computable functions somehow dense in the uncomputable ones, in the way that the (countable) rational numbers are dense in the (uncountable) real numbers?
link31 comments|post comment

What juggling has taught me about relationships [Apr. 24th, 2007|02:51 pm]
[Tags|, , ]
[music |Cpl Joshua Belile USMC - Hadji Girl]

I used to think that relationships were like teapots. Not, as [info]wormwood_pearl suggested to me when I first mentioned this to her, because good things come out of them: nor because they start out hot and gradually cool down. No, I thought relationships were like teapots because when you first get one, it's perfect and whole, but then you drop it, and it gets damaged. Maybe you can glue the bits back together and have something that works for a bit, but it's never quite as good as it was before - the cracks show, you've almost certainly lost a few crucial shards of china under a cupboard somewhere, and the glue isn't as strong as the china was. The teapot now leaks, and gets damaged much more easily; and each time it gets damaged, it's harder to put back together. Eventually, you have to face up to the fact that your much-loved teapot is now a Frankenteapot, unsuitable for either use or decoration1. I remember once reading that Communism had "collapsed under the weight of its internal contradictions"2 - that's the kind of idea I'm getting at. As your teapot/relationship continues, you accumulate more and more damage, and eventually the whole thing falls apart, and probably gets scalding hot tea on everyone.

Under this model, successful relationships arise from
  1. Starting off with a really good teapot.
  2. Being very very careful not to drop it.

Then I learned to juggle. You might think that the same approach would work for juggling patterns:
  1. Get a clean start.
  2. Don't screw up.
But in fact it turns out that this doesn't work. In simple terms, it's impossible not to screw up. Nobody (and certainly not a beginner) throws perfectly straight. Juggling is about feedback: you're constantly watching the pattern for deviations from the ideal, and correcting those deviations. The difference between juggling well and badly is that the good juggler makes smaller mistakes, corrects those mistakes faster, and can correct bigger mistakes than the bad juggler. In fact, you learn to be actively suspicious of "good starts" - you need to be able to get a bad start and recover from it. So it is with relationships. The skill is in watching for things going wrong, and fixing them as soon as possible before they become big problems. Experience will improve your ability to spot problems and your ability to fix them.

The trouble is that in order to be a good juggler, you need to drop. A lot. Charlie Dancey, in his Encyclopedia of Ball Juggling, suggests that "jugglers form only a small percentage of the world's population, but they are responsible for most of the world's drops". Sadly, this too seems to be true of relationships: the experience you need to fix problems will largely come from what turned out to be failed test runs. This is why the "stay with your first love for the rest of your life" model seems so unrealistic to me - it's like handing someone three balls and expecting them to produce a solid cascade on the first go. It does happen, but it's vanishingly rare.

What you need to keep going, in love as in juggling, is the hope and belief that this time will be the time when it comes together. And when it doesn't, the patience to pick the balls up and try again.

1 I in fact have a teacup decorated with wonderful cartoons by Mr Scruff, that I've dropped and glued together at least three times. It was my favourite mug for a long time, but it's now so fragile that it's essentially useless.
2 Googling, I see that the phrase is pretty widespread, and has been applied to pretty much any regime the writer doesn't like.
link30 comments|post comment

While I'm talking about philosophy.... [Apr. 9th, 2007|08:53 pm]
[Tags|, , , , , , ]

I'd like to talk about a couple of simple thought experiments invented by the mathematician and philosopher Gottlob Frege, which for me really nail the relationship between mathematics and the physical world, and at the same time raise some fundamental questions in the philosophy of mathematics.

Suppose you have a vessel containing 2cc of liquid. To this, you add a further 3cc of liquid. How much is in the vessel now? Well, 2+3 = 5, so obviously it's 5cc. But the liquid you added wasn't the same as the liquid that was in there: the two underwent a chemical reaction, emitting some gas, and so the volume of the liquid in the vessel is actually less than 5cc. Or suppose you have five things, and you then add two more half-things. You've got six things, right? Except the "things" were pairs of boots, and the half-things were individual boots, but both individual boots were left boots. You have twelve boots, but only five pairs.

In both cases, you have some physical system (liquid in a vessel, pairs of boots in a rack) that you're trying to model using some mathematical formalism (whole numbers and addition, fractions and addition). In each case, it turns out that the model isn't a very good one, as it incorrectly predicts the behaviour of the system. But this doesn't mean that 2+3 is not equal to 5, or that 5 + 1/2 + 1/2 is not equal to 6! Nor does it mean that there's no mathematical model that would fit - in both cases, it would be pretty easy to construct one. It just means that we've chosen the wrong models. Standard arithmetic still works fine, it just happens to be the wrong thing in this case.

( SCIENCE! )

( PHILOSOPHY! )

Frege's story's rather a sad one, as it happens. He did pioneering work in the philosophy of language and in logic (he's got a solid claim to be one of the three great logicians of all time, along with Boole and Aristotle, and without his work much of modern mathematics would be literally unthinkable). In 1903 the culmination of his life's work, the Basic Laws of Arithmetic (Grundgesetze der Arithmetik), was on the verge of publication: in it, he claimed to show that arithmetic (and thus all of mathematics) could be derived from the obvious truths of logic. As it was about to go to press, he received a letter from Bertrand Russell informing him of what is now known as Russell's Paradox. This blew the entire enterprise out of the water. Frege inserted a preface to the effect of "This doesn't work any more, but I hope you find it interesting", then went off and had a nervous breakdown.

1 If you can get hold of a copy of his (sadly out-of-print) Foundations of Arithmetic, I strongly recommend it, if only for the chapter contra Mill.
link6 comments|post comment

Sliding Definition Ploy [Apr. 8th, 2007|03:15 pm]
[Tags|, , , , , ]
[music |Four Tet - everything ecstatic]

Closely related to the No True Scotsman fallacy is Sliding Definition Ploy1. It goes like this: "for the sake of argument", give a slightly-odd definition to some common term, like Mind, or Freedom, or Justice, or Beauty. Deduce some consequences from that definition (ideally, this stage should take a while, to overflow your audience's input buffers). Claim that these deductions tell you something about the ordinary meaning of the term you started with. Better yet, don't claim it; just proceed as if they do.

SDP is, unfortunately, endemic to philosophy, or at least was when I last took a look. In philosophy, one of the big problems is that all the really interesting ideas you want to talk about (Truth, Justice, Ethics, Vision, Desire, the Soul, Mind, Body, even simple things like "looking"2) are ill-defined. The other big problem, of course, is that you can't do experiments on most of these things (even if you're the sort of philosopher who believes we can trust our senses and the sort who's prepared to accept the validity of the scientific method, which is by no means all of them). So you're left with pure reasoning. Mathematicians can get away with relying on pure reasoning, because they're working with abstract things that are precisely defined. Sorta3. So, in order to get any traction at all on their problems, philosophers often have to provide definitions of common terms. This allows the unscrupulous philosophers4 to insert a Sliding Definition Ploy or two.

SDP is also common in arguments about politics: we're all in favour of Liberty, Justice, etc, but these terms are all ill-defined, and by choosing definitions carefully, it's easy to show that your opponent is opposed to any given Good Thing. [info]zompist has written more about this in one of his rants, in which he also elaborates on the linguistic problems with definitions.

There are lots more standard logical fallacies: Wikipedia has a list (Googling will reveal several others), and here's infidels.org's guide to logic and fallacies, which also has what looks like a good section on what logic is, what it isn't, and what it's useful for.

[By the way, I am no longer eating salted porridge. I am now about to tuck into a sausage sandwich. An organic venison sausage sandwich, no less, filled with sausages from the farmers' market at Queen's Park yesterday :-) ]

1 The term is due to John Puddefoot, AFAIK.
2 I know a philosopher who recently wrote a paper on the difference between "looking" and "watching". Or possibly "watching" and "seeing". Or something like that. It's subtle stuff.
3 At the risk of being accused of SDP myself, this is probably the best definition of mathematics we have.
4 A depressingly large subset, from what I can see.
linkpost comment

The No True Scotsman fallacy [Apr. 8th, 2007|03:14 pm]
[Tags|, , , , ]
[music |Four Tet - everything ecstatic]

Happy Easter, everybody! Today, I'm going to talk about two of my favourite logical fallacies. This post got a bit long, so I've split it into two: the second part, about Sliding Definition Ploy, is here.

My favourite, for the name if nothing else, is the No True Scotsman Fallacy1, which canonically goes like this:
Hamish: No true Scotsman puts sugar on his porridge.
Jock: But my cousin Angus MacAlasdair from Glen Coe puts sugar on his porridge.
[Beat.]
Hamish: No true Scotsman puts sugar on his porridge.
[We're assuming that Angus MacAlasdair's Scottish nationality is above reproach, apart from his unnatural and perverted breakfast habits.]

( Discussion and further examples )

By the way, porridge really is a lot tastier with salt on it. In fact, I'm eating some salted porridge now. Mmmm...

1 That's its name. Really!
link8 comments|post comment

Ten things I hate about Perl [Mar. 13th, 2007|01:08 pm]
[Tags|, , , , , , ]

brian d. foy says that you can't be an effective advocate for a language unless you can think of five things that you hate about it off the top of your head, the reason being that if you can't, then you don't know enough about the language to advocate it effectively. So, just to go one (or five) better, here are ( ten things I hate about Perl )
This is not to say that I hate Perl: far from it. I think it's a wonderful, fun language, with a great community around it, producing some insanely cool software (CPAN might be considered the world's premier laboratory for module and language-extension design). I am continually surprised that Perl has such a bad press, and gets such short shrift from the language-design community. You might expect that a language that breaks almost every accepted precept of language design would simply be a bad language, and no fun at all to use. Yet Perl does this, and has a fanatical community of users, some of them truly excellent hackers. This, it seems to me, is a datum point of enormous importance.

But anyway, I'd like to ask this question to the hackers reading this. What five things do you hate most about your favourite language?

* Unless you've set $[ to 1 - thanks, [info]paddy3118!
link19 comments|post comment

Amo, amas, amat [Mar. 13th, 2007|11:54 am]
[Tags|, ]

Here's a thought that struck me the other day: Latin, like Sumerian before it, endured as a scholarly and priestly language for hundreds of years after people stopped speaking it as an everyday tongue. Will English go the same way? Will the people of 2500 (or even later) be forced to learn this weird language, full of exceptions to rules and superfluous vocabulary, in order to do science and business internationally (or even interplanetarily)? Or is English's place in the sun only a brief flicker, like the dominance German enjoyed over science in the late 19th and early 20th century? And if so, what will replace it? The two leading candidates are Chinese and Hindi, I'd imagine...
link21 comments|post comment

Three random thoughts [Feb. 14th, 2007|12:33 pm]
[Tags|, , , , , ]

Cut for length, but only the second point is esoteric - the rest should be accessible to anyone. And the first contains a big Neal Stephenson quote, which should raise the standard of writing in this post above my usual average :-)

[Oh, and I'd like to mention [info]wormwood_pearl, who this morning gave me the Best V********'s D** Gift EVAR, by doing all the washing-up in the flat :-) ]
link5 comments|post comment

The Incredibles [Feb. 4th, 2007|11:35 am]
[Tags|, , ]

What's your favourite incredible fact?

The background to this question is as follows: Philipp I went to the mountains yesterday with a visiting Australian mathematician called Geordie. It was one of the best days we've had in the mountains - great conditions (though it may be time to abandon the winter trousers for the season), beautiful views, pleasant company and some fascinating discussions about mathematics*. On the train on the way back, we started discussing the question above, although being mathematicians we phrased it as "what's your favourite incredible theorem?"

I think it's an interesting question, and I'd like to throw it open to the floor. You may like to contribute theorems, but you don't have to: for instance, one of my favourite incredible non-mathematical facts is that traffic congestion can increase if you build more roads (even without an increase in total traffic volume, IIRC). Or how about "The Universe is nearly 15 billion years old, and contains around 10^23 stars"? That's pretty damn incredible, when you think about it.

By the way, our favourite incredible theorems were

Geordie: for n != 4, there is exactly one differentiable structure on R^n. For n = 4, there are uncountably many.
[Or: there exists a surjection from R to R^2 - the famous Peano curve being an example]
Philipp: I can't remember, even though he's just told me again. Something to do with coverings and Baier measure, whatever that is.
Me: there exists a countable model of ZF set theory. In other words, there's a universe of "sets" that satisfies all the usual axioms of set theory, but only has countably many objects.

Incredible, no?

* The only slight downside was that I'd been out for a romantic meal at the Shish Mahal with [info]wormwood_pearl the night before, and I'd made the schoolboy error of drinking five pints and then ordering the vegetable paal. For those of you who don't eat Indian food much, paal dishes are typically too hot to feature on menus, and I had to ask for this one specially. It was so hot. As Philipp put it when he tried some later, it was "hot beyond Good and Evil". After a couple of mouthfuls, even breathing became painful, as the air flowing over my palate re-ignited the chilli thereon. I managed about a third of it, and had to ask for the rest to be bagged up.

It was fantastic :-)

Though I have to agree with [info]wormwood_pearl, in that it's better to think of it as a relish for other dishes than a dish in itself. Currently it's in the freezer, frozen into very small portions... anyway, my digestive system coped remarkably well, but I was still feeling a bit iffy the next morning on the train.
link11 comments|post comment

Business plan [Jan. 15th, 2007|04:54 pm]
[Tags|, ]

One for all you chemists out there (er, so that would be [info]adqam, then).

1. Invent a process for making industrial sapphire really cheaply.
2. Market the sapphire to manufacturers of mp3 players, PDAs, phones, laptops, etc - hey presto, scratch-proof gadget screens!
3. PROFIT!!!!!
link5 comments|post comment

Paradigm shifts and the Malayan Emergency [Jan. 12th, 2007|02:20 pm]
[Tags|, , , , ]

I'm currently half-way through a fascinating book called The Utility of Force by the retired general Rupert Smith. I'll blog about it at greater length when I've finished it, but for now, here are a couple of IITESKAs to warm up:

( Paradigm Shifts )

Now, this next bit is way outside my area of expertise, but here goes:

( The Malayan Emergency )
link13 comments|post comment

navigation
[ viewing | most recent entries ]
[ go | earlier ]