Both childish and unethical, of course, but I thought the “slogans” themselves were kind of amusing.  So, along the same lines…

VOTE FOR THE GREENS because …

… trees are people too

… the economy isn’t going to ruin itself!

… you hated your science teacher, right?

VOTE FOR LABOUR because …

… New Zealand needs more debt

… we did OK last time, right?  Right?

VOTE FOR MANA because …

… Pakeha should just bugger off

… there are too many white <expletive deleted> in Parliament

… the Greens aren’t crazy enough

VOTE FOR ACT because …

… Maori should just bugger off

… National isn’t crazy enough

VOTE FOR NEW ZEALAND FIRST because …

… we made MMP what it is today!

VOTE FOR THE PIRATE PARTY because …

… have we got the coolest name, or what?

What if they were to offer full membership subject to the condition that the Palestinians accept a UN-negotiated treaty with Israel?  Negotiations between Israel and the Palestinians have been unproductive, but negotiations between the UN and Israel need not be.  (Of course, the UN would first have to accept that the Green Line is not a particularly useful starting point, which might be politically unpalatable to many member nations.)

Any such treaty would be significantly more favorable to Israel than the Palestinian negotiators have ever been willing to consider.  They probably wouldn’t get East Jerusalem, and Israel wouldn’t be accepting the return of any refugees.  Even so, it would be a difficult offer to turn down when the prize is United Nations recognition of a Palestinian State.

Would this have worked?  Maybe not – but I don’t suppose we’ll ever know for sure.  I think it would have been worth a try.

Pot.  Kettle.  Black.

In Windows Vista and later, an application can be coded to require UAC elevation.  If you try to run it as a non-administrator, you get asked for an administrator username and password, and if you don’t provide them the application doesn’t start.  That’s all very well, but some developers set this flag when it isn’t really needed (I’m looking at you, beepa) which locks out all non-administrators.

This isn’t usually a big problem on a home machine, because you probably have an administrator account even if you don’t use it for everyday activities.  In a teaching lab, however, as in many other contexts, it’s fatal; the students don’t know the administrator password (or at least I devoutly hope they don’t!) and obviously we’re not going to tell them what it is.

It turns out that this is as simple as setting an environment variable.  Set __compat_layer to RunAsInvoker, and Windows will ignore the application manifest.  You could set this globally via group policy, or write a simple wrapper program around specific applications that need it.  (Of course, if an application really does require administrator privilege it may fail in strange and unexpected ways, so take care.)

Hope this helps – and Norbert, if you’re reading this, thank you.  Knowing about this is going to come in very handy.

(Original picture courtesy Evan-Amos, Wikimedia Commons.)

The phrase “free software” has exactly one correct grammatical meaning, and guess what, it isn’t the one the Free Software Foundation keeps on pushing.

Software can of course be free as in “costing nothing”.  [All definitions are from NZ Pocket OED, 1988.]

Can it be free as in “power of acting without constraint of necessity or fate”?  No.  [1]

Can it be free as in “not a slave”?  Well, only in the trivial sense [1] that no software is a slave, since the word only applies to people.

Can it be free as in “not under the control of another [other than the software itself]“?  Again, no. [1]

Well, I don’t want to go through the entire list of definitions (it takes up an entire column) but you get the idea.  Some of the definitions can be applied to software, such as “available to all” but they don’t match the meaning of “free software” as defined by the FSF either.

And of course using the phrase “free software” with the FSF’s meaning causes endless confusion with the (more correct) meaning of the word “free”.

So, what should we call GPL and other similarly licensed software?  My vote (so to speak) is for “freedom software”.  This isn’t exactly euphonious, but at least it isn’t confusing and it means what it says – software that supports freedom.  (Even if it seems to me to be an odd kind of freedom for people to worry about.)

The upshot is that I’ve decided to start using “freedom software” instead of “free software”.  I’m hoping it won’t be necessary to explain myself too often.  I invite you to join me.

Harry.

[1] Except for an AI, I suppose, but that’s not really the point.

