OT: This Swift thing

[Chris Angelico]

On Fri, Jun 13, 2014 at 3:04 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Chris made the argument that *the laws of physics* put limits on what we
> can attain, which is fair enough, but then made the poor example of speed
> limits on roads falling short of the speed of light. Yes, speed limits on
> roads fall considerably short of the speed of light, but not because of
> laws of physics. The speed limit in my street is 50 kilometres per hour,
> not because that limit is a law of physics, or because cars are incapable
> of exceeding 50kph, but because the government where I live has decided
> that 50kph is the maximum safe speed for a car to travel in my street,
> rounded to the nearest multiple of 10kph.
>
> In other words, Chris' example is a poor one to relate to the energy
> efficiency of computing.

The point isn't so much the legal or safe limit as that that's the
speed of most driving. That is to say: Around here, most cars will
travel at roughly 50 kph, which is a far cry from c. There are other
reasons than physics for choosing a speed.

> Take three numbers, speeds in this case, s1, s2 and c, with c a strict
> upper-bound. We can take:
>
> s1 < s2 < c
>
> without loss of generality. So in this case, we say that s2 is greater
> than s1:
>
> s2 > s1
>
> Adding the constant c to both sides does not change the inequality:
>
> c + s2 > c + s1

As long as we accept that this is purely in a mathematical sense.
Let's not get into the realm of actual speeds greater than c.

> Subtracting s1 + s2 from each side:
>
> c + s2 - (s1 + s2) > c + s1 - (s1 + s2)
> c - s1 > c - s2
>
> In other words, if 250mph is larger than 150mph (a fact, as you accept),
> then it is equally a fact that 250mph is closer to the speed of light
> than 150mph. You cannot possibly have one and not the other. So why do
> you believe that the first form is acceptable, but the second form is
> nonsense?

And at this point the calculation becomes safe again, and obvious
common sense. (Or alternatively, substitute Mach 1 for c; it's not a
hard limit, but there are good reasons for staying below it in
practical application - most airliners cruise a smidge below the speed
of sound for efficiency.)

> If I were arguing that there are no engineering limits prohibiting CPUs
> reaching Landauer's limit, then you could criticise me for that, but I'm
> not making that argument.
>
> I'm saying that, whatever the practical engineering limits turn out to
> be, we're unlikely to be close to them, and therefore there are very
> likely to be many and massive efficiency gains to be made in computing.

And this I totally agree with. The limits of physics are so incredibly
far from where we now are that we can utterly ignore them; the limits
we face are generally engineering (with the exception of stuff
designed for humans to use, eg minimum useful key size is defined by
fingers and not by what we can build).

ChrisA