先日、Google Glassに究極のアプリが登場: 警官,消防士,災害救助などの現場が使用する多用途情報機器へという記事がありました。

実際の運用には、事前にどれだけ情報を得ておいて良いのか、防犯カメラなどへのアクセスについて問題はないのかなど、いろいろ問題があることはあるだろうと思います。でもまぁ、そのあたりはどうにかするでしょうという前提で。

こういうシステムを運用しようとすると、フォワードとコントロール（あるいはバックアップと呼ばれるかも）という体制が必要になると思います。現状でも指揮室とか指揮車とかはあると思います。ですが、おそらくコントロール側のあり方が変わるのではないかと思います。単純に人数比でも、フォワードとコントロールの人数比が１対１にまではならないでしょうけど、フォワード３に対してコントロール１とか、そのあたりまでの人数比にはなるかも。コントロール側だけでも、今はマルチディスプレイを使うでしょうが、対応するフォワードの人数＋何枚かくらいのディスプレイが必要かもしれません。さらには、現場での班などの分け方が必要に応じて変わると、あるフォワードに対するコントロールが誰なのかが変わったりするかもしれません。そんなのも簡単に制御できるほうが嬉しいでしょう。そうすると、指揮室とか指揮車とかの様子も変わるだろうなぁと思います。

まぁ、その手の話が好きな人にとっては当たり前の環境が、現実になるかもという感じでしょうか。

Pebbleの一般Pre-Orderへの出荷が始まったのか、すでに始まっているのかという状況みたい。

面白そうだけど、日本語に対応していないし（多分OS周りのアップデートですぐに可能になると思う）、基本的には受信＋通知みたいだし。Pebbleからスマートフォンへの送信もできると思うけど。タッチパネルもマイクもヘッドフォンジャックも無いらしい。入力は物理的なボタンが４つあるだけみたい。

すっきりした設計とは言えるだろうけど。Pebble自身も計算機だから、独力いろいろできると思うけど。

でも、買ったとして、時計画面の切り替えだけで使うのももったいないしなぁ。ポテンシャルは結構あると思うのだが。１つアイディアはあるのだが、Pebbleを使わず、スマートフォンだけでできるし。

まぁ、Pebbleの一番の魅力は、e-Inkを使ってることによると思われる（CPUやクロックも当然関係するが）、バッテリーの保ち時間かな。一週間くらいもつらしいし。

まぁ、「京の後継機」という表現をしているところもありますが。アーキテクチャとかいろいろどうなるかわかりませんし、そうなると後継機という表現が妥当かどうかもわかりませんので。

スパコン世界一なるか　「京」後継機、1000億円で(日経)

京の時には、蓮舫さんの「2位じゃだめなんですか？」というのが有名になりましたが。いやぁ、2位を狙うというのは1位を狙うより難しいだろうなぁと思ったりもします。まぁ、お金の話をしているときに、何位かという話が出てきたのも理解できなかったのですが。かけたお金と順位が比例すると思ってらっしゃったんでしょうか。

今回のものも、いろいろ意見があるみたいです。声が大きいのは次の2つかなと思います。

1. 外から買った方が安いから外から買え
2. 震災復興など、より重要なものに金を使え

どちらも、間違った主張ではありません。2については、反論は難しいかなと思います。感情的な部分もありますし。しいて言うなら、「1000億で足りますか？」というくらいかと。

で、1の方です。求めるものが計算速度であるならば、そのとおり、買えばいいと思います。

国立天文台、約502TFLOPSのCray製Xeonスパコンを運用開始(PC Watch)

このような例もありますし。

ただ、問題なのは、求めているものが計算速度なのかという結構根っこの部分です。

こういう書き方をすると、「計算機に計算速度以外の何を求めるのか？」という考えもあるかもしれません。そういう方には、「その速度を達成しているのは何によってですか？」と聞いてみたいと思います。

まぁ、「世界一」なんて言葉は無視すればいい話ですが、こういう言葉のほうが人を惹きつけたり、分かり易い気分にさせるので使うのでしょうね。それよりも「エクサ級」の方が大事なのですが。

で、考えてみて欲しいのが、エクサ級というのが「現状のままで達成できるのか？」ということです。現状のままで達成できるのであれば、それは既に達成されていなければ理屈に合いません。既に達成されているのでないならば、それがどのように小さなものであれ、何がしかの技術の進歩が必要だということです。