I really don’t think I was being silly.  I’m perhaps not incredibly well informed on the subject matter, but well enough (I’d have thought) to have a valid viewpoint.  I certainly wasn’t trolling – I hope those on the other sites/newsgroups I frequent would agree that while I may occasionally be lighthearted, I never argue dishonestly.

My feelings are hurt, to be honest.

I’ve suggested that my comments be removed, so I’m going to put them all here instead.  If anyone can explain to me how I might have presented my opinions less offensively, please feel free to comment.  These are not chronological but in thread order.

I first ran across the doomsday argument many years ago (under another name, if I remember correctly) in the novel Manifold: Time by Steven Baxter.  It’s one of those interesting ideas – it’s obviously nonsense, but it’s very hard to pin down exactly where the reasoning fails.  At the time I think I pretty much dismissed it, but it appeared again in an online article a year or two back and I’ve been musing about it on and off ever since.  It turns out to be even more interesting than I thought, because once you do pin down the logical flaw, you realize that it depends on a metaphysical assumption.  This means that, arguably, the Doomsday Argument is the first ever experimental test of a metaphysical idea, which I find fascinating.

For those unfamiliar with the Doomsday Argument, the short version is that, using Bayesian statistics, you can take the fact that you were born now (rather than, say, a thousand years into the future) and use it to predict that the human race is almost certain to become extinct in the near future.  For more information, I’d recommend this site by Professor Nick Bostrom of Oxford University.  There is also a Wikipedia entry but personally I found it disorganized and confusing.

So where do I think the flaw lies?  Well, the DA requires you to reason like this: if the human race is not about to become extinct, what was the probability of my being born now rather than at some point in the future?  The subjective nature of this question is essential to the argument – you can’t, for example, imagine being a visiting alien pointing to someone and saying “what was the probability of such-and-such a person [or people] being born now?”.  It just doesn’t work that way.

Now, that question sounds reasonable.  But consider this: is it really meaningful to ask whether you might have been born at a different time?  What, exactly, does the question actually mean?  If somebody were born in 3000AD with your exact genetic code, would that person be you?  I argue that (s)he would not, because your experiences and memories are at least as critical to your identity as your genetic code.  Even identical twins are not the same person.

It should also be kept in mind that the chances of a person being born with an identical genetic code to you at some point in the future are unaffected by whether or not you were in fact born now.  So if you would consider a person born with your genetic code in 3000AD instead of now to be yourself, you would have to also consider a person born with your genetic code in 3000AD as well as now as being yourself.  In which case there would have been two yous.  So to speak. [1]

At first glance, this would seem to handily refute the Doomsday Argument, but there’s a catch.  What about your soul?  If we suppose that people have souls, and that these souls already exist in some sense before a person is born, then suddenly the DA works again – you can ask “what were the odds that I [i.e., my soul] would be placed in the world at this time, rather than a thousand years in the future?” perfectly meaningfully.

It is, at this point, very tempting to assert that if humanity does not become extinct in the near future that would disprove the existence of the soul.  This would however be dishonest, for several reasons: for one, my reasoning only applies if souls are (so to speak) created ahead of time, which is not necessarily the case; for another, the DA might have one or more other flaws (I believe Professor Bostrom discusses some possibilities in detail, though I must admit I haven’t actually read the book); and finally and perhaps most fatally, the DA also requires you to suppose that your soul is placed in the world at random, which I think according to most religions is unlikely to be the case.

Despite these caveats, I personally find this situation fascinating … as I may have said before.  If you’ve gotten this far without giving up in dismay, bless you, and I hope I haven’t bored you completely to tears!  My next post should be back to normally scheduled programming.

Harry.

[1] English really isn’t a very suitable language for discussing this sort of hypothesis, is it?

I’m going to use new keywords for integer variable types: int<n> to indicate a signed integer n bits wide, e.g., int32 for a 32-bit signed integer; and nat<n> to indicate an unsigned integer, e.g., nat32 for a 32-bit unsigned integer.  In mathematics, natural numbers are the positive integers, sometimes (as in this case) including zero, and I find “unsigned int” unnecessarily long-winded and abbreviations like “uint” ugly.

