PROPOSAL: Add 'Natural' type to base:Data.Word

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add 'Natural' type to base:Data.Word

Daniel Gorín
Wouldn't it make sense to have two different types for naturals, one with exception and one with saturating semantics? I can imagine cases where one would prefer one over the other and none of them seem simple enough to simulate if only the other one is given.

On 14 Nov 2014, at 07:05, Herbert Valerio Riedel <[hidden email]> wrote:

> On 2014-11-13 at 23:20:47 +0100, Mario Blažević wrote:
> [...]
>> Regarding the partial vs. saturated negation, I'm in favour of
>> the former. However, there is another option nobody mentioned so far:
>> NaN. I.e.,
>>
>> 1 - 2 = NaN
>> 3 + 1 - 2 = 2
>> 3 + (1 - 2) = NaN
>>
>> Could a GMP-based implementation provide such semantics
>> without too much performance loss? If so, this would be my preference.
>
> Purely from a technical point of view:
>
> If you look at how it's implemented right now:
>
>  https://phabricator.haskell.org/D473
>
> being able to represent a 'not-a-natural' would be possible for the
> GMP2-backed 'Natural' by adding a 'NatErr#' constructor, i.e.
>
>  data Natural = NatS# Word# | NatJ# {-# UNPACK #-} !BigNat | NatErr#
>               deriving (Eq,Ord)
>
> that, however, would require to add one or two case-distinction to all
> 'Natural' operations, and we probably shouldn't auto-derive 'Eq'/'Ord'
> anymore (as it's no longer to be considered a properly ordered
> set/equivalence relation with that absorbing NatErr# element)
>
> However, also the fallback implementation (for when GHC is configured with a
> the old integer-gmp or the integer-simple backend) which is
>
>  newtype Natural = Natural Integer
>
> would need to become more complex, as the lightweight newtype would be
> turned into something like
>
>  data Natural = Natural !Integer | NaturalErr
>
>
> So I'm afraid handling not-a-natural would indeed come at a cost.
>
>
> Cheers,
>  hvr
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add 'Natural' type to base:Data.Word

Mark Lentczner-2
I'm neutral on adding Nat or Natural.... seems you math types :-) need to sort out how to handle subtraction.... the rest of us dirty-hands mechanics are fine with the quirky subtract operation on Words...

BUT

-2 to adding this to Data.Word.  This is not the place to add this, for at least two reasons:
  • Data.Int and Data.Word are the "go to" places for types that correspond closely with what modern hardware supports, and what most interoperable specifications are written to (think file formats, protocols, RFCs, etc....). Nat has none of these properties and is hardly universally agreed upon!
  • People import Data.Word unqualified all the time - I don't think this type meets the trade-off for adding something into many program's global name space.

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add 'Natural' type to base:Data.Word

Andres Löh-3
In reply to this post by Herbert Valerio Riedel
Hi.

> I hereby suggest to add a type for encoding term-level naturals
>
>   data Natural = <opaque/hidden>
>        deriving (...the usual standard classes...)

+1 in general

FWIW, I'm in favour of:

* not putting this into Data.Word, but rather into Data.Nat or Data.Natural
* having default subtraction to be saturated rather than partial
* adding a Nat type for bounded naturals as well (even if it's just a
synonym for Word)

Cheers,
  Andres
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add 'Natural' type to base:Data.Word

Mikhail Glushenkov-2
Hi,

On 18 November 2014 16:38, Andres Löh <[hidden email]> wrote:
> FWIW, I'm in favour of:
>
> * not putting this into Data.Word, but rather into Data.Nat or Data.Natural
> * having default subtraction to be saturated rather than partial
> * adding a Nat type for bounded naturals as well (even if it's just a
> synonym for Word)

+1 on all points. 'Data.Nat.Nat' will clash with 'data Nat = Z | S
Nat' (which is quite popular), but I think that it's better to call
that 'Peano' or something similar. Perhaps we could add 'Peano' to
Data.Nat while we're at it?
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: PROPOSAL: Add 'Natural' type to base:Data.Word

Andreas Abel-2
In reply to this post by Andres Löh-3
+1 for putting it into a separate module like Data.Nat.

On 18.11.14 11:38 PM, Andres Löh wrote:

> Hi.
>
>> I hereby suggest to add a type for encoding term-level naturals
>>
>>    data Natural = <opaque/hidden>
>>         deriving (...the usual standard classes...)
>
> +1 in general
>
> FWIW, I'm in favour of:
>
> * not putting this into Data.Word, but rather into Data.Nat or Data.Natural
> * having default subtraction to be saturated rather than partial
> * adding a Nat type for bounded naturals as well (even if it's just a
> synonym for Word)
>
> Cheers,
>    Andres
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>

--
Andreas Abel  <><      Du bist der geliebte Mensch.

Department of Computer Science and Engineering
Chalmers and Gothenburg University, Sweden

[hidden email]
http://www2.tcs.ifi.lmu.de/~abel/
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
123