h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

Re post 9...

Don't actually know if it's anything to do with this particular system MB but...



U180644
+
281474976710656
=
U281474976891300
+
281474976710656
=
U562949953601956
+
281474976710656
=
U844424930312612

Aye - that's the one. I'm pretty sure it works along this sort of Maths.

B

Hello Whisky.


I must have some Livy water. Clever post, how's it done?

OH

You told us the maths, OH - exactly like that.

B

Don't ask me how its done...

I always presumed there was a maximum possible number of U pages built into the software and the rather than throw out invalid numbers if you typed in one then it recycled the old ones

(it could have something to do with the fact that the key number is actually

100000000000000000000000000000000000000000000000 in binary

(1 followed by 47 zeros)

Which is precisely what this 'ere entry's talking about!

Honestly, I think I'm talking to myself sometimes.

B

Maybe I should go back and read the entry again... see if I understand it properly this time...

List of excuses:
It's late
I'm tired
My head hurts
I'm stoopid

Take your pick

Erm - actually, I have a small confession to make.

I was reading two different entries on binary maths simultaneously last night. I meant to post Post 9 (and most of the ensuing conversation) to a completely different place, and only realised this just now when I went back for a re-read. Please ignore everything I've said. Possibly ever.



B

Hello Gnomon.

If such is possible, forget memory. On mechanical, memoryless, decimal calculators, if you inadvertently subtract a larger from a smaller, the displayed result is the 10's complement of the true one. If it's just part of a longer sum, that doesn't matter. The entry explains why that is so. I would love to have assumed that readers would have experienced such machines (by Facit, Monroe, Friden and others), but alas, I know few people ever to have used such machines.

If the problem is about 20 bits and 6 digits, that's a register length, not a memory demand (that's why I called it arithmetic hardware). The fact that 20 bits is large enough to show a whole (decimal) digit advantage, and not a multiple of a byte size, is why I chose it. Getting old, you see, now equipped with high capacity forgetory ... memory never mentioned.

OH (with pangs of nostalgia for a certain Friden)

MB...

There is really only one response to that...

-=






Stop trying to confuse me... I can manage that all on my own!

Hello Whisky

Now I really am going down the pub. 48 bit joke for a 2 bit entry. I'll smile all the way.

OH (looking for some cash)

Hello All.

The entry has been reworked, in the light of the comments made, and to fix some things which no-one else noticed.

The introduction has been revised.

9's complement now states that 9 is the largest decimal digit, and mentions the use of longer strings of 9s.

10's complement now explains itself a little more, and mentions the use of more digits, before double precision is mentioned.

2's complement as a conversion of 10's complement is more fully explained, the difficult of binary is reworded (to be less condescending), and the last sentence is longer.

Anyone like these modifications ?

Hi Cyzaki,

In my Number Systems (A600427) entry I used an analogy with a car odometer to try to explain how, if you halve the range, you can represent both pos. and neg. numbers.

I skirted around the 2's complement thing though (might even have got it wrong) when I tried to explain how you would interpret the -ve numbers. This entry, I think, does a good job of that.

Awu

Hello All.

Still lurking

I thought of the odometer thing, but left it out because it doesn't help at all for explaining multplication. And I also manage to get 10's complement and 2'complement (the standard phrases) via the stepping stone of 9's complement, by tackling encoding head on.

The base power weighting of digits in different number systems can be taken further in binary: for 2's complement, the high bit weight is negative (e.g. in a byte -128, 64, 32, 16, 8, 4, 2, 1). However, this does not help explain why signed add/subtact and unsigned add/subtract both work on identical hardware (I fact I forget to put in my entry).

The first time around, I stopped reading "Number Systems" as soon as I was asked to count dots. No pleasing all of the people all of the time ...

*sigh* I love a good math entry.

Hi Old Hairy,

In my post 33 I was actually resplying to Cyzaki, because she (I think) was having a problem with -128 vs +127. I thought my entry on hex and propagating the sign bit, etc. might help.

I wasn't suggesting that you refer to it.

Awu.
P.S. You dont HAVE to count the dots I tell you the answer. But it's to take the reader through the mechanics.

Hello All.

Still lurking here. Is the entry looking finished now?

If so, I am thinking about another entry "Complementary Arithmetic: The Hard Stuff".

This would perhaps include some of the following for binary only:
An explanation of sign extending, and shifting left and right.
How to detect overflow, and using carry at the left.
The differences between carry and borrow. (on x86s, subtraction makes a borrow, on 68000+ it makes a carry).
How to do division, Booths Algorithm perhaps.
How to extend the precision in a computer (just using more digits is a purely manual technique).
How to do anything else that might be suggested.

Comments invited, on existing entry and suggested one.
Be as suggestive as you like!

OH

Congrats! This one has been accepted for the Edited Guide!


Mikey

Well done!

Thank you everyone.

OH