Making integer arithmetic safe is simple in principle and can be summed up briefly: all integer arithmetic must either produce the right answer or cause execution to stop.  I’ll leave vague exactly what “stop” means because it depends on context, but the same sort of mechanisms already used to deal with a divide-by-zero are probably suitable.

In the following example, execution will stop on the second line:

nat16 a = 65535;
nat16 b = a + 1;

Execution will also stop on the second line in this example:

nat16 a = 32767;
int16 b = a + 1;

More subtly, this also needs to cause execution to stop:

nat16 a = 32768;
int16 b = a;

Technically an assignment isn’t arithmetic, but it still needs to be safe.

We need to detect underflow as well as overflow:

nat16 a = 5;
nat16 b = a - 10;

This is a bit trickier:

nat16 a = 32768;
nat16 b = 32768;
nat16 c = (a + b) / 2;

The correct answer is 32768, which will fit into the nat16 type, but the intermediate value of 65536 won’t.  Whether you will get the right answer depends on what type the compiler uses when working out the expression.  In some cases (such as C in a 32-bit environment) the language specification will guarantee that the code succeeds; in other cases, I would suggest that the compiler be permitted to either succeed or to stop at its own convenience.  The only thing it shouldn’t be allowed to do is decide that the answer is zero.  (Unfortunately, that’s exactly what will happen with most real-world compilers!)

On occasion the programmer needs to allow an overflow to occur, so the language  should define a way to do that.  There are a number of options.  The simplest and most elegant would be to introduce a keyword:

nat16 a = 65535;
nat16 b = lenient a + 1; // b will be set to zero

One problem: this code then wouldn’t compile if the compiler didn’t know about the keyword.  Perhaps a pragma, then:

nat16 a = 65535;
#pragma lenient
nat16 b = a + 1; // b will be set to zero
#pragma strict

Yet another alternative would be to require the compiler to ensure that an overflow in an intermediate calculation won’t stop execution if the final result is still correct:

nat16 a = 65535;
nat16 b = (a + 1) & 65535;

However, I’m not sure this approach is feasible in general, i.e., for more complicated expressions.

On a side note, it might also be desirable to simplify the rules determining the types used in expressions, including a straightforward mechanism for the programmer to override the defaults.  I don’t think I should discuss that now, but I’ll try to write about it later in a separate post.

Now it is of course possible for a compiler to do all the above using the standard x86 instruction set – it just needs to check the carry or overflow flag as appropriate after each step.  Why doesn’t this happen?  Nowadays, backwards compatibility would be a problem, but presumably the original issue was performance, and I suspect this is still a concern, particularly where branch instructions would be necessary.  (The INTO instruction is presumably quite efficient, but there is no corresponding INTC instruction for unsigned arithmetic.)

It shouldn’t be too hard for the CPU to come to our aid here.  For unsigned arithmetic, I think the best approach would be introduce a separate overflow bit for each register, rather than (or as well as) having carry and overflow flags.  Writing the register to memory would trigger a software interrupt (or equivalent) if the overflow bit is set, as would using the register in any other inappropriate way.

Also, instructions for writing only part of a register to memory (the low byte, for example) should generate a software interrupt if the remainder of the register is not zero.

For example, on a 16-bit processor and using a hopefully self-explanatory syntax:

move 65535 -> a0     # register a0 is set to 65535 and the a0 overflow bit is cleared.
move a0 -> nat8 x    # write a0 to 8-bit memory location x;
                     # this causes a software exception because a0 doesn't fit in 8 bits.
add 1 -> a0          # a0 is now zero and the a0 overflow bit is set.
move a0 -> nat16 y   # this causes a software exception, because the overflow bit is set.
add a0 -> a1         # add the value of a0 to a1;
                     # this causes a software exception because the a0 overflow bit is set.

