2005/11/02
CLコードの登場（ロカポ誕生の記録：８）
認知心理学からヒントを得てコードを作ることに決めた。とりあえず名前を認知心理学（Cognitive Psychology）から「Cognitive Location コード」（CLコード）と名づけてスタートした。（これがその後「ロカポ（Locapoint）」となる）
実際は試行錯誤の連続でしたが、ここでは最終的に落ち着いたフォーマットの仕様について、その経緯等を書いておきたいと思います。これは実質的にロカポの仕様ともいえます。これができあがったのが2005年1月の終わりごろでした。
（本文がかなり長いです・・・・）
●チャンク分け。
例えばソフトウェア製品のプロダクトキーなどは、入力しやすい（？）ように、
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX と言うようなキーを
XXXXX-XXXXX-XXXXX-XXXXX-XXXXX という様に分割しています。
分け方としては、何文字ずつ、と物理的に分けるより「意味のあるかたまり」に分割する方が、脳の中でデータが意味付けられるので記憶に残りやすい。例えば
「はじめ4桁は・・・」「次の3桁は・・・」
というより
「市外局番は・・・」「市内局番は・・・」
の方が覚えやすいと思われる。
位置情報コードを分けるには、まず緯度情報と経度情報に分けられる。二つだけではまだサイズが大きいので、これをさらに意味のある単位に分割するには「広域情報」と「詳細情報」に分けることが考えられた。
そこでCLコードは4チャンクで緯度、経度それぞれの広域、詳細の情報を表すことに決定した。
●使用する文字。
Globalでの使用を考えているので、カタカナや漢字はNG。どこでも通用する文字としてはやはり英語のアルファベットであろう。大文字と小文字を使い 分ければ文字種が増えるので桁数短縮に貢献できそうだが、音声での伝達時に伝達ミスが発生しやすい。（これはソニーのGeoコードの特許でも述べられてい る）。したがって大文字か小文字のどちらか片方に絞る。小文字は文字の形にバリエーションがあり、瞬間的な視認性が優れている。逆に大文字は漢字のように おおよそ正方形であり、小文字よりは視認性に劣る。ただし、小文字であればどうしても「単語」と受け止めてしまう（と私は思った）
つまり（da）とかいてあれば「ダ」と読んでしまう。これが大文字で（DA）とかいてれば「ディー・エー」と読む率が上がるだろうと考えた。誰が読んでも同じになることが望ましいので、後者を取って使う文字は英語アルファベットの大文字のみに決定した。
●連続する文字
「HK」と「KH」は間違えにくいが、「GKH」と「GHK」は間違えやすい。この手の認識間違いは連続する文字数が増えるほど大きくなる。特に私は（日 本人なので？）3文字以上は覚え間違いが多い。したがって、連続する英文字は二文字にしたい。ただし、これは情報量との兼ね合いとなる。
●数字の使用
アルファベット（26文字）と数字（10文字）を混在させれば、36進法が使用できる。ただし、数字の１と文字のI、数字の０と文字のOは得に間違えやす い。パスワード等では文字のIとOは使わないものが多い。カナダのNACコードでは数字とアルファベット大文字から、母音の「AIUEO」と「Y」を省い た30文字を使用している。これはなかなか良く考えられている。まず、省く文字は「母音」と覚えられる。Iと思ってもそれは数字の１である。母音を省いた だけでは31文字であるが、31進法は計算がやりにくい。また30進法にすれば、360度がベースの角度との割り算等がやりやすい。ここで子音を一文字抜 く必要があるが、母音ではないが「I」と音が近くイメージしやすい「Y」を選んでいるあたり、考え抜かれた形跡が伺える。
ちなみにNACコードとほとんど同じマイクロソフトのコードは数字＋アルファベット小文字で、母音と子音一文字を省いた30進法である。子音一文字は「ｙ」ではなく「ｌ（エル）」が選ばれているが、これは数字の１と形が似ているからであることは容易に推察できる。
さて、前置きが長くなったが、CLコードでは、文字と数字を使用する「位置」を区別してこの問題を解決することになった。これは次のリズムとも関連がある。
つまり、文字が表れるべき位置と数値が表れるべき位置を明確に分離しておく。すると「｜」のような文字が表れた場合、それが「文字」の場所なら「I（アイ）」だし、「数字」の場所なら「１（壱）」と区別できる、というアイデアである。
●リズム（韻）
これも電話番号を覚える時だが、よく似た番号をもつものは覚えやすくないだろうか。
例えば
6305-6385
と
6305-2976
では前者の方が覚えやすい。また、少なくとも私は最後の一文字が同じだけでも覚えやすい
6206-8586
これは最後の６だけが２チャンク間で共通なのだが、このおかげで一種の韻を踏むような効果で記憶に残りやすかった。この仕組みをなんとかコードに取り入れたい。韻を踏む、というのは万国共通で、大概各チャンクの後ろで音を合わせている。
とはいえ、
XXXXB YYYYB
のように、強制的に最後の一桁を前のチャンクに合わせるわけにはいかない。これでは一桁の情報量がほとんど無駄になる。
CLコードでは文字の種類でリズムを出すことを思いついた。
つまり、文字であろうが数字であろうが、コンピュータには単に8ビットのデータであるが、人間は明確に「文字」とういグループと「数字」というグループに分けて認識することができる。これを利用してリズムを作るのである。
つまり
「文字・文字・数字」「文字・文字・数字」
とか
「文字・文字・文字・数字」「文字・文字・文字・数字」
のような感じである。正確には韻ではないのだが、それなりのリズムは作ることができる。
●混合基数記数法
これらを加味すると、文字（A～Z）しか表れない位置と、数字（０～９）しか表れない位置ができる。これを数値化するには、文字の桁は26進法、数字の桁は10進法という桁によって進法がことなる（？）進法が必要となる。
調べてみると、これは混合（復号）基数（基底）というそうである。英語ならMixed RadixとかMixed Notation である。身近な例では、
時間：年（365日）、月（30日）、週（7日）、日（24時間）、時（60分）、分（60秒）、秒以下（10進法）
とか、
緯度経度でもある角度
度（３６０分）、分（６０秒）、秒以下（10進法）
そのほかに、アメリカのインチ・ヤード方（インチ・ヤード・フィート）や通貨の単位（ドルとセント）などがある。しかし、これら以外ではめったに使われることはない。
CLコードでは必要な情報量と何文字使用するか、を試行錯誤した結果、
「文字・文字・数字」という単位を4つ繰り返したコードにすることに決定した。
これで表せる情報量は
26（文字）の2乗×10（数字）＝6760
これを緯度、経度に割り振ると、それぞれ７６７０の二乗＝４５６９７６００通り＝25.5ビットで、必要な25ビットをクリアしている。
精度にすると、経度（幅360度）は45697600で割ると赤道上で0.000007.87度（約８０センチ）、緯度６０度ではその半分の４０センチとなる。緯度は幅１８０度なので４０センチの精度である。これだけの精度があれば、「人間が使う」分には十分である。
これでやっと、使いやすいフォーマットと必要な情報量を同時に満足させることができた。
●エンコード・デコードの容易さ
エンコード、デコードをできるだけシンプルにするために、暗号化や圧縮などのアルゴリズムを使用せず、0から45697659までの数字と、緯度なら南緯 90度から北緯90度までの角度を線形に対応させた。経度では西経180度から東経180度に対応させた。これで、「文字・文字・数字」の表記が示す数値 が分かれば、その後は式一つで緯度経度にデコード可能である。
●エリアコードと詳細コードの分離
当初は「緯度上位桁」「緯度下位桁」「経度上位桁」「経度下位桁」の順に並べていた。ここで上位桁同士を並べて左側にしてみた。そうすると、左側２チャンクが広域情報に相当するので、狭い地域で使用する際には、左にチャンクはほとんど変化しない事になる。
電話でも関東地区（東京以外）は04XX、関西地区（大阪以外）は07XX というように、完全に地域コードになっている。こうしておくと、地域内での使 用に際して、左二桁に対して、脳はほとんど気を配らなくても良い。言い換えると、詳細情報である右の２チャンクに記憶力を集中できるので、認知効率が上が る。
この効果はかなり効果的である。私は関西在住であるが、大阪駅周辺はSA2.WU4という地域コードになり、覚えてしまった。あとは詳細コードさえ聞け ば、いつでもそこへいける。なんば（道頓堀川があるところ）などのミナミと呼ばれるエリアは、大阪駅の少しミナミになるのでSA1.WU4 である。
●PCとの親和性（おまけ）
これは当初は想定していなかったが、意外とPCとの親和性があることに気づいた。つまり
SKJEUD というコードがあったとして、パソコンに認識させるには
＜××コード＝“SKJEUD”＞
とタグなどを付けてあげなければ、それが位置情報かどうか分からない。ところがCLコードは
「文字・文字・数字・文字・文字・数字・・・・・・」
というパターンを正規表現で検索すれば、コードが認識できる。これはつまり、「お店の場所はSA2.WU4.SD3.KL4 です。」とプレーンテキスト で書いていても、メールアドレスやURLのように自動的に位置情報であることを検出し、地図やナビソフトを立ち上げるハイパーリンクにできる。
続く．．．
実際は試行錯誤の連続でしたが、ここでは最終的に落ち着いたフォーマットの仕様について、その経緯等を書いておきたいと思います。これは実質的にロカポの仕様ともいえます。これができあがったのが2005年1月の終わりごろでした。
（本文がかなり長いです・・・・）
●チャンク分け。
例えばソフトウェア製品のプロダクトキーなどは、入力しやすい（？）ように、
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX と言うようなキーを
XXXXX-XXXXX-XXXXX-XXXXX-XXXXX という様に分割しています。
分け方としては、何文字ずつ、と物理的に分けるより「意味のあるかたまり」に分割する方が、脳の中でデータが意味付けられるので記憶に残りやすい。例えば
「はじめ4桁は・・・」「次の3桁は・・・」
というより
「市外局番は・・・」「市内局番は・・・」
の方が覚えやすいと思われる。
位置情報コードを分けるには、まず緯度情報と経度情報に分けられる。二つだけではまだサイズが大きいので、これをさらに意味のある単位に分割するには「広域情報」と「詳細情報」に分けることが考えられた。
そこでCLコードは4チャンクで緯度、経度それぞれの広域、詳細の情報を表すことに決定した。
●使用する文字。
Globalでの使用を考えているので、カタカナや漢字はNG。どこでも通用する文字としてはやはり英語のアルファベットであろう。大文字と小文字を使い 分ければ文字種が増えるので桁数短縮に貢献できそうだが、音声での伝達時に伝達ミスが発生しやすい。（これはソニーのGeoコードの特許でも述べられてい る）。したがって大文字か小文字のどちらか片方に絞る。小文字は文字の形にバリエーションがあり、瞬間的な視認性が優れている。逆に大文字は漢字のように おおよそ正方形であり、小文字よりは視認性に劣る。ただし、小文字であればどうしても「単語」と受け止めてしまう（と私は思った）
つまり（da）とかいてあれば「ダ」と読んでしまう。これが大文字で（DA）とかいてれば「ディー・エー」と読む率が上がるだろうと考えた。誰が読んでも同じになることが望ましいので、後者を取って使う文字は英語アルファベットの大文字のみに決定した。
●連続する文字
「HK」と「KH」は間違えにくいが、「GKH」と「GHK」は間違えやすい。この手の認識間違いは連続する文字数が増えるほど大きくなる。特に私は（日 本人なので？）3文字以上は覚え間違いが多い。したがって、連続する英文字は二文字にしたい。ただし、これは情報量との兼ね合いとなる。
●数字の使用
アルファベット（26文字）と数字（10文字）を混在させれば、36進法が使用できる。ただし、数字の１と文字のI、数字の０と文字のOは得に間違えやす い。パスワード等では文字のIとOは使わないものが多い。カナダのNACコードでは数字とアルファベット大文字から、母音の「AIUEO」と「Y」を省い た30文字を使用している。これはなかなか良く考えられている。まず、省く文字は「母音」と覚えられる。Iと思ってもそれは数字の１である。母音を省いた だけでは31文字であるが、31進法は計算がやりにくい。また30進法にすれば、360度がベースの角度との割り算等がやりやすい。ここで子音を一文字抜 く必要があるが、母音ではないが「I」と音が近くイメージしやすい「Y」を選んでいるあたり、考え抜かれた形跡が伺える。
ちなみにNACコードとほとんど同じマイクロソフトのコードは数字＋アルファベット小文字で、母音と子音一文字を省いた30進法である。子音一文字は「ｙ」ではなく「ｌ（エル）」が選ばれているが、これは数字の１と形が似ているからであることは容易に推察できる。
さて、前置きが長くなったが、CLコードでは、文字と数字を使用する「位置」を区別してこの問題を解決することになった。これは次のリズムとも関連がある。
つまり、文字が表れるべき位置と数値が表れるべき位置を明確に分離しておく。すると「｜」のような文字が表れた場合、それが「文字」の場所なら「I（アイ）」だし、「数字」の場所なら「１（壱）」と区別できる、というアイデアである。
●リズム（韻）
これも電話番号を覚える時だが、よく似た番号をもつものは覚えやすくないだろうか。
例えば
6305-6385
と
6305-2976
では前者の方が覚えやすい。また、少なくとも私は最後の一文字が同じだけでも覚えやすい
6206-8586
これは最後の６だけが２チャンク間で共通なのだが、このおかげで一種の韻を踏むような効果で記憶に残りやすかった。この仕組みをなんとかコードに取り入れたい。韻を踏む、というのは万国共通で、大概各チャンクの後ろで音を合わせている。
とはいえ、
XXXXB YYYYB
のように、強制的に最後の一桁を前のチャンクに合わせるわけにはいかない。これでは一桁の情報量がほとんど無駄になる。
CLコードでは文字の種類でリズムを出すことを思いついた。
つまり、文字であろうが数字であろうが、コンピュータには単に8ビットのデータであるが、人間は明確に「文字」とういグループと「数字」というグループに分けて認識することができる。これを利用してリズムを作るのである。
つまり
「文字・文字・数字」「文字・文字・数字」
とか
「文字・文字・文字・数字」「文字・文字・文字・数字」
のような感じである。正確には韻ではないのだが、それなりのリズムは作ることができる。
●混合基数記数法
これらを加味すると、文字（A～Z）しか表れない位置と、数字（０～９）しか表れない位置ができる。これを数値化するには、文字の桁は26進法、数字の桁は10進法という桁によって進法がことなる（？）進法が必要となる。
調べてみると、これは混合（復号）基数（基底）というそうである。英語ならMixed RadixとかMixed Notation である。身近な例では、
時間：年（365日）、月（30日）、週（7日）、日（24時間）、時（60分）、分（60秒）、秒以下（10進法）
とか、
緯度経度でもある角度
度（３６０分）、分（６０秒）、秒以下（10進法）
そのほかに、アメリカのインチ・ヤード方（インチ・ヤード・フィート）や通貨の単位（ドルとセント）などがある。しかし、これら以外ではめったに使われることはない。
CLコードでは必要な情報量と何文字使用するか、を試行錯誤した結果、
「文字・文字・数字」という単位を4つ繰り返したコードにすることに決定した。
これで表せる情報量は
26（文字）の2乗×10（数字）＝6760
これを緯度、経度に割り振ると、それぞれ７６７０の二乗＝４５６９７６００通り＝25.5ビットで、必要な25ビットをクリアしている。
精度にすると、経度（幅360度）は45697600で割ると赤道上で0.000007.87度（約８０センチ）、緯度６０度ではその半分の４０センチとなる。緯度は幅１８０度なので４０センチの精度である。これだけの精度があれば、「人間が使う」分には十分である。
これでやっと、使いやすいフォーマットと必要な情報量を同時に満足させることができた。
●エンコード・デコードの容易さ
エンコード、デコードをできるだけシンプルにするために、暗号化や圧縮などのアルゴリズムを使用せず、0から45697659までの数字と、緯度なら南緯 90度から北緯90度までの角度を線形に対応させた。経度では西経180度から東経180度に対応させた。これで、「文字・文字・数字」の表記が示す数値 が分かれば、その後は式一つで緯度経度にデコード可能である。
●エリアコードと詳細コードの分離
当初は「緯度上位桁」「緯度下位桁」「経度上位桁」「経度下位桁」の順に並べていた。ここで上位桁同士を並べて左側にしてみた。そうすると、左側２チャンクが広域情報に相当するので、狭い地域で使用する際には、左にチャンクはほとんど変化しない事になる。
電話でも関東地区（東京以外）は04XX、関西地区（大阪以外）は07XX というように、完全に地域コードになっている。こうしておくと、地域内での使 用に際して、左二桁に対して、脳はほとんど気を配らなくても良い。言い換えると、詳細情報である右の２チャンクに記憶力を集中できるので、認知効率が上が る。
この効果はかなり効果的である。私は関西在住であるが、大阪駅周辺はSA2.WU4という地域コードになり、覚えてしまった。あとは詳細コードさえ聞け ば、いつでもそこへいける。なんば（道頓堀川があるところ）などのミナミと呼ばれるエリアは、大阪駅の少しミナミになるのでSA1.WU4 である。
●PCとの親和性（おまけ）
これは当初は想定していなかったが、意外とPCとの親和性があることに気づいた。つまり
SKJEUD というコードがあったとして、パソコンに認識させるには
＜××コード＝“SKJEUD”＞
とタグなどを付けてあげなければ、それが位置情報かどうか分からない。ところがCLコードは
「文字・文字・数字・文字・文字・数字・・・・・・」
というパターンを正規表現で検索すれば、コードが認識できる。これはつまり、「お店の場所はSA2.WU4.SD3.KL4 です。」とプレーンテキスト で書いていても、メールアドレスやURLのように自動的に位置情報であることを検出し、地図やナビソフトを立ち上げるハイパーリンクにできる。
続く．．．
# posted by Nao : 20:02