そこで問題なのが、求めているのは計算速度なのか、技術の進歩なのかというところです。

この手のプロジェクトだと、結局は両方ということになるわけですが、なんにせよ技術の進歩を求めてのものなわけです。それも独自の。先の「何によってですか？」は、技術によってなわけです。

「技術だって買えばいい」という意見もあるかもしれません。ただし、それは技術開発や研究というものを放棄することになります。知的財産（ノウハウも含む）の蓄積や、人材の育成というものを捨てるのであれば、「技術も買う。物も買う」という方向でかまわないかと思います。その場合、知財の蓄積、技術などの継承、人材の育成が止まり、ついでに人材の流出という方向になるでしょう。買うだけの金がある間はいいですけどね。

たとえば、ヨーロッパのHuman Brain Project (これってBlue Brainが起源なのかなぁ)や、アメリカのBrain Initiative、日本の霊長類の脳の分析なんかはグランドチャレンジとなっています(あ、日本のはグランドチャレンジじゃないかも)。まぁアメリカの機関もHuman Brain Projectに参加してるでしょうけど、なのになぜ独自にプロジェクトを立ち上げるのかってのと同じです。あと、Human Brain Projectにせよ、Brain Initiativeにせよ、「金額がちょっと安くない？」と思われるかもしれませんが、Human Brain Projectだと2023年までということなので、期間、金額も同程度かと。あとは、これを呼び水にして世界中からお金が出るからかと思います。

まぁ、データ活用の基本企画は決まった。まだ、どのプログラミング言語でどういうデータ構造にするかは悩んでる。

うーむ、空とかnullはφという記号を使うとして。不定ってのはなにかよく使われる記号ってあったっけ？普通に単一化みたいに考えてただの変数みたいに書いとけばいいのかな…。でもギリシア文字とか使った方がかっこいい、じゃなくて目立つから、見た目で分かり易いのだが。

空にεを使うのもふつうだな。 ψでも使うか。∃と∀はこの記号でいいや。

分野によっては不定なんとかをχを使うのもあるのか。それもいいなぁ。

直接は使わないけど、記号論理と述語論理を軽く読み直した方がいいかも。どっかに詰め込まれた本を探さないと。記号論理はどこにあるか分かっているけど。

amazon.co.jpでkindleを出したころから、amazon.co.jpのマイストアの感じが変わった。amazon.comのと同じようになってる。

amazon.comと同じようにするのは構わないけど、現状、amazon.co.jpのマイストアもamazon.comのもちょっと問題がある。

マイストアで、本でもkindle本でもいいけど、">"を１回でもクリックしてみる。その上で、表示されてる本をクリックする。そうすると、その本のページにジャンプする。そこから、「マイストア」のリンクをクリックしても、ブラウザのバックボタンをクリックしても、キーボードのバックスペースボタンを押しても、マイストアでの表示が最初のものに戻ってしまう。(何回か">"をクリックしたときの)本をクリックした状態に戻って欲しいのだが。">"を何回かクリックした後で、元に戻ると面倒で…。

クッキーあたりを使えばどうにかなると思うのだが。改善して欲しいな。

ちょっと仕事で、扱うデータ構造と、それを処理するために使う言語で悩んでます。

まず、どういうデータ構造にするのが楽かを決めかねてる。表計算みたいな感じで、一行ごとのまとまりを基本にする方法もないわけじゃないが、項目間にちょい面倒な関係があるので、一行(1 record)単位で済ましてしまうのは、記述能力が低い。できないことはないけど、「参照、参照」の嵐で、面倒になりそう。

単純に考えると、多重の入れ子構造にするのが素直なんだけど。まぁ、いわゆるリスト(あるいはS式)みたいなもの。ただ、プログラミング言語で処理をする時に、ぱっと見で、各々の処理で必要なところをデータから直に引っ張り出せない。引っ張り出す関数やメソッドを書けばいいだけだけど、言語によって書きやすさが違う。関数やメソッドを書いて独立させるにせよ、書かないでべた書きするにせよ、計算機にやらせるのだから、時間がかかるとかそういうことはとりあえず気にしなくていい。ただ、データ構造の基礎は単純であっても、実際に作るデータは結構面倒になるので、使う言語によっては、プログラムを後で自分が見たときに、「何をやってたんだっけ？」ということになりかねない。

深い入れ子構造ではなく、比較的単純な入れ子構造にしといて、適宜マーカーを埋め込んでおくという方法もある。ある理由から、適宜マーカーを埋め込んでおく方法が実はいろいろと楽かもしれないとは思っている。

データ構造の方は、そういうわけで、詳細はともかく、基本的にはリストにしとくのが楽かなぁとは思っている。

で、言語の方。ちょっと事情があって、データの前処理にはRubyを使う。まぁ、外部ライブラリの関係なので、Rubyでなくてもかまわない。ただ、以前Rubyで作った、そこのところのプログラムを使えるはずなので、前処理はRubyでやろうと思っている。

言語について悩んでいるのは、前処理の結果を読み込んで、リストにして、いろいろ処理をするのにはどの言語を使うと楽かなぁと。前処理で、出力を微妙にリストにすることはできるから、その可能性も込みで。あ、前提として、正規表現を使えるととっても便利という条件はある。使えないなら使えないでやりようはいくらでもあるけど。

Rubyも、リストの入れ子というか配列の入れ子はできる。Pythonも同じく。ただ、やり方しだいというところはあるけど、リスト操作や、リストでの入出力がちょっとやりにくいかなぁとも思う。LISP的なリストが頭にあって、その考え方をしているので、RubyやPythonではやりにくいと思うのかもしれない。なので、データ構造もリストを基礎にしたものとは別のものもありうるかと思ってみたり。

配列の入れ子の方が、ぱっと見では楽に扱えるようにも思えるかもしれない。ただ、それは配列の何番目にはどういうデータが入っているかが分かっていることが前提。表計算の列には、同じ種類のデータしか入ってない(なんでもいいけど、たとえば単価とか)。列の中で、このセルは単価、あっちのセルは製品番号というようになってたら、データとして扱えない。で、扱おうと思っているデータが、困ったことに、それと似たようなものになる。むしろ、その程度の問題なら、適宜可能な範囲で整列させ直せばいい。ところが、扱おうと思っているデータだと、配列的にうまく扱おうと思っても、難しい場合があることがはっきりしている。配列的に扱う方法もないわけではないけど、例外処理になっちゃうので、ちょっと避けたいかなぁと。

リストを基礎にしたデータ構造を想定しているので、LISP系統の言語を使うのが素直かもしれない。GaucheとかClojureとか、いろいろある。でも、任意のデータを引っ張り出すのがなぁ。関数やメソッドの定義で済んでしまうことだから、そうするのが良いのだと思う。

