Discussion: Change the specification of rotateL for non-finite Bits, or move rotations to FiniteBits
Edward Kmett
ekmett at gmail.com
Mon Sep 29 15:41:49 UTC 2014
It does seem like it should rotate in 1s, but if it does so, what happens
when it rotates out something that isn't all 1s into a negative number or
all 0s into a positive number?
We'd expect `rotateL n . rotateR n = id = rotateR n . rotateL n` for the
finite cases.
but you can't rotate out the digits "up at infinity".
So even this is messy. =/
Ideally we *would* move rotate/rotateL/rotateR to FiniteBits, but there is
a huge upgrade/migration cost associated with that. All user specified
instances break in a way that requires CPP and it diverges from the
standard further.
On Mon, Sep 29, 2014 at 11:33 AM, David Feuer <david.feuer at gmail.com> wrote:
> Problem:
>
> The documentation currently specifies that for non-finite Bits instances,
> rotate is the same as shift. This seems reasonable for Integer rotateR, but
> very strange for Integer rotateL. In particular:
>
> rotateL 5 (-1 :: Int) = -1
> rotateL 5 (-1 :: Integer) = 16
>
> Based on the concept that Integers represent two's complement out to
> infinity, rotating a negative integer left should fill with 1s, but it
> fills with 0s instead.
>
> Solutions:
>
> As stated in the subject, I think one reasonable solution is just to make
> rotateL fill with 1s for negative non-finite instances, and the other is to
> move rotations to FiniteBits, as was done with bitSize.
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140929/42eaf448/attachment.html>
More information about the Libraries
mailing list