contributed by <jhin1228>
根據 LeetCode 1680. Concatenation of Consecutive Binary Numbers 給定一整數 ,回傳將 到 的二進位表示法依序串接在一起所得到的二進位字串,其所代表的十進位數字 之值。
以輸入值 n = 12 為例:
串接結果: 1101110010111011110001001101010111100
該十進位值: 118505380540
後,結果為 505379714
以下是可能的實作:
在串接各數字時,需要判定何時需要增加 shift 的位移量,譬如 :
要串接 3 = 0b11 到 110 時,只需要將 110 向左 shift 2 位元再和 0b11 作 or 運算即可,變成 11011。
然而如果要將 4 = 0b100 串接到 11011,會發現無法只把 11011 向左移 2 位元,因為在二進位中,只要數字為 2 的冪,leading 1 就會向左增加 1,所以這時 shift 位移量需加 1 並作 or 運算得到 11011100。
所以,利用 x & (x - 1) == 0
檢查 x
是否為 2 的冪,是則增長 len
的長度。
x & (x - 1) 將最右邊的 1 變成 0,其他位元保持不變。
利用 x & (x - 1) == 0 判斷 x 是否為 2 的冪時在 x = 0 時會出現問題,須修正為 x && !(x & (x - 1))
。
__builtin_{clz,ctz,ffs}
改寫
- Counting leading zeros (clz) : 用來計算 2 進位數從 MSB 往右遇到的第一個 1 之前的所有 0 數量。
- Counting trailing zeros (ctz) : 用來計算 2 進位數從 LSB 往左遇到的第一個 1 之前的所有 0 數量。
- Find first set (ffs) : 用來計算 2 進位數中從右往左數來第一個 1 出現在第幾個位置。
作業環境中存取一個 int
型別需 4 bytes,亦即以 32 個位元構成一資料型態為 int
的變數。32 - __builtin_clz(i)
可以視為整數 i
從 MSB 開始往右第一個出現的 1 在 LSB 開始往左的第幾個位置。
除了上述方法,可利用在 i
為 2 的冪時左移 __builtin_clz(i) + 1
會只剩一個 1 位元的性質。
然而,在 i = 1
時會左移 32 位元,由於 i
資料型態為 int
(在此 sizeof(int) == 4
),這樣的行為在 C standard 中是未定義,換言之,只有左移 0~31
是被 well-defined。
6.5.7 Bitwise shift operators 第三段提及:
- The integer promotions are performed on each of the operands. The type of the result is
that of the promoted left operand. If the value of the right operand is negative or is
greater than or equal to the width of the promoted left operand, the behavior is undefined.
嘗試修改成如下:
在 LeetCode 執行卻發生 runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
,回頭查閱規格書:
6.5.7 Bitwise shift operators 第四段提及:
- The result of is left-shifted bit positions; vacated bits are filled with
zeros. If has an unsigned type, the value of the result is , reduced modulo
one more than the maximum value representable in the result type. If has a signed
type and nonnegative value, and is representable in the result type, then that is
the resulting value; otherwise, the behavior is undefined.
因為 1 是 singed integer,1 << 31
相當於 ,顯然超出 int
的表達範圍(),可將 i
轉換成 unsigned integer:
在 $ gcc (Debian 10.2.1-6) 10.2.1
環境下測試:
可發現 gcc
只警告 1 << 32
的部分:
實際執行時會發現 1 << 32
和 1 << input
輸出結果不同,可知 1 << 32
在 gcc
中是未定義。
至於為何 gcc
沒有針對 1 << 31
跳出警告,查閱 gcc - 4.5 Integers 可發現:
As an extension to the C language, GCC does not use the latitude given in C99 and C11 only to treat certain aspects of signed ‘<<’ as undefined. However, -fsanitize=shift (and -fsanitize=undefined) will diagnose such cases. They are also diagnosed where constant expressions are required.
先實驗 gcc
針對 1 << 31
的行為處理:
執行結果如下:
結論是前處理器計算的值和實際執行計算的值相同。
在編譯時加上
- fsanitize=shift
可在執行時檢查出:
runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
接著可以從組合語言的角度來檢視:
從組合語言的觀點來看 gcc
如何處理 1 << 31
,以下是擷取上方程式碼編譯後和 1 << 31
相關的組合語言部分:
根據官方針對 shl
的敘述,預期是以 (int)(((unsigned)1) << n)
的方式處理。
回到利用__builtin_{clz,ctz,ffs}
改寫的部分,亦可改寫成如下:
mod
運算進行 mod
運算相當耗費 CPU 資源,在編譯器無優化下,可從以下程式碼的組合語言發現除法 (divl
) 指令:
此時搭配 gcc
參數 -O1
觀察優化過程:
先講述背後原理:
這裡有個特別的數: ,稱之為 magic number,神奇的地方在於透過此數可將除法替換成乘法運算。
但在這 不為 的因數,在有限的位元數下做浮點數乘法是件麻煩事,所以希望 是整數。
Case1:
令,
假設 ,
(矛盾)
Case2:
令,
則 ()
,其中的 是誤差值,可藉 來改善。
我們當然可以取足夠大的 來降低誤差值,但此舉會造成 值過大而無法存取於有限位於的暫存器中,導致需要額外處理並影響效能。
目標: 取最小的 同時能有效減少誤差值的影響。
所以,要確保 多出來的小數部分加上 小於 1,可以列成:
在這由於 n
的資料型態為 int
,假設 n
為 32 位元的整數:
當 ,
當 ,
所以在 時, 式會成立。
接著思考取這樣的 N
值會不會導致 m
太大?
以下找尋 值範圍:
另外,
在計算 時,由於 可能是一個 33 位元的數, 需要特別留意 ( 可能為 65 位元的數)。
可以利用加法分配律來改進,針對 :
(可看成是將第 33 位元和其他位元分開處理)
令 (在這 是 扣除第 33 位元)
令
其中 仍可能產生溢位 (),需再作進一步處理:
從以下不等式可知:
不會造成 integer underflow
也不會造成溢位
結論 (計算 ):
- 預先計算:
- 預先計算: (注意: 此例實際在編譯器上組合語言顯示的 magic number 是 ,不是 。)
- 計算:
- 計算:
- 計算:
接著搭配此處組合語言驗證上述演算法:
$eax
存取輸入值a
0x12e0be63
就是 ,並將q
值存放至$rax
和$rdx
(, 等於 去除第 33 位元)- 接著
$eax
值為n
,在<+50>:
時$eax
值為- 然後
<+52>: add %edx,%eax
等同計算t
- 更新 。至此已計算出 並存至
$eax
最後, 結果存入$esi
以下程式碼可判定 16 位元無號整數是否符合特定樣式 (pattern):
符合上述程式碼樣式如下:
觀察上述代碼和程式碼樣式可得知其作用為確認 MSB 是否為 1 且從 MSB 開始到最低位的 1 間是否存在 0 ,若存在便會回傳 false
。
上述代碼在輸入值越大時,由於位元長度遞增而造成迴圈執行次數的增加,故可利用下列程式碼改進:
首先,由於特定樣式的性質,取其二補數時可保證只有一個 1 且是最右邊的 1,如下方例子:
接著,n ^ x
可去除原數最右邊的 1,保證運算後的結果必定小於原數。
若輸入值 x
不滿足該樣式,也就是從 MSB 開始到最低位的 1 間存在至少一個 0,取二補數後夾在中間的 0 會變成 1,即使後續作 XOR 運算也只能去除最右邊的 1,這些在中間的 1 依然存在,導致結果比原輸入值大,如下方例子: