ノート:巡回冗長検査
> 値から元のデータを復元できるわけではない。 CRC16では1bitのエラー訂正ができるようです。——以上の署名の無いコメントは、202.227.43.6(ノート/Whois)さんが 2007年4月11日 (水) 04:05 (UTC) に投稿したものです(三畔 2011年4月26日 (火) 13:01 (UTC)による付記)。
- CRC16に限ったものではないですし、CRC16の中でも一部だけの話ですね。CRCそのものの特性ではありません。
- 具体的には、除数が原始多項式であり且つ、検査対象のサイズが(CRC16の場合なら)2^16bits以内、つまり8,192バイト以内の場合に限り、もし誤りが1ビットだけであると(他の誤り検出符号等と併用するなりして)特定出来たなら、エラー訂正が可能になります。
- 世界最狂の魔法使いCray-G 2008年12月19日 (金) 07:57 (UTC) 何故か除去されていたので再掲--世界最狂の魔法使いCray-G 2011年6月14日 (火) 10:29 (UTC)
CRC多項式の設計
[編集]新たなCRC多項式を作成したり、既存のCRCを改良する場合、多項式が既約性を持つようにするのが一般的である。
とありますが、実際に使われている次の生成多項式は既約ではなく、次の既約多項式 と の積になっているようです。
例えば、CRC-16-CCITT の は と分解できます。
現在の英語版の記事 en:Cyclic_redundancy_check#Designing_polynomials により詳細な解説があります。
--NaOHaq(会話) 2017年9月7日 (木) 09:05 (UTC)
CRC-nが検出可能なバーストエラー長
[編集]>>CRCがよく使われている重要な理由として、効率が保証されている点が挙げられる。nビットCRCは通常、nビット未満の連続する誤り(バースト誤り)を検出できる。言い換えれば、nビットの範囲内に1ビットの誤りが複数存在する場合を検出できる。…
上の記述は2008年9月12日(金)20:52の編集で、英語版のページからの部分訳として持ち込まれています。しかし、英語版ページを見ると
>>An important reason for the popularity of CRCs for detecting the accidental alteration of data is their efficiency guarantee. Typically, an n-bit CRC, applied to a data block of arbitrary length, will detect any single error burst not longer than n bits (in other words, any single alteration that spans no more than n bits of the data),…
となっており、nビット未満ではなく、nビット以下が正しいのではないかと思います。
私は全くの素人なので、お詳しい方は検討をお願いします。 --シャミ子(会話) 2020年11月5日 (木) 15:26 (UTC)
- 仰る通り、nビット以下で正しそうですね。
- http://zakii.la.coocan.jp/signal/44_crc.htm
- の (3) を参照。
- それに、仮に未満だとすると、CRC の特殊ケースである偶数パリティ:多項式 x + 1 の CRC-1 が、1 ビットのバーストエラーを検出できないということになってしまいますので、変ですね。
- ひとまず、修正させていただきます。一応上記サイトで証明が述べられているので大丈夫だと思いますが、間違いに気づいた方がいましたら、出典か証明を示してください。--Mr T.I.71(会話) 2022年3月5日 (土) 03:11 (UTC)
CRC-8-CCITT 英語版との違い
[編集]CRC-8-CCITT | x8 + x7 + x3 + x2 + 1 (1-Wire バス) | 0x8D / 0xB1 (0xC6) |
となっていますが英語版では下記のようになっています。
CRC-8-CCITT | ITU-T I.432.1 (02/99); ATM HEC, ISDN HEC and cell delineation, SMBus PEC | 0x07 | 0xE0 | 0xC1 | 0x83 |
x8 + x2 + x + 1 |
ITUのドキュメントを見つけられなかったのですが、当方でx8 + x2 + x + 1をSMBus通信に実際使用していますのでこちらが正しいではないでしょうか?--Mfumita(会話) 2022年8月9日 (火) 03:26 (UTC)