コグノスケ

誕生日

43歳になりました。昨年の日記（2025年3月10日の日記参照）を見ると、転職して半年というのもあって通勤の話をしていました。

チューリングに転職したときは大崎まで電車通勤で、2024年12月あたりで平和島に拠点が移り、車通勤メイン＋月数回の電車通勤になりました。私は偶然、家と会社の距離が近かったので、通勤時間は車も電車もさほど変わりませんでした。駅と家はまあまあ遠いので雨の日は車のありがたみが大きいです。

東京23区の会社で車通勤OKなところって珍しいですよね？土地代考えたらそりゃ当たり前ですけど、ベンチャー＆人数がまだ少ないうちだけの芸当かもしれません……今のうちに堪能しておきましょう。ま、通勤の話はもう良いか。

別の話をしよう

去年から変わったなと思うのはAIの発展です。特に議事録機能、コーディングエージェントは目に見えて強力になりました。

議事録機能は会議の内容をAIが文字に起こしたり、まとめてくれる機能です。ネイティブ言語（日本語）の場合は人がやった方が若干上かな？って思いますが、AIの凄まじい点は「どの言語でも関係なく」議事録能力を発揮することです。自分が全くわからん言語の会議であっても、日本語でまとめてくれる訳です。外国語に人生全振りの専門家なら勝てると思いますが、並の人間の外国語能力ではもう敵わないだろうと思います。

ドラえもんにでてくるホンヤクコンニャクまで、そう遠くない感じがします。スゴイ時代になったな。

コーディングエージェントは作りたいものを伝えると、AIがコードを生成してくれる機能です。冗長で変なコードを生成していてポンコツだな？？なんて思ったのも昔の話。今は自分が知らないプログラミング言語やフレームワークを使うコードを書かせたら、普通に自分を上回っていると思います。

プログラミングできます！○○言語書けます！ってだけのソフトウェアエンジニアがクビになる日は、そう遠くない感じがします。ソフトウェアエンジニアが全員クビになる日は、まだ遠いと思いますが時間の問題でしょう。その時が来たら俺は何をしたら良いのやら……？

CRCの計算方法 - その1

目次: ベンチマーク

令和の時代に今更ですがCRCについて調べてました。CRCのベースになる数学理論である有限体（ガロア体）は、興味深い性質をもちますが、私は説明できるほど詳しくないので、とりあえずCRCだけに着目します。

CRCはたくさんのバリエーションがあり、ビット数（CRC-8とかCRC-16とか）の違いといくつかのパラメータがあります。CRCの種類、パラメータ、結果のサンプルはCatalogue of parametrised CRC algorithmsが有名です。

良く見るパラメータは初期値（init）、出力へのXOR値（xorout）、順序（refin）、生成多項式（poly）です。

• 初期値: CRCの計算を始めるときの値
• 出力へのXOR値: CRCの計算後にXORする値
• 順序: MSBから演算 or LSBから演算のどちらか
• 生成多項式: 入力を割って余りを求めるのに使う多項式の2進数表現、最上位の1ビットが必ず1なので省略して書くことがほとんど

以降の説明ではCRC-8を例にしますので、CRC-8のパラメータを挙げておきます。

• CRC-8
• 初期値: 0
• XOR値: 0
• 順序: 逆転なし（MSB→LSB）
• 生成多項式: 0x1d5 = 0b1_11010101 (x^8 + x^7 + x^6 + x^4 + x^2 + 1)、最上位を省略するなら0xd5

初期値やXOR値が0で一番シンプルなCRCだと思います。

筆算で計算

CRC-8の入力と結果の一例を示します。入力が0xb3 0xb7だとすると結果は0xfeになります。

• 入力: 0xb3 0xb7（= 0b10110011_10110111）
• 結果: 0xfe = 0b11111110

筆算でCRC-8を計算する過程を全て書くと下記のようになります。

入力  : 10110011 10110111 00000000
初期値: 00000000

入力と初期値をXOR（今回は0なので値は変わらず）

10110011 10110111 00000000
11101010 1
 1011001 00110111 00000000
 1110101 01
  101100 01110111 00000000
  111010 101
   10110 11010111 00000000
   11101 0101
    1011 10000111 00000000
    1110 10101
     101 00101111 00000000
     111 010101
      10 01111011 00000000
      11 1010101
       1 11010001 00000000
       1 11010101
              100 00000000
              111 010101
               11 01010100
               11 1010101
                  11111110 = 0xfe

MSB→LSBの順に書いています。MSB側から生成多項式で割った余りがCRCの値です。入力データの最後（16ビット目以降）には生成多項式のビット数 - 1（9ビット - 1 = 8ビット）を0パディングします。パディングする理由がいまいちわからなかったのですが、パディングしないと8ビット以下の入力の場合に、入力 = CRCになってしまうからでしょうか？

プログラムで計算

プログラムで処理するときも筆算とほぼ一緒なんですが、入力をMSB側に寄せていくと考えるとわかりやすいと思います。

  10110011 10110111 00000000

#### 入力のMSBが1なら、1ビット左シフトして生成多項式をxorする = 余りを取る

1 01100111 01101110 0000000_
  11010101
  10110010 01101110 0000000_
| |
|  `--- 最上位を除く上位8ビットだけレジスタに保持する
`--- 左シフトであふれたビットは消す

#### 入力のMSBが0なら、1ビット左シフトする

  00100000 00000___ ________
0 01000000 0000____ ________
0 10000000 000_____ ________

#### 以降は上記の繰り返し

1 00000000 00______ ________
  11010101
  11010101 00______ ________

#### 全ビットを左シフトしたら終わり

  11111110 ________ ________ = 0xfe

MSB側に寄せていって計算する場合を1ステップずつ書くと下記のようになります。

1 01100111 01101110 0000000_
  11010101
  10110010 01101110 0000000_

1 01100100 11011100 000000__
  11010101
  10110001 11011100 000000__

1 01100011 10111000 00000___
  11010101
  10110110 10111000 00000___

1 01101101 01110000 0000____
  11010101
  10111000 01110000 0000____

1 01110000 11100000 000_____
  11010101
  10100101 11100000 000_____

1 01001011 11000000 00______
  11010101
  10011110 11000000 00______

1 00111101 10000000 0_______
  11010101
  11101000 10000000 0_______

1 11010001 00000000 ________
  11010101
       100 00000000 ________

1 00000000 00______ ________
  11010101
  11010101 00______ ________

1 10101010 0_______ ________
  11010101
  01111111 0_______ ________

  11111110 ________ ________ = 0xfe

先程の筆算が左側に寄っただけで、同じ値が計算途中に出現していることがわかると思います。