Алексей Егоров | 13 Apr 18:16 2013
Picon

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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Franco | 13 Apr 18:41 2013
Picon

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`.
Jerzy Karczmarczuk | 13 Apr 19:18 2013
Picon

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
Daniel Díaz Casanueva | 13 Apr 19:12 2013
Picon

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, Алексей Егоров <electreg <at> list.ru> wrote:
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.

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




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

let f x = x in x
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
wren ng thornton | 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
Kim-Ee Yeoh | 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
Gabriel Dos Reis | 15 Apr 12:16 2013
Picon

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
wren ng thornton | 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
Levent Erkok | 17 Apr 19:23 2013
Picon

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 <wren <at> freegeek.org> 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


_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane