アカウント名:
パスワード:
はい？なんのためのチェックデジットなんだろか、、、
必ず検知できるんだったら、単なる冗長化やん
チェックデジットの一般的な実装では、ナンバーの各桁を特定の数式で処理することで入力されたナンバーが間違っていないかどうかを検出できるのだが
実装によって若干の差はあるが、チェックデジットが１桁なら「入力ミスでも１／１０に近い確率で通ることはある」
いやまあ、たとえば「各桁の数字を足して下１桁をチェックディジットにする」みたいな原始的な方法なら「１桁の入力ミス」は確実に検知できるけど今度は「１２３４５６７８」と「１２３５４６７８」みたいな間違いを検知できない
チェックディジットは単純に「誤入力の確率を減らす」だけで「誤入力を確実に検知できる」ものではないんだよなぁ確実に検知したけりゃ親コメの言うように冗長化するしかない
これ読んでいないよね。
分かりやすくするため、個人番号を11桁の数字abcdefghijkxとしますと、検査用数字xはx = 11 – (6a + 5b + 4c + 3d + 2e + 7f + 6g + 5h + 4i + 3j + 2k) mod 11 ただしx≧10ならx=0です。これなら、まだしもわかりやすいでしょうか。
その分かりやすい説明で何がわかったと思ってるのかわかんないなぁ
まあ確かに、あのコメントで意味が分かるような人は、#3052845 [srad.jp]みたいなボケたことは最初っから書かないでしょうね。、#3052873 [srad.jp]の式が意味することは、「隣り合う桁に対して、異なる数を乗する」ことで、「隣り合う数値が入れ替わった時にはチェックデジットが変わる」ようになっているってことです。> 今度は「１２３４５６７８」と「１２３５４６７８」みたいな間違いを検知できないなんていう浅はかなチェックデジットなんて今時使ってるとこなんてありません。
ちなみに、製品バーコードとして広く使われているJANコードなんかは、「(a+3b+c+3d+e+…+k+3l+m) mod 10 = 0」を満たすようにチェックデジットmが設計されてます。こうすることで、隣り合う数字の入れ替わりは検出できます。(たとえば、コードの始まり2桁が「12」だったら、この部分のチェックデジット計算用の数値は1+3×2=7になりますが、この2桁が入れ替わって「21」になったらチェックデジット計算用の数値は2+3×1=5で、元の数値と変わるので誤り検出できます)ですが、この式だと二つ隣の入れ替わり(12345678が12543678になるなど)は検出できません。それでも、「各桁の数値を間違える」「隣り合う数値が入れ替わる」という「人間がやってしまいがちな入力ミス」に対抗するには、こういう式でも十分効果があると考えられており、これが実用に供されているわけです。
チェックデジットが数字1桁である以上、全部合わせれば確率10%で通ってしまうのは避けようがないけど、人間がやりがちな間違いに検知率を偏らせるように工夫がされてるってことですよね。平均すればデータ量の増加は避けようがないからといって可逆圧縮が不可能ではないように。
# しかし#3052845のようなボケたコメントがプラスモデされるのが今のスラドクォリティ
ちなみに、製品バーコードとして広く使われているJANコードなんかは、「(a+3b+c+3d+e+…+k+3l+m) mod 10 = 0」を満たすようにチェックデジットmが設計されてます。こうすることで、隣り合う数字の入れ替わりは検出できます。
49000083000194900003800019どちらも（下１桁のチェックデジットの「9」も含めて）正しいGTIN-13（JAN）コードです確率は低いですが「必ずしも桁の入れ替わり」は検知できるとは限りません
#1桁の入力ミスは確実に検知できたはずですが
本当にそれだけの意味でその数式書いたの？まぁあなたじゃないんだろうけど。
「検知できない場合があるのは問題だ」という（チェックディジットというものを理解していない）元コメに対してチェックディジットはそういうものではない、検知できない場合もあるという説明をしているって話の流れでしょう。
そこで「このチェックディジットなら数字の入れ替わりを検知できるもんね」って指摘する意味が全くわかんないよ。
上げ足とってチェックディジットのこと詳しい俺ＴＵＥＥＥＥしたいだけの人に何言っても無駄だよ
# しかもそれで「JANコードは入れ替わりも検出できます」とか言い切っちゃって反例あげられてるから凄い間抜けっぽい
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
検知できない場合がある (スコア:0)
はい？なんのためのチェックデジットなんだろか、、、
Re: (スコア:0)
必ず検知できるんだったら、単なる冗長化やん
Re:検知できない場合がある (スコア:1)
実装によって若干の差はあるが、チェックデジットが１桁なら「入力ミスでも１／１０に近い確率で通ることはある」
いやまあ、たとえば「各桁の数字を足して下１桁をチェックディジットにする」みたいな原始的な方法なら「１桁の入力ミス」は確実に検知できるけど
今度は「１２３４５６７８」と「１２３５４６７８」みたいな間違いを検知できない
チェックディジットは単純に「誤入力の確率を減らす」だけで「誤入力を確実に検知できる」ものではないんだよなぁ
確実に検知したけりゃ親コメの言うように冗長化するしかない
Re: (スコア:0)
これ読んでいないよね。
分かりやすくするため、個人番号を11桁の数字abcdefghijkxとしますと、
検査用数字xはx = 11 – (6a + 5b + 4c + 3d + 2e + 7f + 6g + 5h + 4i + 3j + 2k) mod 11 ただしx≧10ならx=0です。
これなら、まだしもわかりやすいでしょうか。
Re: (スコア:0)
その分かりやすい説明で何がわかったと思ってるのか
わかんないなぁ
Re:検知できない場合がある (スコア:5, 参考になる)
まあ確かに、あのコメントで意味が分かるような人は、#3052845 [srad.jp]みたいなボケたことは最初っから書かないでしょうね。、
#3052873 [srad.jp]の式が意味することは、「隣り合う桁に対して、異なる数を乗する」ことで、「隣り合う数値が入れ替わった時にはチェックデジットが変わる」ようになっているってことです。
> 今度は「１２３４５６７８」と「１２３５４６７８」みたいな間違いを検知できない
なんていう浅はかなチェックデジットなんて今時使ってるとこなんてありません。
ちなみに、製品バーコードとして広く使われているJANコードなんかは、「(a+3b+c+3d+e+…+k+3l+m) mod 10 = 0」を満たすようにチェックデジットmが設計されてます。こうすることで、隣り合う数字の入れ替わりは検出できます。
(たとえば、コードの始まり2桁が「12」だったら、この部分のチェックデジット計算用の数値は1+3×2=7になりますが、この2桁が入れ替わって「21」になったらチェックデジット計算用の数値は2+3×1=5で、元の数値と変わるので誤り検出できます)
ですが、この式だと二つ隣の入れ替わり(12345678が12543678になるなど)は検出できません。
それでも、「各桁の数値を間違える」「隣り合う数値が入れ替わる」という「人間がやってしまいがちな入力ミス」に対抗するには、こういう式でも十分効果があると考えられており、これが実用に供されているわけです。
Re: (スコア:0)
チェックデジットが数字1桁である以上、全部合わせれば確率10%で通ってしまうのは避けようがないけど、人間がやりがちな間違いに検知率を偏らせるように工夫がされてるってことですよね。平均すればデータ量の増加は避けようがないからといって可逆圧縮が不可能ではないように。
# しかし#3052845のようなボケたコメントがプラスモデされるのが今のスラドクォリティ
Re: (スコア:0)
4900008300019
4900003800019
どちらも（下１桁のチェックデジットの「9」も含めて）正しいGTIN-13（JAN）コードです
確率は低いですが「必ずしも桁の入れ替わり」は検知できるとは限りません
#1桁の入力ミスは確実に検知できたはずですが
Re: (スコア:0)
本当にそれだけの意味でその数式書いたの？まぁあなたじゃないんだろうけど。
「検知できない場合があるのは問題だ」という（チェックディジットというものを理解していない）元コメに対して
チェックディジットはそういうものではない、検知できない場合もあるという説明をしているって話の流れでしょう。
そこで「このチェックディジットなら数字の入れ替わりを検知できるもんね」って指摘する意味が全くわかんないよ。
Re: (スコア:0)
上げ足とってチェックディジットのこと詳しい俺ＴＵＥＥＥＥしたいだけの人に何言っても無駄だよ
# しかもそれで「JANコードは入れ替わりも検出できます」とか言い切っちゃって反例あげられてるから凄い間抜けっぽい