Question

I am trying to solve the problem 2’s complement here (sorry, it requires login, but anyone can login with FB/google account). The problem in short is to count the number of ones appearing in the 2’s complement representation of all numbers in a given range [A, B] where A and B are within the 32-bit limits (2³¹ in absolute value). I know my algorithm is correct (it’s logarithmic in the bigger absolute value, since I already solved the problem in another language).

I am testing the code below on my machine and it’s giving perfectly correct results. When it runs on the Amazon server, it gives a few wrong answers (obviously overflows) and also some stack overflows. This is not a bug in the logic here, because I test the same code on my machine on the same test inputs and get different results. For example, for the range [-1548535525, 662630637] I get 35782216444 on my machine, while according to the tests, my result is some negative overflow value.

The only problem I can think of, is that perhaps I am not using Int64 correctly, or I have a wrong assumption about it’s operation.

Any help is appreciated. Code is here.

Answer 1

The stack overflows are a bug in the logic.

countOnes !a !b | a == b = countOnes' a

countOnes' :: Int64 -> Integer
countOnes' !0 = 0
countOnes' !a = (fromIntegral (a .&. 1)) + (countOnes' (a `shiftR` 1))

Whenever you call countOnes' with a negative argument, you get a nonterminating computation, since the shiftR is an arithmetic shift and not a logical one, so you always shift in a 1-bit and never reach 0.
But even with a logical shift, for negative arguments, you’d get a result 32 too large, since the top 32 bits are all 1.

Solution: mask out the uninteresting bits before calling countOnes',

countOnes !a !b | a == b = countOnes' (a .&. 0xFFFFFFFF)

There are some superfluous guards in countOnes,

countOnes :: Int64 -> Int64 -> Integer
countOnes !a !b | a > b = 0
-- From here on we know a <= b
countOnes !a !b | a == b = countOnes' (a .&. 0xFFFFFFFF)
-- From here on, we know a < b
countOnes !0 !n = range + leading  + (countOnes 0 (n - (1 `shiftL` m)))
    where
        range = fromIntegral $ m * (1 `shiftL` (m - 1))
        leading = fromIntegral $ (n - (1 `shiftL` m) + 1)
        m = (getLog n) - 1
-- From here on, we know a /= 0
countOnes !a !b | a > 0 = (countOnes 0 b) - (countOnes 0 (a - 1))
-- From here on, we know a < 0,
-- the guard in the next and the last equation are superfluous
countOnes !a !0 | a < 0 = countOnes (maxInt + a + 1) maxInt
countOnes !a !b | b < 0 = (countOnes a 0) - (countOnes (b + 1) 0)
countOnes !a !b | a < 0 = (countOnes a 0) + (countOnes 0 b)

The integer overflows on the server are caused by

getLog :: Int64 -> Int
--
countOnes !0 !n = range + leading  + (countOnes 0 (n - (1 `shiftL` m)))
    where
    range = fromIntegral $ m * (1 `shiftL` (m - 1))
    leading = fromIntegral $ (n - (1 `shiftL` m) + 1)
    m = (getLog n) - 1

because the server has a 32-bit GHC, while you have a 64-bit one. The shift distance/bit width m is an Int (and because it’s used as the shift distance, it has to be).

Therefore

m * (1 `shiftL` (m-1))

is an Int too. For m >= 28, that overflows a 32-bit Int.

Solution: remove a $

range = fromIntegral m * (1 `shiftL` (m - 1))

Then the 1 that is shifted is an Integer, hence no overflow.