3 ms·

Nonsense! That works fine in Haskell: cal@hp-elitedesk ~/s/b/i/ops> ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package g

Nonsense! That works fine in Haskell: cal@hp-elitedesk ~/s/b/i/ops> ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> 1/0 Infinity

da_chicken 11y ago
Well done, Haskell. You're not even wrong.
RyanZAG 11y ago
1/0 is not infinity, it is undefined. The limit as x tends to 0 of 1/x is infinity, but there is no value for 1/0, which is why doing a calculation that involves a divide by 0 is mathematically invalid. That Haskell let's you do it and gives an approximate answer is OK, but if it was in a calculation for the number of apples you can eat, it would be a useless answer. You could end up with that if you made a mistake in defining your logic. In the same way, you can make a mistake when doing all manner of other things such as using a non-pure function or adding instead of subtracting. They're all forms of logic error that are either allowed or disallowed by tools. The tool isn't broken if it let's you make mistakes though. A power drill will let you drill a nail into your leg. That doesn't make power drills broken. A smart drill that turned off the drill if your leg was in front would be better - but we still use drills without that function because there are trade offs when you make your drill do that. There are trade offs in functional languages too. That doesn't make C# "broken" for being a tool that let's you drill into your leg if you point your drill there.
- thoth 11y ago
  Well then your formula which contains a division by zero is mathematically invalid as well. What do you think is valid - a floating point exception? That's how the hardware handles it. I think you're being overly pedantic on this specific example, division by zero is a special case. Floating point numbers on all architectures are only approximate - 1/7 times 7 is seldom exactly equal to 1, in any language, but that doesn't mean floating point math on a computer is useless.
  - RyanZAG 11y ago
    Sure, but that wasn't my point - my point is that if you're calculating the number of apples you can eat and you make an error in the logic and end up with a calculation of x/y with x=22.9 and y=0, you get an exception or an answer of 'infinity'. My point was: either answer is obviously wrong. You can't eat infinity apples any more than you can eat undefined apples. It wasn't the real answer to the question you were trying to solve. Haskell (or whatever language) allowed you to enter logic that gave an invalid answer. You used the mathematical and functional operators to blow off your leg. You could probably use a more constrained language dealing specifically in "apples and eating" that would prevent you from getting an answer that wrong. Obviously you'd have trade offs in using that language though. So let me try again: Haskell isn't any more a broken language because it let's you calculate apples incorrectly than C# is a broken language because you can print things multiple times.
- Sanddancer 11y ago
  The standard for floating point, IEEE 754, defines X/0, where X != 0 as Infinity. 0/0 is defined as NaN. I disagree quite a bit with the philosophy of a lot of functional programming, but this is an area where they're right.
juliangregorian 11y ago
JavaScript will do the same, as will Ruby for floats.
michaelochurch 11y ago
You can blow up the runtime with integer division by zero, however. λ 1 `quot` 0 *** Exception: divide by zero With `1/0`, it uses `Double` because `(/)` requires a Fractional type. Also, partial functions like `head` or `fromJust` can burn you: λ head [] *** Exception: Prelude.head: empty list The latter is a legacy behavior that is generally considered undesirable. The former is more debatable; some would say that you should avoid integer division by an unknown value as much as possible. In Haskell, exceptions in non-IO code (other than deliberate hard crashes) are generally considered a wart to be avoided and mitigated as much as possible (because they interfere with functional programming).

da_chicken 11y ago

Well done, Haskell. You're not even wrong.

RyanZAG 11y ago

1/0 is not infinity, it is undefined. The limit as x tends to 0 of 1/x is infinity, but there is no value for 1/0, which is why doing a calculation that involves a divide by 0 is mathematically invalid. That Haskell let's you do it and gives an approximate answer is OK, but if it was in a calculation for the number of apples you can eat, it would be a useless answer. You could end up with that if you made a mistake in defining your logic. In the same way, you can make a mistake when doing all manner of other things such as using a non-pure function or adding instead of subtracting. They're all forms of logic error that are either allowed or disallowed by tools. The tool isn't broken if it let's you make mistakes though. A power drill will let you drill a nail into your leg. That doesn't make power drills broken. A smart drill that turned off the drill if your leg was in front would be better - but we still use drills without that function because there are trade offs when you make your drill do that. There are trade offs in functional languages too. That doesn't make C# "broken" for being a tool that let's you drill into your leg if you point your drill there.

thoth 11y ago
Well then your formula which contains a division by zero is mathematically invalid as well. What do you think is valid - a floating point exception? That's how the hardware handles it. I think you're being overly pedantic on this specific example, division by zero is a special case. Floating point numbers on all architectures are only approximate - 1/7 times 7 is seldom exactly equal to 1, in any language, but that doesn't mean floating point math on a computer is useless.
- RyanZAG 11y ago
  Sure, but that wasn't my point - my point is that if you're calculating the number of apples you can eat and you make an error in the logic and end up with a calculation of x/y with x=22.9 and y=0, you get an exception or an answer of 'infinity'. My point was: either answer is obviously wrong. You can't eat infinity apples any more than you can eat undefined apples. It wasn't the real answer to the question you were trying to solve. Haskell (or whatever language) allowed you to enter logic that gave an invalid answer. You used the mathematical and functional operators to blow off your leg. You could probably use a more constrained language dealing specifically in "apples and eating" that would prevent you from getting an answer that wrong. Obviously you'd have trade offs in using that language though. So let me try again: Haskell isn't any more a broken language because it let's you calculate apples incorrectly than C# is a broken language because you can print things multiple times.
Sanddancer 11y ago
The standard for floating point, IEEE 754, defines X/0, where X != 0 as Infinity. 0/0 is defined as NaN. I disagree quite a bit with the philosophy of a lot of functional programming, but this is an area where they're right.

juliangregorian 11y ago

JavaScript will do the same, as will Ruby for floats.

michaelochurch 11y ago

You can blow up the runtime with integer division by zero, however. λ 1 `quot` 0 *** Exception: divide by zero With `1/0`, it uses `Double` because `(/)` requires a Fractional type. Also, partial functions like `head` or `fromJust` can burn you: λ head [] *** Exception: Prelude.head: empty list The latter is a legacy behavior that is generally considered undesirable. The former is more debatable; some would say that you should avoid integer division by an unknown value as much as possible. In Haskell, exceptions in non-IO code (other than deliberate hard crashes) are generally considered a wart to be avoided and mitigated as much as possible (because they interfere with functional programming).