「REBOLは？」と聞かれるかも。REBOL ver. 2.x(本家の一つ。日本語訳ドキュメント(一部)。)は日本語文字コードに対応していない。REBOL ver. 3.x はUTF-8(だったと思う）を使うが、処理系そのものがαテスト段階。αテスト段階でも、だいたいまともに動くみたいなんだけど、ちょっと不安もある。

現状、データ構造を先に決めるか、使う言語を先に決めるか、なんだか卵が先か鶏が先かみたいな状況になってる。同じことが出来るなら、どうせなら楽に出来るほうが嬉しいし。目的とする処理にあまり向いていないデータ構造でも、力技でどうにでもできる。だけど、面倒だからそれは避けたい。力技でやると、バグの発見・修正が面倒だったり、後でソースを読み直したときに、「なにやってんだっけ？」(上にも書いたけど)となる。なので、それは嫌だなぁと。そこをうまい事やるのも技術なんだとは思う。でも私は別の方向での対応の方が好き。

困ったものですな。

補足(追記 2013-Apr-19)---- BEGIN
えーと、プログラミング言語によっては、それぞれに扱い易いデータ構造があるってことです。配列が扱い易い言語もあれば、連想配列が扱い易い言語もあれば、リストを扱い易い言語もある。使うデータ構造と、使う言語の相性がいいと、プログラミングがとてもやり易くなる。

それから、仕事とかやる事によるところもあるという前提で。私の場合、あまり大きなプログラムは作らないようにしている。全体としてはある程度大きなプログラムになる場合ももちろんあるけど。基本的にある程度の機能ごとに独立したプログラムを書くようにしている。で、それぞれの機能のプログラムごとに、異なるプログラミング言語を使う場合がままある。それぞれの処理や、データの扱いを、それをやり易いプログラミング言語で書く。それが可能な仕事とできない仕事もあるけど、私の場合、それをやっても構わないので。プログラム間のデータの受け渡しは、ファイルにするのがたぶん一番簡単。ただ、その場合はファイルの書き出し・読み込みに少し時間が取られる(OSが提供するキャッシュとかRAMディスクはあるけど)。なので、場合によってはパイプとかプロセス間通信とか。それでも、モノリシックなプログラムより、実行の効率は下がるだろうけど。個々のプログラムの開発や修正は、その中でとりあえずまとまっているので、作るのも理解するのも覚えるのも修正するのも楽。必要なときに、「あぁ、あのプログラムか」と思うと、ソースコードが頭の中に全部展開されるくらいの感じ。必要があればモノリシックで大きなプログラムも書くけど、できるだけそういうのは避けるようにしている。モノリシックで大きなプログラムを書かないといけないときでも、効率は落ちても、それなりに分割して考えられる単位に分けるようにしている。

あとは、処理によってはmakeを使って処理手順を書いたりする。makeを使うと、たとえば拡張子(.exeとか.docとかいろいろ)などによって、これこれの処理をする際には前もってあっちをやっとかないといけないなどなどを自動化できるので楽だ。そういう機能があるのと、プログラムを処理ごとに分割してあるので、途中結果をファイルに書き出しておけば、その続きの処理を先と異なるパラメータで計算することもできるし。パラメータと言えば、プログラムの動作に関するパラメータも、プログラムの起動時に渡すものとして何種類もそれぞれの処理として記述しておけるので、ソースコードを見ながら、「さっきうまく動いた時のパラメータはどうだったっけ？」とか「直し終えてない場所はないよな？」とか、頭を抱えなくてすむ。だいたいソースコードにいくつもの値がコメントとして並んでいると、それぞれについての説明も書いておいたとしても結構混乱するんだ。
---- END

最近、Appleや、Samsung、Google、それにPebbleなどなどがSmartWatchというものを開発途中だとか。単体で機能するものなのか、それともスマートフォンを本体として、補助デバイスとなるのか、それはわからない。

腕時計に計算機の機能を持たせるというのは、画期的なアイディアに思えるかもしれない。だが、そう思うなら技術音痴を自覚したほうがいい。

日本限定でも、1984年にSEIKOからUC-2000とEPSONのRC-20が発売されている。また、1998年にはセイコーインスツルメンツがRuputerを発売している。

つまり、もちろん現在の技術で高機能化しているだろうが、SmartWatch(腕コン)は、新しい概念ではない。

で、話が変わるが、2014年にはGoogle Glassが出てくるらしい。しばらくは開発者向けなので値段が高そうだが。これまた革新的と思われるかもしれない。だが、メガネに投影する形のディスプレイは20年くらいからある。もちろん、CPUやメモリ、OS、GUIなどの利用環境、投影技術、音声入出力技術、バッテリなどの高度化により、当時とはかなり状況が違う。10数年前だろうか。その頃には、機械の修理や操作をする際に、身につけたグラスに操作箇所などを投影する、Augmented Reality技術はあった。

つまり、もちろん現在の技術で高機能化しているだろうが、Glassは、新しい概念ではない。

Glassの方を使っている様子は、適当に検索すればビデオが見つかるだろう。基本的に入力は音声で、出力は投影ディスプレイと音声だ。

なら、仮に腕コンが単体で本体として動作するとしたら、どういう使い勝手になるだろう。

腕コンの小さい画面は、おそらく補助的なものになるだろう。ただ、一般ユーザがどれくらいの大きさまで許容できるかは分からない。私個人は、大雑把な話、スマートフォンを上下に２等分した、そのサイズなら腕につけててもあまり違和感は感じないと思うが。まぁ、いずれにせよ画面は小さい。腕コンから空間に映像を投影できればいいんだけど、そんな技術はない。

そうすると、Bluetooth接続の小型のヘッドセットを使って、音声入出力がメインという事になるだろう。検索結果も、webページも、すべて合成音声での読み上げだ。使いやすさは、ブラウザにどの程度の言語処理を組み込むかにもよるだろう。また、現在スマートフォンやタブレット用のwebページが用意されているように、読み上げ用のページが用意されるようになるかもしれない。

ただし、腕コンの致命的な問題は、腕につけるということからくる、サイズの制限だ。今のスマートフォンのバッテリーを使おうとすると、面積が大きくなったり、厚くなったりするしか無い。受け入れられるサイズで、利用可能時間をどう確保するか。難しい問題だと思う。

2013-Feb-01に行われた、麻布中学の入試で、次のような問題が出たとか。（以下の引用枠内は再構成したもの。）

あるものが生物であるか否かは、次の３つの基準によって判断される。
特徴A: 自分と外界を区別する境界を持つ。
特徴B: 自身が成長したり、子をつくったりする。
特徴C: エネルギーを蓄えたり、使ったりするしくみをもっている

このような条件に照らし、ドラえもんは生物であるといえるか。
また、その理由を述べよ。

ついでに書いておくことがいくつかある。

この特徴では、ある生命体が自身の形、構造を維持することが述べられていない。これは恒常性が保たれているか否かという問題である。目が覚めたら虫になっていた経験のある人はいない。つまり、成長しても老化してもある生命体はある生命体であるとして存在しているということ。

特徴Cについては、通常「代謝を行なう能力があること」といわれているもののことだろう。

３つめに、ウィルスはどうなんだという問題。学術的にはどっちかというとウィルスは生命ではないということになっているらしい。しかし、本当にそういっていいのかどうかという議論はあったと思う。

話題になった問題では、「インターエデュケーション・ドットコム」というとこが解答例を出しており、それによりば、「ドラえもん自身が成長したり、子孫を残すことができないから」とのものだそうな。前提条件として与えられていることの内容と、「ドラえもんはロボットである」という常識から、そういう解答はそのまま出てくる。こんな問題、作ってても解いてても何が面白いのか。ただ、大昔から言われていることだが、ロボットを作る工場を系に組み込んだらどうかということは言われている。そこまで考慮に入れた解答があれば面白いけど。

ジェイムス・P. ホーガンの「造物主の掟」ではもっと生物っぽくなっている。このロボットは、互いにコミュニケーションし、道具を作り、使い、身分制度を持ち、国という概念を持ち、環境を観察し、環境に介入する。十分にドラえもんだ。更に、このロボットはペアを組み、個々のロボットの持つ設計情報の半分ずつを提供し、それを合わせたものを使い、工場内で子供ロボットを組み立てるようになっている。現状、人工子宮はまだないが、それが出来さえすれば、働きはもう同じものだ。そしてそのロボットがドラえもんなら、ドラえもんは生物だと答えるのが妥当だろう。つまらない。この状態で答えを出せる人は何を考えているんだろうか。

なんにせよ、問題となってる設問よりも、「ドラえもんはヒトであるか？」という設問の方がよっぽど面白い。ヒトは何故にヒトという一つのグループにまとめられているのか？あるいは、まとめることが可能になっているのか？それは生物種という問題を超えた問題だ。

例えば、ドラえもんではなく、灰色の宇宙人がやってきたとしよう。もちろん、地球人、宇宙人１という種の区別は残るが、宇宙人という言葉に人という字がついているように、我々は宇宙人１をヒトと考えるであろう。ならば、何を持ってヒトという呼び方が認められたり認められなかったりするのか？

ヒトか否かの判定に、生物種は関係ないだろうことは宇宙人１の例で示した。だが、ヒトという呼び方は生物種しか超越できないのだろうか？

チューリングテストではないが、隣にいるロボットが十分に、人間とも宇宙人１とも共通する何かを持っていたのならば、その何かが今のところ明言されてないだけで、それがあればおそらくロボットをヒトと呼んでも構わないはずだ。実際には明言されてないわけでもなくてSF小説の中ではいくつも議論されてるけど。

で、まあ、勉強しないといけないものが多かったり、コンピューター上の作業環境を変えたりとか、サボってたりとかいろいろ理由があってほとんど進んでなかった私の研究は、結構その辺の一部に関すること。それを今日から本格的に開始しようかと思う。

NWC計画

とか名前付けてみようかな(wcってあるけど、トイレじゃないよ）。

別段、特別な理由も、使う目的もあるわけではありませんが、頭の体操的にプログラミング言語を考えています。

これが結構難しい。新しさや変わったものである感じ、読みやすさ、書きやすさ、処理系での処理のしやすさとか、そのバランスとかが難しい。既存のプログラミング言語とほぼ一緒なら、頭の体操的にもあまり意味はありませんし。考えてるだけでも、計算モデルとかの勉強になリますね。そこそこおもしろいです。

本来なら、計算モデルあたりから考えて、そのモデルの試験的実現として処理系を作るという流れがいいのでしょうけど。でもそれでは面倒だし。まぁ、頭の体操的なものだし。

例えば、concatenativeな言語ということで考えてみます。Concatenativeな言語を例に挙げるのは別に特別な理由はありません。なんとなく思いついただけです。

Factorのif文はこんな感じになります。

10 3 < [ "Math is broken" print ] [ "Math is good" print ] if

Joyのif文はこんな感じ。

[1000 >] [2 /] [3 *] ifte

Concatenativeの元祖みたいなFORTHのif文はこんな感じ。

条件式 IF 真文 THEN
とか
条件式 IF 真文 ELSE 偽文 THEN

まぁ、それぞれですが、Concatenativeであることとか、スタック型とか、RPN的であるとかを突き詰めると、FactorやJoyみたいな感じになる。でも、これって、条件が真の時や偽の時の処理内容が長くなると、あるいはそうでなくとも、どこからどこまでがif文の範囲なのかが分かりにくい気がする。というか、読んでいて、これは一体何が書かれているのかが、あとの方にならないと分からない。Forthの場合、IFとかは実は処理をしてない感じ。条件の真偽はすでにスタック上にあるので、その段階でIFがなにかするような必要は特にない（実際には真偽によってジャンプしたりしなかったりという処理を行なっている)。中身が無い命令というか、単に「IFブロックですよ」というラベルみたいなものを書くというのは、なんか気持ちが悪い気もする。でも、読みやすさを考えると、FORTHの方がよさそうな気もする。

あとは、Ruby的にいろいろな書き方ができる方が好きか、Pascal的あるいはPython的に特定の書き方しか認めない方が好きかとか。

プログラミング言語を考えるのは、いろいろな条件が絡み合っていて、頭の体操としては面白い。実際に処理系を作るのは面倒だけど。何かに処理系を組み込むことになったら、既存の言語に新たに必要な分を組み込んだ処理系を使うと思う。

どうも、新しいディスプレイでの表示の見えやすさの調整が難しいなぁという感じでした。

で、マニュアルを読んでみたところ、ICC(国際カラーコンソーシアム)が規定しているICCプロファイル(*.iccというファイルみたい)が使えるとのこと。メーカーのページからダウンロードできるようなので、早速ダウンロードしました。Linuxのドライバが対応してるかどうかの不安はありましたが。

ダウンロードの後、findでそれっぽいディレクトリを探して、そこに放り込んだところ、LinuxというかFedoraというかGNOMEというかの設定プログラムでもそのICCプロファイルを認識している様子。早速、そのプロファイルを選んでやりました。ドライバも反応している様子。

結果として、確かに、無いより使う方が良い感じがします。例えばですが、gmailのスターで、多色というかなんというかを使えるようなオプションを使っているのですが、その例で。iccプロファイルを読み込む前は、赤いスターの色が黒ずんでいるような感じでした。どうにかならないかなと思っていたのですが、ICCプロファイルを読み込んだ後では、なんか良い感じの赤になってます。

まぁ、色の再現性の問題は根深いので、ICCプロファイルみたいなもので調整が必要なのだとは思います。でも、ディスプレイで、先の赤のように、ICCプロファイルがないと色の加減がどうにもおかしいというのはいかがなものか。こちらはディスプレイにそれほど色の再現性は求めていないということもありますが、ICCプロファイルがなくてもデフォルトとかでそれなりに良い感じになってくれるのが良いと思うのですが。

あとは、人や目的にもよると思いますが、くっきりはっきり表示されるのが好きとか思って、ディスプレイ自体の設定で、シャープネスあたりの設定をきつくしすぎると、却って見えにくくなるというのも経験しました。このあたりはメーカーや製品でいくらか違いはあるでしょうけど。

快適に使うには、もう少しディスプレイの設定をいじってみるといいのかもしれません。