13 Apr 18:16 2013

## NaN as Integer value

is there a reason why Integer doesn't have 'NaN' as value?
I think it would be very convenient to be able to handle (1 `div` 0) as regular NaN value and not as exception.

Thanks.
```_______________________________________________
```
13 Apr 18:41 2013

### Re: NaN as Integer value

```> Hello haskellers,is there a reason why Integer doesn't have 'NaN' as
value?I think it would be very convenient to be able to handle (1 `div` 0)
as regular NaN value and not as exception.Thanks.
>

I think because, if you need NaN like values, `Maybe Int` does the same job
without tainting the definition of `Int`.
```
13 Apr 19:18 2013

### Re: NaN as Integer value

```Franco answers a question :
>> Hello haskellers,is there a reason why Integer doesn't have 'NaN' as
> value?I think it would be very convenient to be able to handle (1 `div` 0)
> as regular NaN value and not as exception.Thanks.
> I think because, if you need NaN like values, `Maybe Int` does the same job
> without tainting the definition of `Int`.
This is not a Haskell problem. For Ints, ALL representations are valid
numbers, a NaN is a specific float object, unless I'm mistaken, so the
introduction of such an abnormal number would require some serious
modifications of the representation.

Jerzy Karczmarczuk
```
13 Apr 19:12 2013

### Re: NaN as Integer value

You can always use the Maybe type as a follows:

intDiv :: Integer -> Integer -> Maybe Integer
intDiv _ 0 = Nothing
intDiv n m = Just (div n m)

This allows you to pattern match results of divisions:

example :: Integer -> Integer -> Maybe Integer
example n m =
case intDiv 4 n of
Nothing -> Nothing
Just n' ->
case intDiv 5 m of
Nothing -> Nothing
Just m' -> Just (n' + m')

Or even better using the do notation:

example2 :: Integer -> Integer -> Maybe Integer
example2 n m = do
n' <- intDiv 4 n
m' <- intDiv 5 m
return (n' + m')

Note that example and example2 both do the same thing.

I think this is cleaner solution add NaN as a value to the Integer type.

Good luck,
Daniel Díaz.

On Sat, Apr 13, 2013 at 12:16 PM, Алексей Егоров wrote:

is there a reason why Integer doesn't have 'NaN' as value?
I think it would be very convenient to be able to handle (1 `div` 0) as regular NaN value and not as exception.

Thanks.

_______________________________________________

--
E-mail sent by Daniel Díaz Casanueva

let f x = x in x
```_______________________________________________
```
14 Apr 10:28 2013

### Re: NaN as Integer value

```On 4/13/13 1:18 PM, Jerzy Karczmarczuk wrote:
> This is not a Haskell problem. For Ints, ALL representations are valid
> numbers, a NaN is a specific float object, unless I'm mistaken, so the
> introduction of such an abnormal number would require some serious
> modifications of the representation.

Also, the necessity of NaN for floats comes from the fact that floats
include values for Infinity and -Infinity, which leads to various
equations which cannot be resolved sensibly. This is different than mere
undefinedness. Undefined values are underspecified, but that can often be
resolved by choosing some arbitrary specification (often chosen via
arguing from limits or combinatorial convenience). Whereas the problematic
values due to infinities are overspecified, so no matter which answer you
pick it's guaranteed to be the wrong answer half the time.

Part of this whole problem comes from the fact that floats *do* decide to
give a meaning to 1/0 (namely Infinity). That's the gateway drug,...

--

--
Live well,
~wren
```
15 Apr 02:53 2013

### Re: NaN as Integer value

```On Sun, Apr 14, 2013 at 3:28 PM, wren ng thornton <wren <at> freegeek.org> wrote:
> Whereas the problematic
> values due to infinities are overspecified, so no matter which answer you
> pick it's guaranteed to be the wrong answer half the time.
>
> Part of this whole problem comes from the fact that floats *do* decide to
> give a meaning to 1/0 (namely Infinity).

I'm not sure what you mean about overspecification here, but in
setting 1/0 as +infinity (as opposed to -infinity), there's an easily
overlooked assumption that the limit is obtained "from above" as
opposed to "from below."

-- Kim-Ee
```
15 Apr 12:16 2013

### Re: NaN as Integer value

```On Sun, Apr 14, 2013 at 7:53 PM, Kim-Ee Yeoh <ky3 <at> atamo.com> wrote:
> On Sun, Apr 14, 2013 at 3:28 PM, wren ng thornton <wren <at> freegeek.org> wrote:
>> Whereas the problematic
>> values due to infinities are overspecified, so no matter which answer you
>> pick it's guaranteed to be the wrong answer half the time.
>>
>> Part of this whole problem comes from the fact that floats *do* decide to
>> give a meaning to 1/0 (namely Infinity).
>
> I'm not sure what you mean about overspecification here, but in
> setting 1/0 as +infinity (as opposed to -infinity), there's an easily
> overlooked assumption that the limit is obtained "from above" as
> opposed to "from below."

Not quite.  0.0 designates "positive zero" or +0.0 in IEEE 754 notation.
There is also "negative zero" or -0.0 in IEEE 754 notation.  If you want
the limit from below, use negative zero.  This is all standard IEEE
754 concepts.

-- Gaby
```
17 Apr 19:11 2013

### Re: NaN as Integer value

```On 4/14/13 8:53 PM, Kim-Ee Yeoh wrote:
> On Sun, Apr 14, 2013 at 3:28 PM, wren ng thornton <wren <at> freegeek.org>
wrote:
>> Whereas the problematic
>> values due to infinities are overspecified, so no matter which answer you
>> pick it's guaranteed to be the wrong answer half the time.
>>
>> Part of this whole problem comes from the fact that floats *do* decide to
>> give a meaning to 1/0 (namely Infinity).
>
> I'm not sure what you mean about overspecification here, but in
> setting 1/0 as +infinity (as opposed to -infinity), there's an easily
> overlooked assumption that the limit is obtained "from above" as
> opposed to "from below."

Setting 1/0 = +inf isn't the problem, or at least not the main one. Of
course, there's always the question about which completion of the reals to
use--- i.e., whether we have +inf vs -inf, or whether we just have a
single point infinity.

Rather, the NaN problem comes from trying to resolve things like:

inf - inf
inf * 0
inf / inf
0 / 0

The overspecification problem I mentioned is that each of these
expressions has "too many" solutions. For example, we have the following
equations:

x   * 0 == 0               -- where x is finite
inf * y == inf * signum y  -- where y /= 0
inf * 0 == ??

x   - inf == -inf  -- where x is finite
inf - y   == inf   -- where y is finite
inf - inf == ??

x / 0 == inf * signum x  -- where x /= 0
0 / y == 0               -- where y /= 0
0 / 0 == ??

--

--
Live well,
~wren
```
17 Apr 19:23 2013

### Re: NaN as Integer value

For better or worse; IEEE-754 settled many of these questions. I personally think the standard is a good compromise of what's practical, efficiently implementable, and mathematically sensible. I find the following paper by Rummer and Wahl an especially good read:

The paper focuses on how to formalize floating-point in SMT-solvers; but section 3 is a great read for understanding how floating-point semantics work, regardless whether you care for SMT-solving or not. It could be the basis for a nice software implementation of floating-point, for instance.

-Levent.

On Wed, Apr 17, 2013 at 10:11 AM, wren ng thornton wrote:
On 4/14/13 8:53 PM, Kim-Ee Yeoh wrote:
> On Sun, Apr 14, 2013 at 3:28 PM, wren ng thornton <wren <at> freegeek.org>
wrote:
>> Whereas the problematic
>> values due to infinities are overspecified, so no matter which answer you
>> pick it's guaranteed to be the wrong answer half the time.
>>
>> Part of this whole problem comes from the fact that floats *do* decide to
>> give a meaning to 1/0 (namely Infinity).
>
> I'm not sure what you mean about overspecification here, but in
> setting 1/0 as +infinity (as opposed to -infinity), there's an easily
> overlooked assumption that the limit is obtained "from above" as
> opposed to "from below."

Setting 1/0 = +inf isn't the problem, or at least not the main one. Of
course, there's always the question about which completion of the reals to
use--- i.e., whether we have +inf vs -inf, or whether we just have a
single point infinity.

Rather, the NaN problem comes from trying to resolve things like:

inf - inf
inf * 0
inf / inf
0 / 0

The overspecification problem I mentioned is that each of these
expressions has "too many" solutions. For example, we have the following
equations:

x   * 0 == 0               -- where x is finite
inf * y == inf * signum y  -- where y /= 0
inf * 0 == ??

x   - inf == -inf  -- where x is finite
inf - y   == inf   -- where y is finite
inf - inf == ??

x / 0 == inf * signum x  -- where x /= 0
0 / y == 0               -- where y /= 0
0 / 0 == ??

--
Live well,
~wren

_______________________________________________
```_______________________________________________