move 65535 -> a0    # a0 is set to 65535 and the a0 overflow bit is cleared.
move 65535 -> a1    # a1 is set to 65535 and the a1 overflow bit is cleared.
add 1 -> a0         # a0 is set to zero and the a0 overflow bit is set.
addc a0, 0 -> a1    # the a0 overflow bit is added to a1;
                    # the a0 overflow bit is now clear;
                    # a1 is now zero and the a1 overflow bit is set.
move a0 -> nat16 x  # zero is written to the sixteen-bit memory location.
move a1 -> nat16 y  # this causes a software exception.
clc a1              # but, if we were to clear the a1 overflow bit first ...
move a1 -> nat16 y  # then this would succeed.

Hopefully, this is clear.  There are details that need filling in, but I think nothing difficult.

Signed arithmetic is much the same, except for one edge case.  There are at least three different ways of distinguishing between signed and unsigned arithmetic; the simplest is distinct arithmetic instructions:

move 255 -> a0       # register a0 is set to 255 and the a0 overflow bit is cleared.
move a0 -> nat8 x    # this will write 255 to the 8-bit memory location x.
move a0 -> int8 x    # this causes a software exception because 255 doesn't fit in
                     # an 8-bit signed variable.  Note that this is a different
                     # instruction code to the above instruction.
adds 32767 -> a0     # a0 is now 33022 (meaning -32514) and the a0 overflow bit is set.
move a0 -> int16 y   # this causes a software exception because the a0 overflow bit is set.
move a0 -> nat16 y   # so does this.

move 65535 -> a0   # a0 is set to 65535 and the a0 overflow bit is cleared.
move 32767 -> a1   # a1 is set to 32767 and the a1 overflow bit is cleared.
add 1 -> a0        # a0 is set to zero and the a0 overflow bit is set.
addcs a0, 0 -> a1  # the a0 overflow bit is added to a1 using signed arithmetic;
                   # the a0 overflow bit is now clear;
                   # a1 is now 32768 (meaning -32768) and the a1 overflow bit is set.
move a0 -> nat16 x  # zero is written to the sixteen-bit memory location.
move a1 -> int16 y  # this causes a software exception.
clc a1              # but, if we were to clear the a1 overflow bit first ...
move a1 -> int16 y  # then this would succeed.

I mentioned an edge case.  This is adding a signed number to an unsigned number.  Consider this code:

nat32 total;
void add_to_total(int32 x)
{
  total = total + x;
}

Simple enough, but … do you do the addition with signed or unsigned arithmetic?  You can’t use unsigned arithmetic because x may be negative.  But you can’t always convert total to int32, either; it may be too large.

One solution would be to convert to int64, but this is inefficient if the processor is 32 bits.  Another is to rewrite the code:

void add_to_total(int32 x)
{
  if (x > 0) total = total + (nat32)x;
  if (x < 0) total = total - (nat32)(-x);
}

But now we’re introducing branches, which is also inefficient.

My suggestion is to introduce a new type, int33 (as well as int9, int17, and int65) which is that extra bit longer.  These types would only be valid as intermediate values in expressions, not as variables.  The code then becomes:

void add_to_total(int32 x)
{
  total = (int33)total + x;
}

The compiler is then free to deal with this in the best way available to it in the given instruction set.  Note that by requiring the programmer to explicitly request this special treatment, we avoid inefficiency in cases where the programmer expects total to always be small enough to convert to int32.  In these cases it might be wise for the compiler to generate a warning unless the programmer explicitly says this is OK:

void add_to_total(int32 x)
{
  total = (int32)total + x;
}

Going back to the CPU, there are several ways a new design could help the compiler out in implementing int33.  The simplest would be to give the arithmetic registers a dedicated sign bit, so that register values are always int33 (or int65, or int129).  This would require separate instructions for loading signed and unsigned values from memory (so the CPU knows whether to sign-extend) but since this is already required when loading values smaller than the register size this probably isn’t a big issue.

I hope this is all clear enough.  Please email me or leave a comment if you have any questions.

Harry.