Comments on: Division by zero http://guru.multimedia.cx/division-by-zero/ Just another WordPress weblog Wed, 10 Mar 2010 12:28:53 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Michael http://guru.multimedia.cx/division-by-zero/comment-page-1/#comment-1810 Michael Wed, 02 Aug 2006 00:18:03 +0000 http://guru.multimedia.cx/?p=43#comment-1810 > Sure but if you generalize your algebraic system a bit and give up some (or all?) of > the nice properties, you can have an algebraic division by zero. Just look at IEEE > floating point. :-) I’m sure there’s a good deal of disagreement over whether or not > IEEE inf/nan semantics are “nice” but it tends to do “the right thing” and sure > beats exception handling IMO. i do like the IEEE inf/nan semantics, and about loosing nice properties, well how many are strictly true for floating point numbers at all? associativity : try huge_val - huge_val + 1 distributivity: try (huge_val - huge_val)*huge_val (overflow) inverse : a * (1/a) (here 1/a probably cant be represented exactly) a*b=0 requires a or b to be 0: try 2 really small numbers ... > Sure but if you generalize your algebraic system a bit and give up some (or all?) of
> the nice properties, you can have an algebraic division by zero. Just look at IEEE
> floating point. :-) I’m sure there’s a good deal of disagreement over whether or not
> IEEE inf/nan semantics are “nice” but it tends to do “the right thing” and sure
> beats exception handling IMO.

i do like the IEEE inf/nan semantics, and about loosing nice properties, well how many are strictly true for floating point numbers at all?
associativity : try huge_val – huge_val + 1
distributivity: try (huge_val – huge_val)*huge_val (overflow)
inverse : a * (1/a) (here 1/a probably cant be represented exactly)
a*b=0 requires a or b to be 0: try 2 really small numbers
…

]]> By: Rich http://guru.multimedia.cx/division-by-zero/comment-page-1/#comment-1804 Rich Tue, 01 Aug 2006 23:07:45 +0000 http://guru.multimedia.cx/?p=43#comment-1804 Sure but if you generalize your algebraic system a bit and give up some (or all?) of the nice properties, you can have an algebraic division by zero. Just look at IEEE floating point. :-) I'm sure there's a good deal of disagreement over whether or not IEEE inf/nan semantics are "nice" but it tends to do "the right thing" and sure beats exception handling IMO. An interesting aside: one might thing that having an infinity element is "wrong" because it's destructive or absorbing, in the sense that INF+x == INF for all x (except -INF). However this is actually true of almost all floating point numbers. For instance if y=2**80 then y+x == y as long as x is fairly small (how small is left as an exercise to the reader). So in a sense, this "misbehavior" is nothing special about infinity, but a nasty property of fixed precision floating point in general. Said differently, infinity is just like a "really big" floating point number at least 2**n times as large as any other, where n is the number of bits in the significand. Interested readers unfamiliar with floating point should read this classic article: http://docs.sun.com/source/806-3568/ncg_goldberg.html Sure but if you generalize your algebraic system a bit and give up some (or all?) of the nice properties, you can have an algebraic division by zero. Just look at IEEE floating point. :-) I’m sure there’s a good deal of disagreement over whether or not IEEE inf/nan semantics are “nice” but it tends to do “the right thing” and sure beats exception handling IMO.

An interesting aside: one might thing that having an infinity element is “wrong” because it’s destructive or absorbing, in the sense that INF+x == INF for all x (except -INF). However this is actually true of almost all floating point numbers. For instance if y=2**80 then y+x == y as long as x is fairly small (how small is left as an exercise to the reader). So in a sense, this “misbehavior” is nothing special about infinity, but a nasty property of fixed precision floating point in general. Said differently, infinity is just like a “really big” floating point number at least 2**n times as large as any other, where n is the number of bits in the significand.

Interested readers unfamiliar with floating point should read this classic article:
http://docs.sun.com/source/806-3568/ncg_goldberg.html

]]>