- #1

- 3,962

- 20

**Dr Anderson and "nullity"**

When Dr Anderson declared his discovery of 0/0 = nullity, he was almost universally derided.

Wikipedia article: http://en.wikipedia.org/wiki/James_Anderson_(computer_scientist)#cite_note-perplex9-10

Paper by Dr Anderson: http://www.bookofparagon.com/Mathematics/PerspexMachineIX.pdf

The Wikipedia article states that he discovered nothing more the symbol "NAN" used in computer IEEE arithmetic to represent a "Not a number" error for division by zero. This is true for Dr Anderson's ideas in their raw form and he does not really specify what to do with nullity once he has obtained it, so it still essentially undefined.

I would like to present some arguments that Dr Anderson might be on to something, but it requires modifying his ideas a little. I hope there are interesting ideas here and that the ideas I present will not be instantly dismissed without some thought given to the details I present.

In his paper Anderson clearly states that 0/0 = is not equal to 1.

I would like to modify that so x takes on the value 1 when x := 0/0, where a := b means a is assigned the value of b rather than usual a=b which means a is equivalent to b in normal algebra. Most computer languages make the distinction between the meanings of "assign" and "equals".

__Now here is an example (and I will follow with a counter proof)__

Lets say a computer programmer has written this pseudo code:

(1) [tex] x := a . b \left({b+c \over b . d}\right) [/tex]

A computer would immediately stop at this point and issue a "division by zero error" or a NAN error when b is zero.

Now if expression (1) had been written as the equivalent expression

(2) [tex] x:= {a . b +a . c \over d} [/tex]

then the computer would have got the correct answer x := ac/d when b = 0.

Now expression (1) is sloppy but humans are not perfect and b might even be the result of the two other variables such as b=(e-f) and the obvious division by zero error might not have been picked up during testing.

Now if the computer was programmed to fully evaluate all terms within expression (1) it might come up with something like this:

(3) [tex] x := {a . 0^{(2)} \over d. 0} + {a . c . 0 \over d.0 } := {a . 0^{(1)} \over d} + {a.c . 0^{(0) } \over d} [/tex]

Now if the computer is programmed to evaluate 0^(0) as 1 and 0^(n) as 0 for any non-zero value of n, then it would not have "crashed" and would have got the correct answer x:= ac/d when b=0.

__Now for the counter proof:__

Lets say we have the expression 0 = x.0

Now lets say we know for a fact x has the value 42, then when we divide both sides of the expression 0 = 42 . 0 by zero we get

0/0 = 42 . 0/0

so 1 = 42 if we assume 0/0 = 1 which is obviously NOT TRUE!

The difference here from the earlier argument is that we are using the algebraic expression a = b where the symbol "=" means "equivalent" rather than the computer expression a := b where the symbol ":=" means "assign the value of the expression on the right to the variable on the left"

In normal algebra equations using "=" rather than ":=" then division by zero is still forbiden.

For example if we ask the question, "what is the value of x?" in the equation 0 = x . 0 then x is an unknown value and we would we express this as x := 0/0 in computer language to get x := 1.

This is made clearer if we express the equation completely in terms of variables then it becomes y = x/y and then x := y/y which gives x:= 1 for all y.

Now if we "know" the value of x is 42 then the expression becomes z := 42 . y which means assign the value of 42 . y to z which when y is zero means z := 0

-----------------------------------------------------------------------------

In a calculator or computer there are precedence rules such that multiplication is evaluated before addition in an expression.The computer program would have an additional precedence rule that multiplication and division by zero are evaluated after multiplication by normal numbers within each term and before adding terms. Care has to be taken to sum the powers of zero because as I hope was made clear above 0*0 or 0^2 is not always the same as 0.

Within these rules [itex]n^1[/itex] is always n and [itex] n^0 [/itex] is always 1 for any n including n = 0, which is not true in IEEE arithmetic or ordinary algebra.

In IEEE arithmetic x := n/0 := infinity for n>0 and x := n/0 := NAN for n=0.

Here, x := n/0 := infinity for n>0 and n/0 = 1 for n=0.

In IEEE arithmetic x := n/0 . 0 := NAN for any n.

Here, x := n/0 . 0 := n for any n.

If n/0 . 0 is evaluated in two stages on different lines of the program then there is a problem because at the first stage it might get (infinity) and then get (infinity).0 = 1 at the second stage. A possible "work around", might be to store the intermediate result as n/0 internally (flagging up a non fatal "potential division by zero error" warning) and proceed until the complete expression is evaluated clearing the error.

This is not meant to be a complete final or formal "proof" but just food for thought.

Further sophistications might include applying L'Hopitals rule when indeterminate results are discovered to provide a more robust operating system that is not crashed by a simple equation like equation (1) of this discussion.

Last edited: