5 ms·

> 2) this applies only to integer division wherein division by zero is undefined. 1.0/0.0 uses the available Infinity value. Oh jeeze... to me that almost nul

> 2) this applies only to integer division wherein division by zero is undefined. 1.0/0.0 uses the available Infinity value. Oh jeeze... to me that almost nullifies all of the points in the article. It does an alright job explaining how 1/0 = 0 is at least consistent with other notions in the language, but to hear that the same logic can’t be applied to floats is just... well, objectively it’s a mess.

spooneybarger 8y ago
Hillel is talking about math. Unfortunately computers don't really do "math". For example, math doesn't have overflow and underflow to deal with. The floating point standard says that division by 0.0 should be Infinity and provides a value for it. The integer math, all possible values are used for numbers, so division by zero is undefined behavior. And from there, every language is potentially going to have a mess of inconsistency to deal with. You can make 1/0 = Infinity so long as you box all your integers. That is, its not using the machine type, but I type that is a wrapper that can be the machine type or Infinity. And every user takes a large performance hit even if they will never divide by zero. For some languages boxing integers is not a bad thing because they already do it. Why do they do it? Usually, because of another not math problem. Overflow and underflow: What is 0 - 1? Well, its -1 right? Except of course if you have an unsigned integer, then its the max value of the integer. And what if you had 1 to the max value that the computer can represent? You wrap around. Some languages make all integers protect you from this and take a performance hit to be able to box and be able to represent numbers better as we expect them to work. In return, you can not do integer math as fast as you could. Computers and numbers... its an inconsistent mess and a series of tradeoffs for any language of performance and various possible errors. I'm going to talk about this and more in my post.
- starmole 8y ago
  Integers are perfectly fine in math. But they are not a field. Integers modulo something are also well understood in math - but again not a field.
  - spacehome 8y ago
    Integers modulo any prime are a field.
    - ummonk 8y ago
      Powers of 2 are not a prime though, unless the power is 1 (i.e. we are dealing with single-bit integers).
- nanimo 8y ago
  Underflow and overflow and 2's complement are all just modular arithmetic, which is definitely math.
  - gowld 8y ago
    Computers is the math you get, not the math you want.
spooneybarger 8y ago
Here's another good one for you... What does your favorite programming language return for 3/2 as compared to 3.0/2.0? Many will return different values. EDIT: for clarity of my point: integer math that uses machine types is pretty surprising compared to what we would expect from "math" in general for division.
- std_throwaway 8y ago
  Did you mean 2/3?
  - spooneybarger 8y ago
    No. But most programming languages I know of return different results for 2/3 vs 2.0/3.0.
- jshap70 8y ago
  `3/2 = 1` is a consistent answer as long as the programmer understands modulo. The way you're phrasing it makes it sound like there are languages out there that say "`3/2 = 2` because 1.5 rounds up to 2". just so long as you don't expect a consistent answer between python2.7 and 3.x... >.>
  - Zarel 8y ago
    The phrasing is relatively clear to me as saying that some languages say 3/2 = 1.5 (e.g. JavaScript) and some languages say 3/2 = 1 (e.g. C).
daveFNbuck 8y ago
As pointed out by others, floats work differently from ints in programming languages. Division in ints is usually defined such that if x = d * y + m, x / y = d and x % y = m. You can make this work by choosing the right m for every d, but when y is not 0, there are a few conventions you can choose to pick a sensible d and m. When y = 0, the m = a and d is completely free, so there really isn't a right answer from how division works. Division with floats doesn't usually have a definition like that, so you don't end up in a similar situation. Plus, floating point math can have denominators get really close to 0 and have the result of the division tend toward the infinity value. Ints don't have values close to 0 or an infinity to represent what that division would tend toward.
jlouis 8y ago
In the mathematical sense, a Field is a Commutative Ring with the added constraint that the multiplicative operation has inverses for every non-zero element. Floating point doesn't even form a Ring, because the operation is not associative[0]. Coq, for instance, defines the operation for QArith, which are the rational numbers. The representation is a pair (Z, positive), where Z is an integer and positive is a positive number (i.e., 1,2,...). QArith does form a field in the usual sense. Integers are not a Field (unless you pick Z/p for some prime p), and machine words, signed or unsigned are even less of a mathematical object with the usual operations. So you can do almost anything you want to them from a programming perspective, including 1/0 = 0. As Hillel writes, what to do will make sense in some settings, but not in others. You may want MAX_INT in some situations, and 0 in others. And this requires a check, partiality or not. Rejection of the case x/0 has more to do with the notion that it is usually a corner case where you want the programmer to think about what the result should be. [0] The reason is that any addition can incur information loss, and the further away from 0 you are, the more information is lost. Thus, the order in which you add values matter.

spooneybarger 8y ago

Hillel is talking about math. Unfortunately computers don't really do "math". For example, math doesn't have overflow and underflow to deal with. The floating point standard says that division by 0.0 should be Infinity and provides a value for it. The integer math, all possible values are used for numbers, so division by zero is undefined behavior. And from there, every language is potentially going to have a mess of inconsistency to deal with. You can make 1/0 = Infinity so long as you box all your integers. That is, its not using the machine type, but I type that is a wrapper that can be the machine type or Infinity. And every user takes a large performance hit even if they will never divide by zero. For some languages boxing integers is not a bad thing because they already do it. Why do they do it? Usually, because of another not math problem. Overflow and underflow: What is 0 - 1? Well, its -1 right? Except of course if you have an unsigned integer, then its the max value of the integer. And what if you had 1 to the max value that the computer can represent? You wrap around. Some languages make all integers protect you from this and take a performance hit to be able to box and be able to represent numbers better as we expect them to work. In return, you can not do integer math as fast as you could. Computers and numbers... its an inconsistent mess and a series of tradeoffs for any language of performance and various possible errors. I'm going to talk about this and more in my post.

starmole 8y ago
Integers are perfectly fine in math. But they are not a field. Integers modulo something are also well understood in math - but again not a field.
- spacehome 8y ago
  Integers modulo any prime are a field.
  - ummonk 8y ago
    Powers of 2 are not a prime though, unless the power is 1 (i.e. we are dealing with single-bit integers).
nanimo 8y ago
Underflow and overflow and 2's complement are all just modular arithmetic, which is definitely math.
- gowld 8y ago
  Computers is the math you get, not the math you want.

spooneybarger 8y ago

Here's another good one for you... What does your favorite programming language return for 3/2 as compared to 3.0/2.0? Many will return different values. EDIT: for clarity of my point: integer math that uses machine types is pretty surprising compared to what we would expect from "math" in general for division.

std_throwaway 8y ago
Did you mean 2/3?
- spooneybarger 8y ago
  No. But most programming languages I know of return different results for 2/3 vs 2.0/3.0.
jshap70 8y ago
`3/2 = 1` is a consistent answer as long as the programmer understands modulo. The way you're phrasing it makes it sound like there are languages out there that say "`3/2 = 2` because 1.5 rounds up to 2". just so long as you don't expect a consistent answer between python2.7 and 3.x... >.>
- Zarel 8y ago
  The phrasing is relatively clear to me as saying that some languages say 3/2 = 1.5 (e.g. JavaScript) and some languages say 3/2 = 1 (e.g. C).

daveFNbuck 8y ago

As pointed out by others, floats work differently from ints in programming languages. Division in ints is usually defined such that if x = d * y + m, x / y = d and x % y = m. You can make this work by choosing the right m for every d, but when y is not 0, there are a few conventions you can choose to pick a sensible d and m. When y = 0, the m = a and d is completely free, so there really isn't a right answer from how division works. Division with floats doesn't usually have a definition like that, so you don't end up in a similar situation. Plus, floating point math can have denominators get really close to 0 and have the result of the division tend toward the infinity value. Ints don't have values close to 0 or an infinity to represent what that division would tend toward.

jlouis 8y ago

In the mathematical sense, a Field is a Commutative Ring with the added constraint that the multiplicative operation has inverses for every non-zero element. Floating point doesn't even form a Ring, because the operation is not associative[0]. Coq, for instance, defines the operation for QArith, which are the rational numbers. The representation is a pair (Z, positive), where Z is an integer and positive is a positive number (i.e., 1,2,...). QArith does form a field in the usual sense. Integers are not a Field (unless you pick Z/p for some prime p), and machine words, signed or unsigned are even less of a mathematical object with the usual operations. So you can do almost anything you want to them from a programming perspective, including 1/0 = 0. As Hillel writes, what to do will make sense in some settings, but not in others. You may want MAX_INT in some situations, and 0 in others. And this requires a check, partiality or not. Rejection of the case x/0 has more to do with the notion that it is usually a corner case where you want the programmer to think about what the result should be. [0] The reason is that any addition can incur information loss, and the further away from 0 you are, the more information is lost. Thus, the order in which you add values matter.