naturalToWord vs 'clampNaturalToWord'

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

naturalToWord vs 'clampNaturalToWord'

Keith
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: naturalToWord vs 'clampNaturalToWord'

Sylvain Henry-2

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: 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 <[hidden email]> 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

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries









_______________________________________________

Libraries mailing list

[hidden email]

http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries