naturalToWord vs 'clampNaturalToWord'

[Carter Schonwald]

Awsome: it’d be good to provide the explicitly word32 and word64 flavors
too for multi platform portability.

On Wed, Sep 16, 2020 at 4:59 AM Sylvain Henry <sylvain at haskus.fr> wrote:

>
>
>
>
>
>
>
>
>
>
> We can easily add this function to ghc-bignum.
>
>
> I've opened https://gitlab.haskell.org/ghc/ghc/-/issues/18697 to
>
> track this.
>
>
> Sylvain
>
>
>
>
> On 16/09/2020 04:19, Keith wrote:
>
>
>
>
>
>
>
>
> The short of it is,
>
>
>
>
>
> clampNaturalToWord :: Natural → Word
>
>
> clampNaturalToWord n = case n of
>
>
> NatS# w -> W# w
>
>
> _ -> maxBound
>
>
>
>
>
> results in much better space and time use than naturalToWord,
>
> which always takes the least significant Word of the Natural.
>
>
>
>
>
>
>
>
> Because naturalToWord takes the least significant Word, you always
>
> have to check for size before conversion. Even though you do
>
> check, GHC has to assume that, after conversion, the big Natural
>
> could have resulted in a small Word and will uselessly duplicate
>
> all branches for both cases.
>
>
>
>
>
> Is there anything wrong with clamping by default in this case?
>
>
>
>
>
> --Keith
>
>
>
>
>
> Sent from my phone with K-9 Mail.
>
>
>
>
>
>
> _______________________________________________
>
> Libraries mailing list
>
> Libraries at haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Libraries mailing list
>
> Libraries at haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200916/f5134f86/attachment.html>