本の虫

2013-12-24

アラン・チューリングに恩赦

BBC News - Royal pardon for codebreaker Alan Turing

1952年、ホモセクシャリティ罪で検挙され、保護観察下におかれ、しかも化学的去勢を行われた、暗号解読者にして、コンピューター科学にも多大な貢献をしたアラン・チューリングに対し、ホモセクシャリティ罪に対する恩赦が与えられた。

あまりにも遅すぎる。

2013-12-23

人との再会は難しい

今、筆者は東京にいる。東京は、人の集まる場所である。実に、大勢の人間が地方からやってくる。

結局、一極集中は効率的なのだろう。それに、地方には仕事がない。

ということは、田舎に住んでいた頃の私の昔の同級生は、東京に住んでいる可能性があるわけだ。

せっかく東京に滞在しているのだから、そのような昔の同級生だった者と再会し、つもる話をもし、成功したのか失敗したのか、近況を聞きたいものだ。

筆者はすでに、京都に住んでいて、昔の友人と再会したことがあるのだ。それは友人側からこのブログをみて連絡が来た。

実は、ネット上で検索した結果、そういう人間が一人だけ、少なくとも去年は東京で働いていたらしい。特別に仲が良かったわけではないが、当時、同じ町内に唯一住んでいた同級生なので、印象には残っている。

ただし、連絡方法がない。いや、あるにはある。実家に紙の手紙を送るという方法がある。しかし、そこまでして会いたいかというと、なかなか難しい。

その同級生が女であることも、連絡を躊躇させる要因となっている。

2013-12-22

アニメにおけるセルシェーディングの利用について

セルシェーディング技術は、非常に発達している。3Dモデルを描画する際、あえて似通った領域を単色で塗りつぶすようにするのが、極端な簡略化した説明だが、とにかく、いかにも3DCGという奇妙な違和感を消し、まるでアニメ塗りのような描画ができる。

ゲームでは、セルシェーディングはよく使われている。例えば、不自由なゲームだが、最近のゼルダの伝説や、Borderlandsといったゲームだ。

では、アニメではどうなのか。実は、意外と積極的には使われていない。

たとえば、プリキュアというアニメでは、エンディングの映像に、セルシェーディングが使われている。非常に高品質で、しかもヌルヌル動く。プリキュア本編はまったくつまらないのだが、、エンディングだけはとても面白い。しかし、本編には、ごく一部の、動きの激しいシーンなどにしか使われていないという。しかも、手で修正を加えた上、フレームも極端に間引いているという。しかし、現に修正をくわえずともそれなりの品質になっているではないか。なぜフレームを間引かずに、大規模な手動の修正も行わずに、そのまま使わないのか。

なぜだ。なぜ手動風の劣化を加える必要があるのだ。なぜぬるぬる動くアニメにしないのだ。

プリキュアを見ていると、明らかに全面的に手で書かれた場所が出てきて、そのような場所は、フレーム単位でみると、とても作画品質の低いことがある。これは、俗に「作画崩壊」と呼ばれている。それに、肝心のアニメーション自体も貧弱だ。しかし、セルシェーディングならば、常に一定した品質を提供できるではないか。なぜセルシェーディングにしないのか。

ある者曰く、ぎこちないアニメーションのほうがむしろ自然なのだという。しかし、トムとジェリーは、ヌルヌルと動くアニメーションで、それでいて最高に面白いではないか。

多くのアニメでは、徒手格闘が出てくる。そういうシーンを、ぬるぬる動くアニメーションに、なぜしないのか。映画マトリックスのようなものがある以上、そこそこの品質でぬるぬる動くアニメーションのほうが素晴らしいと思うのだ。手動で描くと、作画は悪いはアニメーションは悪いはと、劣化でしかないと思うのだ。

あるいは、映画は24 Frame Per Secondで撮影しないと、映画らしくならないという話と似たようなものなのだろうか。つまり、我々が、映画なら24FPS、アニメなら作画崩壊貧弱アニメーションに慣れてしまっているので、あまりにも高品質すぎる物を見せられると、違和感が生ずるのだろうか。

しかし、現に私は、プリキュアに関しては、本編の人の手による悲惨な劣化作画と見るに耐えない劣化アニメーションよりも、、エンディングのセルシェーディングされてヌルヌル動く映像のほうが、圧倒的に高品質であると感じる。圧倒的に魅力がある。もし本編がこのように作られていたならば、ぜひとも見たいと思う。現に、プリキュア本編は見るに耐えない内容であったが、エンディングの映像だけは食い入るように眺めてしまった。なかなか悪くないセルシェーディングだからだ。

あるいは、人の手で描かれたものを尊ぶ風潮でもあるのだろうか。しかし、それならばもっと抽象的で極端なデフォルメの絵にすればいいわけで、プリキュアはまだその抽象度とデフォルメ度が十分ではない。それよりは、セルシェーディング技法に技術的観点から興奮すべきではないのか。

もちろん、エンディングは繰り返しつわれる短時間の映像だから、セルシェーディングした後に、手動でフレームごとに修正を加えているのかも知れない。しかし、私は近年のセルシェーディング技法の発達を知っている。もちろん、セルシェーディングもそのようなシェーダーを書くのは職人技だが、フレームごとにひたすら手動でやるよりも、よほど筋のいい職人技だ。一度素晴らしいシェーダーを書けば、それにより全体が向上する。

そういう意味では、アニメは完全にセルシェーディングにして、ビルドして映像生成という形にすべきではないのか。すなわち、ソフトウェアだ。ソフトウェアである以上、自由ソフトウェアにすべきだ。そうすれば、稚拙な3Dメッシュが直されたり、シェーダーが改良されたりするのではないか。

いい加減に人の手で努力しただけのものを評価するのは、やめようではないか。もはや、写実画は写真に負けている。人間がまだ優位に立てると安心しているデフォルメの世界だって、例えばアニメ塗りのようなものは、セルシェーディングで近似できる。セルシェーディング技法は今後もますます発展することに疑いはなく、人間の優位性はいよいよ危うい。

将来は、ピカソのような絵や、デフォルメ化された3Dメッシュなども、自動的に生成できるようになるだろう。

私の観測できる範囲では、プログラマーとアニメの親和性は高い。私はアニメが好きではないから、これは不思議なことだ。私には、なぜ彼らがアニメを尊ぶのか、理解できない。現行のアニメが、単に人の手による単純作業で作られている。アニメ制作者が安く買い叩かれているのは、やはり、ある程度の画力があれば、代わりはいくらでもいるような単純作業だからだろう。

変えようではないか。現状を。アニメは技術者が作ればいいのだ。作画は3Dメッシュに取って代わられる。塗りはセルシェーディングに取って変わられる。高品質な3Dメッシュを作成するのは困難だが、一度作成してしまえば、後はアニメーションを作ればどのようなシーンもアニメーションできる。破綻しない自然な塗りをシェーダー言語で記述するのは困難だが、一度書いてしまえば、後はどのようなシーンでもレンダリングできる。

怠惰は美徳である。機械的な作業は機械に任せようではないか。もし、ある手動作業が自動化できるとするならば、我々はむしろ自動化するための準備に労力を注ぐべきなのだ。そうすれば、後は全て自動化される。我々人間は、機械を作るべきなのだ。その身を機械におとしめてはならない。

なるほど、私がアニメを好まない理由が、今にしてわかった。アニメは手動の単純作業だから感動しないのだ。そして、その映像の描画方法、すなわちソースコードが公開されていないから嫌悪するのだ。ああ、残念ながら、この考え方はあまりにも先進的すぎる。おそらく、数百年は理解されないことだろう。

ただし、2013年にこのような考えを持つ進んだ一個の人間がいたということは、ここに記しておく。

2013-12-21

Google、Chrome Web Storeから多目的の拡張を禁止する

GoogleはChromium Blogで、Chrome Web Storeから、複数の目的を有する拡張を禁止する発表を出した。

Chromium Blog: Keeping Chrome Extensions Simple

本日、我々はChrome Web Storeポリシーの変更を告知する。Chrome Web Storeの・拡張は、必ず、狭く簡単に理解できる単一の目的を有さなければならない。これはChrome拡張システムの意図であるが、すべての拡張はこの理想に従っていない。奴ら、多目的拡張(mutli-purpose extensions)は、ブラウザーのUIをごちゃごちゃとさせ、Webブラウジングを愚鈍にし、時には悲惨なことになる。我々はこの問題を修正し、ユーザーにブラウザーの支配力を与えるために、今回のポリシー変更を行った。

簡潔で高速なブラウジング体験は、Chromeのはじめからの、基本理念である。簡潔性は我々にとって重要なことで、その理由は、ブラウザーはとても複雑になり、重量級のユーザーインターフェース（俗に"chrome"（ブリキ化）と呼ばれている）を持っているからだ。この複雑なUIは、ブラウザーのそもそもの存在理由である、ページ内のコンテンツから注意を空してしまう。"Chrome"という名前は、我々は「コンテンツ」に注力したいというこの理念からきている。

現在、ブラウザーの重量化に強力に貢献しているのは、万能ツールバーのような拡張だ。ユーザーが複数のそのようなツールバーをインストールした結果は、悲惨なものになる。

我々の簡潔性の理念を維持するため、我々は異なるアプローチをとることを決定した。Chrome拡張は自然に簡潔で単一の目的用になり、単一のbrowser actionか単一のpage actionという、単一の可視UI「サーフェイス」しかサポートされない。ツールバーは設計上サポートされず、ユーザーはこれによりブラウザーに追加する機能について一層のコントロールを得ることとなる。

残念ながら、一部で、このような設計を技術的に矯正できない。 content scriptにより、拡張の開発者はページに対する完全なコントロールを得、結果として、どんなUIでも実現できる。たとえ、ツールバーをページに作成するような機能であったとしてもだ。他には、content scriptを使って、多数の機能がごちゃまぜになったような、どのような拡張とも分類しがたいものをつくりだす。多くの場合、Chrome Web Storeは、ある拡張が変な挙動をしていることを、低評価により示しているが、そうでもない場合もある。

なお悪いことに、拡張がローカルのコンピューターに、間接的に読み込まれた時（たとえば、他のインストールしたソフトウェアに同梱されていたなど）、ユーザーはChrome Web Storeの恩恵を受けることができない、そのため、望まない機能や低評価の拡張のインストールにユーザーが同意したことに気が付かないことがある。

このため、当初の単一目的の設計を強制させるため、Chrome Web Storeのポリシーを変更した。我々は、これにより既存の拡張に大きな変更が必要になることを承知している。一部の拡張は、複数の拡張に分離する必要があるだろう。開発者は、我々が追加した、拡張への送金方法を簡単にする方法に変えて、別の方法による課金方法に切り替えないといけないだろう。これらの変更には実装に少し時間がかかるため、2014年6月まで強制を見送る。新しい拡張については、このポリシーは直ちに適用される。

Googleもだいぶ邪悪になってきたようだ。ある拡張がどう実装されようとどうでもいいわけで、これはユーザーにコントロールを与えるなどというのは詐欺もいいところだ。問題の本質は、Windowsにまともなパッケージマネージャーがないことに起因すると思うのだが。

Google announces ban on "multi-purpose" Chrome extensions | ZDNet

Google announces ban on "multi-purpose" Chrome extensions | Hacker News

2013-12-19

2013年12月16日から17日の日記

16日

いつも通り、吉田寮で起床。最近、私は吉田寮に入り浸っている。吉田寮は人を選ぶが、私にとっては、とても居心地のいい空間なのだ。

今日は、はてなのセミナールームを借りて、勉強会を行う。また、狂える中3女子ボレロ村上さんを案内しなければならない。ひとまず自宅に戻って身支度をした。

午前中は、修理に出していたJ-PRESSのダッフルコートを取りに行った。これから一週間ほど東京に行くので、なにかまともなコートがほしいと思っていたのだ。実家には、父親があまり着ていない昔のコートがある。もう30年ほど前に、当時7,8万で買った、いいコートだ。今は、もはやこんないいコートは金を出しても買うことができないという。何でも、復刻版があるそうだが、父親いわく、どうも劣化しているとのことだ。合皮のような革で、水牛のツノもまるでプラスチックのような見た目だという。

このダッフルコートは、生地の端を布で覆っているのだが、その布がボロボロになってしまっている。私はそれでもいいと思うのだが、父はこだわる人間で、着るならばと修理に出すことにしたのだった。

ただし、これを修理するには、一度服をバラバラにして、再び縫い合わせなければならない。技術的には可能なのだが、とても手間がかかる作業だ。材料費こそ三千円程度なのだが、あまりにも手間がかかるため、結局3万円ほどかかってしまった。三万あれば、普通のコートは買えるだろう。しかし、このコートは買えない。このコートは三万出してまで治す価値のあるコートだ。

王将で餃子を食べて家に帰ってみると、なんと、ボレロ村上さんが、予定より早く、すでに京都駅に着いているという。私は急いで京都駅に向かった

聞説、ボレロ村上さんは長髪で作務衣を着用しているという。京都駅でそのような人物を探すが見つからない。はて、どうしたものか。携帯電話を持たない私にとって、唯一の通信手段はラップトップとモバイルWiFiルーターだ。そのような大掛かりな通信装置を広げるのは面倒だが、見つからない以上、やるしかない。と、そう思いかけた瞬間、とても筋骨たくましい男が声をかけてきた。なるほど、最近の中3女子はだいぶ屈強な体格をしているのだな。長髪ではあるものの、作務衣ではない。まあ、今の季節に作務衣はいかにも寒すぎる。

我々はバスに乗って吉田寮へと向かった。吉田寮は人を選ぶ場所である。果たしてボレロ村上さんは吉田寮を受け入れることができるのか、それは気がかりではあったが、この漢であれば、問題はないだろう。

さて吉田寮に到着し、暖房の入った部屋に通したボレロ村上氏は、おもむろに外套を脱ぎ始めた。するとみよ、なんと氏は、外套の下に作務衣を着ているではないか。今にして筆者は、氏の陶芸家としての姿を目にしたのだ。

さて、しばらく吉田寮でだらだらと過ごし、たこ焼きを食べた後、我々ははてなのセミナールームに向かった。そして、C++の勉強会を開催した。

勉強会というものは、今、とても流行している。筆者もC++の啓蒙活動をしている身で、過去に二回、勉強会で発表したので、やはりここは、勉強会を主催してみるべきだと考えたのだ。

結論だけ書くと、勉強会を個人で開催するのはとても難しい。今回は、はてなが場所と人を提供してくれたので、便利にもUstreamによる配信付きの勉強会を開くことができたが、長期的には色々と工夫しなければならない。

詳しい内容については、以前の記事を参照してほしい（もちろん、すでに終わった勉強会であるので、申し込みはできない）

本の虫: 江添とボレロ村上の京都C++勉強会、開催の告知と参加者募集のお知らせ

本の虫: 江添とボレロ村上の京都C++勉強会のスライド資料

本の虫: 江添とボレロ村上の京都C++勉強会を終えて

さて、勉強会を終えて、ボレロさんを囲んで吉田寮で鍋をつつくことにした。ボレロさんは吉田寮との親和性が高く、初日にコタツで寝るという離れ業を披露してみせた。

17日

吉田寮で起床、というか昼ごろまで雑談

ボレロ村上さんは、本当に吉田寮との親和性が高く、我々が大声で雑談している中、ぐっすりと熟睡していた。なかなかに常人のできることではない。

その日の雑談はとても面白く、もっと話していたかったのだが、残念ながら私は用事があるので、昼ごろに抜けて、身支度をし、夕方過ぎに東京へと向かった。

明日は朝早くから色々と用事があるので、その日は早めに就寝。

続く

Ubuntu 14.04がTRIMをデフォルトで有効にする

[Phoronix] Ubuntu 14.04 Finally Enables SSD TRIM By Default

Ubuntu 14.04が、SSDのTRIMをデフォルトで有効にするそうだ。

Linuxカーネルは2.6.33からTRIMをサポートしているが、これを有効にするには、discardマウントオプションを指定する必要がある。Ubuntuは、デフォルトでこのマウントオプションを有効にしていなかった。

「十分なテスト」の結果、Ubuntu 14.04では、TRIMをデフォルトで有効にする決定がなされた。

2013-12-17

clang_completeのvimプラグインの開発が停滞中

Clang_completeという、Clangを使ったCファミリー言語の静的解析ツールがある。これは、Clangの素晴らしいフロントエンドをそのまま使い、高度で規格準拠な名前補完機能を提供してくれるツールだ。

このclang_completeを、Vimという最高のテキストエディターから使えるようにするプラグインがある。

Rip-Rip/clang_complete

ところが、このプロジェクトは、最近開発が停滞しているようだ。例えば、以下のような簡単な修正のPull Requestすらマージされずに半年放置されている。

Fixup jumpToLocation loc.file is NoneType by visitor83 · Pull Request #336 · Rip-Rip/clang_complete

Silex commented

@xaizek: このプロジェクトの状況はどうなっているんだ？　この程度のものはマージされるべきだろ。@Rip-Ripのアクティビティをみるに、最近は何もしていないみたいだな。

xaizek commented

@Rip-Ripのアクティビティは、この春からみてないな。たぶん、今はプロジェクトを保守する時間もないんじゃないか。

さて・・・いずれVimのプラグインの開発方法も学ばなければならないな。

江添とボレロ村上の京都C++勉強会を終えて

江添とボレロ村上の京都C++勉強会が、無事終了した。

今回の勉強会にあたって、一番苦労したのが、場所の確保である。勉強会を開催するには、数十人を格納できる場所がなければならない。さらに、単に場所だけでは不十分で、椅子、テーブル、プロジェクター、電源、無線LANが提供されていなければならない。

勉強会での発表には、スライドを映す必要があるので、プロジェクターは必須である。

さらに、聴衆もラップトップは使いたいであろうし、インターネットにも接続したいだろうから、電源と無線LANも提供されていなければならない。となると、椅子とテーブルも必要である。

勉強会の主催は相当に面倒だが、やはり、変化しなければならないと決めた以上、新しいことをやらなければならないのだ。

私は人前でスカスカのスライドを映して口頭で60分ほど話すことによる教育効果には疑問だ。まず、スライドというのはそれほどの情報量を含めることができない。たまに、アホなスーツが情報のぎっしり詰まったとても読みづらいスライド資料を使うことがあるが、あんなものは到底読めたものではない。それゆえ、スライドは自然とスカスカとなる。それに、口頭で使える情報は、とても伝達効率が悪い。まず、人間の話す速度は遅いという問題がある。それに、私は弁舌の徒ではない。

したがって、勉強会というのは、具体的な詳細を解説するのではなく、こういうものもあるという紹介程度の内容にならざるを得ない。ことC++においては、その情報さえ、日本語では不足しているということもあるだろうが。

とにかく、勉強会に使える場所を確保しなければならない。色々と探したあげく、京都駅の近くに、プロジェクターと電源と無線LANがついて、一時間三千円で借りられる部屋を見つけた。

京都の貸し会議室・レンタルスペース｜ベーコンラボ

収容人数が、テーブルを出すと20人、椅子だけで最大38人ぐらいと、ちょっと狭いのだが、京都駅の近くなのでわかりやすいし、何より、プロジェクター、電源、無線LANの条件を満たす部屋というと、京都市内は本当に少ないのだ。

当初はベーコンラボを使おうと思っていたのだが、にわかに京大の教室を借りるとか、はてなのセミナールームを借りるなどという話が出てきた。

京大の教室は、土日も借りられるし、なにしろ大学の教室なのだから、プロジェクターと電源と無線LANはあるし、それに100人ぐらいが入れる大部屋もあるという点で、とてもすばらしいものだ。日本の大学機関はそういう立派な設備を持っていながら、なぜC++のような実用的な言語を教育できる人間がいないのか。理解に苦しむ。聞けば、京大では初年度にSICPをやり、二年目にC言語をやるのだそうだ。C言語！　ああ、C++はC言語を改良し、なおかつC言語と同じシステムプログラミングを提供できるように設計されてきたというのに。

そして、さらにひどいことに、京大ではJavaのような一個の民間企業に独占された不自由で使いにくい言語を教育しているという。これはありえないことだ。C++にはそのような独占がないからこそ、安心して使えるのだ。しかも、Javaはその機能からして明後日の方向に向かっている。単にアルゴリズムやデータ構造を記述するために書きやすく、しかも実用的な言語というのであれば、今は便利な言語も多いというのに、なぜあのようなクソみたいな設計のJavaを選んでしまうのか。背景には、即戦力になる安い組み込みプログラマーを量産したいという業界の思惑があるらしい。情けないことだ。

はてなのセミナールームは、すこし条件が厳しい。プロジェクター、電源、無線LANこそ提供されているものの、椅子だけ並べて収容人数が40人（一応、机もあり、さる有名なCプリプロセッサーメタプログラマーは空気を読まずに使っていたが）、それも、土日はだめで平日の夜のみという、難しい条件だ。

平日の夜というのは、多くの職業プログラマーの参加を難しくしてしまう。それに、午後7時から始まる都合上、使える時間がせいぜい二時間ぐらいと短いので、そう何人も発表できない。

ただし、はてなのセミナールームには、この悪条件を吹き飛ばす、ある特別な設備が備わっている。Ustream配信のための設備だ。なんと、はてなは当日の勉強会をUstreamで配信してくれるという。

USTREAM: hatenatech

Ustreamとは、動画配信のためのプラットフォームで、閲覧者に不自由なFlash Playerを要求する邪悪なSaaSSである。そのため、一般的に言って、読者はUstreamを使うべきではない。

しかし、勉強会というのは所詮、物理的な場所で開催しなければならないわけで、場所をどこにしようとも、遠方であるために参加できない人間が出てくるものだ。開催日時を土日にしたところで、やはり物理的に己の肉体をその場所に持っていく都合のつかない人はいる。Ustreamのような閲覧に不自由ソフトウェアを要求するSaaSSは、紛れもなく悪であるが、この場合、もたらす善もゼロではないのではないか。

悩んだ挙句、今回は、はてなのセミナールームを借りて勉強会を行うことにした。

そして、講演者は、私ともう一人、コンパイル時プログラミングの権威、ボレロ村上に依頼した。当日の勉強会の動向は、近いうちに、日記として公開する。

将来的には、自分でカメラを用意して録画し、自由な動画、音声、コンテナーフォーマットで公開するべきだろう。ただし、そのためには私以外の撮影者が必要だ。それに、今回は初めて自分で主催する勉強会なので、そこまで手を広げることもできない。まず何としても、勉強会を計画し、場所の手配をし、告知して人を集め、発表して無難に終えるという、一連の仕事をこなさなければならないのだ。

少なくとも今回、積極的に新しいことをやり始めた結果、色々と可能性が広がってきた。京大の教室を借りての勉強会も、来年に行うよう調整中だ。現在の予定では、来年の春休み、つまり2月末から3月にかけての休日の昼間に、京大の教室を借りて勉強会を行うよう、調整中だ。内容は、今回のようにC++14の新機能でもいいし、あるいはなにか別のものでもいい。

さて、今回初めて、勉強会を主催した経験からいうと、勉強会を個人の力で開くのは色々と難しい。勉強会は最近の流行だが、実際に開催しようとすると、普通の営利活動では、到底正当化できないほどの費用と手間がかかる。私が今後もC++の啓蒙活動を続けるためには、どういう形であれ、私に金が入らなければならない。結局、私は霞を食べて深山に修行するわけにはいかないのだ。しかし、勉強会は、営利目的としてはいかにも無理だ。

やはり、さらなる劇的な変化が必要なのだろう。

2013-12-16

江添とボレロ村上の京都C++勉強会のスライド資料

今日の勉強会の、ボレロ村上さんの発表に使う資料が公開された。

すごい constexpr たのしくレイトレ！

江添によるスライド資料

C++14の新機能

まだ少し人数に余裕があるので、早いうちに参加申し込みをすれば、まだ間に合う。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

2013-12-15

xkcd: gitコミット

xkcd: Git Commit

メインループ作成＆タイミング処理

設定ファイルのパース有効化

細かいバグ修正

コード追加/編集

もっとコード

それ、コード

ああああああああ

くぁｗせｄｒｆｔｇｙふじこｌｐ；

なにか適当に入力

手ーーーーーーー

プロジェクトが進むにつれて、俺のgitコミットメッセージが適当になっていく。

さもありなん。

xkcd What if?: 液体の水銀や臭素やガリウムやタングステンや窒素やヘリウムの上でボートをこぐとどうなるの？っと

エクストリーム・ボート

水銀の湖の上でボートをこぐとどうなるの？　臭素は？　液体ガリウムは？　液体タングステンは　液体窒素は？　液体ヘリウムは？

–Nicholas Aron

一つづつみていくことにしよう。

臭素と水銀は、室温で液体になる唯一の純粋な元素だ。

水銀の海の上でボートをこぐのは、おそらく可能だ。

水銀はとても密度が高いので、鋼鉄球すら水面に浮かぶほどだ。

ボートは浮きすぎて、水銀にあまり沈まないかも知れないので、パドルに体重をかけなければ水面下に棹させないかもしれない。

結論としては、ちょっと難しいかも知れないし、あまり早く焦げないかも知れないが、おそらく水銀上でボートをこぐのは可能だろう。

読者は水かけ合戦をしないほうがよい。

臭素は水とほぼ同じ密度を持っている。そのため、標準的な手こぎボートは、理論的には、浮かぶはずだ。

ただし、臭素は悲惨だ。まず第一に、臭いがひどい。臭素(bromine)という名前は、古代ギリシャ語の"brōmos"から来ていて、意味は「臭う」だ。それだけではなく、臭素は、多くの物質と激しく反応する。読者はアルミニウム製のボートを使うのはやめておいたほうがよい。

これでもまだやめる気にならないのであれば、臭素の物質安全データシートには以下の文面があることを記しておこう。

深刻な火傷及びに潰瘍

消化器官の穿孔

永続的な角膜混濁

空間識失調、不安感、失望感、筋肉協調運動不能、情緒不安定

血を伴う下痢

読者は臭素の湖で水かけ合戦をしないほうがよい。

液体ガリウムは不思議な物質だ。ガリウムはバターのように、室温の少し上の温度で溶ける。手のひらの上で長時間保持することはできない。

それなりの密度はあるが、水銀ほどの密度はないので、ボートをこぐのは水銀よりは簡単だろう。

ただし、これも、アルミニウム製のボートはやめておいたほうが良い。なぜならば、アルミニウムは、その他の多くの金属と同じく、あたかもスポンジが水を吸い込むように、ガリウムを吸収してしまうからだ。ガリウムはアルミニウムの中に急激に広がり、その化学的特性を変えてしまう。変化したアルミニウムは、とても脆く、湿った紙のようにちぎることができる。

水銀とガリウムに共通の性質で、アルミニウムを破壊してしまうのだ。

「ガリウムの湖でアルミニウムのボートを漕ぎだしちゃいけないよ」とは、筆者の婆ちゃんがよく言っていたことだ（筆者の祖母はすこし変わっていたのだ）

液体タングステンは難しい。

タングステンはどの元素よりも融点が高い。これはつまり、我々はその特性について、あまりよく知らないということである。特性を検証できない理由は、すこし馬鹿げたように思えるかも知れないが、液体タングステンを保持できる容器がないためである。並大抵の容器では、タングステンが溶けるより先に、容器を構成する物質が溶けてしまう。炭化タンタルハフニウムのようなごく一部の化合物のみが、わずかに高い融点を持つだけだ。ただ、そのような化合物で液体タングステン用の容器を作成できた者はいない。

液体タングステンがどのくらい熱いのかということを実感させるために、その具体的な融点の温度(3422℃)を書くということもできるが、以下のように説明したほうがわかりやすいだろう。

液体タングステンはあまりにも熱いため。もし溶岩に滴下したならば、溶岩はタングステンを凍らせてしまうのだ。

言うまでもなく、もし読者が液体タングステンの海にボートで漕ぎだしたならば、読者とボートは両方共、瞬時に発火炎上するだろう。

液体窒素はとても冷たい。

液体ヘリウムはさらに冷たいが、どちらも絶対零度に近く、南極の最低温度よりも下だ。そのため、ボートで漕ぎだす目的のためには、温度の違いは瑣末なものだ、。

液体窒素の安全性に関するDartmouth工業ページには、以下の文面が並ぶ

有機物と激しく反応

爆発する

室内の酸素を減らす

激しい着衣の炎上

前兆なしの窒息

液体窒素は、水に近い密度を持っている。そのため、手こぎボートは浮かぶだろう。ただし、読者は長時間生存できないだろう。

もし、実験開始時点で、窒素の上の空気が室温であったならば、急速に冷却され、読者とボートは、空気が凝縮された濃い霧に覆われて窒息するだろう。（これは液体窒素をそそいだ時に発生する湯気と同じ効果である）。凝縮は凍結を引き起こし、読者をボートを急速に雪に埋もれさせるだろう。

暖かい空気は、窒素の表面を蒸発させる。これは湖面の酸素を減少させ、読者は窒息するだろう。

もし、空気（あるいは窒素）が、蒸発を防ぐほど十分に冷たいのであれば、読者は低体温症により、死亡するだろう。

液体ヘリウムはさらにひどい。

まず、液体ヘリウムは水の8分の1しか密度がないため、自重を支えるために、読者のボートは8倍の大きさを有していなければならない。

「俺らにはでっかい船が必要だ」
「まあでも、サメは問題にならんよな」

ただ、ヘリウムは厄介だ。もし、2度ケルビン以下に冷却された場合、超流動になる。これには不思議な特性がある。毛細管現象により、容器の壁を登り上がるのだ。

約秒速20cmほどで登るので、30秒以内に、ボートの底に液体ヘリウムがたまり始める。

液体窒素の時と同じく、低体温症により急速な死をもたらす。

ひとつ慰めになるとすれば、横たわって死につつある中、読者はとても奇妙な現象を観察することになるだろう。

読者の体を急速に覆いつつある超流動のヘリウムの層は、ほとんどの物質と同じく、音波を伝える。しかし、液体ヘリウムには全く別の形の波、ヘリウムの層をゆっくり伝わる波があるのだ。これは超流動でしか観測されていないもので、不思議で詩的な、第三の音という名前が与えられている。

読者の鼓膜はもはや機能しておらず、そもそもこの種類の振動を検出することはできないだろうが、巨大なボートの床の上で凍てついて死につつある読者の耳には、人間が未だかつて聞いたことのない、第三の音で満たされていることであろう。

これは、少なくとも、とってもクールだ。

C++03とC++14の違い: ライブラリ導入編

京都C++勉強会の宣伝のために、C++03とC++11の違いを、少しづつ解説することにした。

今回は、ライブラリ導入編だ。ライブラリ導入(Library Introduction)とは、C++の標準ライブラリを使うにあたっての約束事を定める章である。たとえば、予約されている名前なども、ここで定められている。

新しい予約された識別子

C++11/14では、新しい標準ライブラリのために、多くの識別子を導入した。既存のC++03のコードで、たまたまその識別子を使っているコードは、名前の衝突を起こす可能性がある。

とはいえ、識別子はほとんどstd名前空間スコープの下にあるし、マクロ名もきぞんのコードと衝突を起こさないように注意深く命名されているので、通常は問題になることはない。

新しいヘッダー

C++11/14では、多くの新しいヘッダーが追加された。

C++の新しくつかされたヘッダーは以下の通り。

また、最新のC言語規格に合わせて、以下のヘッダーが追加された。

<ccomplex>, <cfenv>, <cinttypes>, <cstdalign>, <cstdbool>, <cstdint>, <ctgmath>, <cuchar>.

たまたま、同じ名前のヘッダーを使っていた場合、問題になるだろう。しかし、ヘッダーの名前も注意深く選ばれているので、通常は衝突することはないだろう。

std::swapのヘッダーが<algorithm>から<utility>に変更

std::swapを使うコードは、C++11からはutilityを#includeしなければならない。

予約された名前空間posixの追加

posixという名前の名前空間が、あらたに追加された。これは、現時点では空っぽだが、将来使うために予約されている。

もし、posixという名前の名前空間をC++03のコードで使っていた場合、互換性の問題がある。

マクロ名として名前キーワードの追加

attribute tokenとして使われている、override, final, carries_dependency, noreturnは、マクロ名として使うことができない。

もし、このような名前のマクロ名を使っている場合は、互換性の問題がある。

そもそも、まともなC++プログラマーはCプリプロセッサーマクロを使うべきではない。

江添とボレロ村上の京都C++勉強会が、12月16日に行われる。これを書いている時点では、まだ空きがあるので、最新のC++14の新機能と、コンパイル時レイトレーシングを勉強したければ、ATNDで参加申し込みをせよ。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

当日はUstreamによる配信もある

http://ustream.tv/channel/hatenatech

また、私の書いたC++11のコア言語を完全に解説した参考書もある。

Gumroadで購入： C++11参考書：C++11の文法と機能

今すぐ閲覧： C++11: Syntax and Feature

誤りがあればGitHubでPull Requestせよ: https://github.com/EzoeRyou/cpp-book

この参考書は、C++の規格のみを参照して記述しており、特定のC++の実装（コンパイラー）で確かめただけで合法、違法を判断する、世間一般によくある駄本とは根本的に質が異なる本である。本書に誤りがあるとすれば、

誤字脱字
筆者の規格文面の解釈間違い
規格文面の誤り

だけである。まだ、世の中の安定版コンパイラーはC++11の規格をバグフリーで完全に実装していない。

2013-12-14

SteamOSが公開された。

SteamOS FAQ :: Steam Universe

[Phoronix] SteamOS 1.0 Is Based Upon Debian Wheezy

[Phoronix] SteamOS Has Its Own Graphics Compositor

[Phoronix] SteamOS Compositor Details, Kernel Patches, Screenshots

[Phoronix] Former NVIDIA, Microsoft Developers Doing Lots Of The SteamOS Work

Valveの忌まわしきDRM付きの邪悪なゲームソフトウェア流通プラットフォームであるSteamに特化したGNU/Linuxのディストロ、SteamOSが公開された。

この不自由ソフトウェアの実行をたやすくしたSteamOSは、Debian Wheezyがベースとなっている。Debianを選んだ理由は、Valveがカスタマイズするものとしては、UbuntuよりDebianの方がやりやすいからだという。

nVidiaやAMDの最新版の不自由なグラフィックドライバーや、最新版のMesaがbackportされているという。また、LinuxカーネルもWheezyの3.2ではなく、3.10となっている。

SteamOSは、デフォルトのUIがBig Pictureモードとなっている。これは、Steamで遊ぶことに特化したUIだ。このBig Pictureモード自体は、GNOME上に構築されている。設定で有効にすれば、デスクトップに切り替えることもでき、普通のGNU/Linuxデスクトップ環境としても使えるそうだ。ただし、初期ではrootアカウントにパスワードがかけられておらず、デスクトップを有効にする際に、パスワードを設定する必要があるのだという。

ValveのFAQでは、passwordコマンドを使えとのことで、まだまだベータといった感じが漂う。

SteamOSは独自のグラフィックコンポジターを使っているという。独自というべきなのか、ややマイナーというべきなのか。その名前をXcompmgrといい、X11上で動作する。Xcompmagr自体は、Keith Packardが書いた、結構昔のコンポジターだ。とても軽いことが特徴で、利用者もいることはいるそうだ。最近は活動的ではなかったそうなのだが、いったいどういうことなのだろう。まあ、今すぐにゲームを実行する必要のある関係上、WaylandやMirのような、全く新しい実装という冒険はできなかったということか。ちなみに、上流のXcompmgrと、SteamOSのXcompmgrのdiffは、2400行になるそうだ。

SteamOSのLinuxカーネルは、linux 3.10 - PREEMPT_RT_FULLで、かなり大量のパッチを当てている。特にリアルタイムカーネル関連のパッチが多いのだとか。

初期化には、SysVinitを使用。今流行りのsystemdではなければ、UbuntuのUpstartでもない。ここも保守的だ。

AMD用のプロプライエタリなバイナリブロブのドライバーも入っているものの、現在のところ、nVidiaのGPUを推奨しているのだとか。

リアルタイムカーネル、X１１のグラフィックコンポジターで軽量に定評のあるXcompmgr、SysVinit、ゲーム用の固定ライブラリバイナリセット、だいぶ保守的でゲームの高速動作に特化したような思想が伺える。

私は使いたいとは思わないが、こんな制限的なシステムでも、もたらす善の方が大きいのだろうか。おぼつかなし。

2013-12-13

ECMAがDartを標準化すべく技術委員会を立ち上げた

[Phoronix] ECMA Is Working On Standardizing Google's Dart

ECMAがDartを標準化すべく技術委員会を立ち上げたそうだ。

Dartについては色々と期待している。何しろ、初期に公開した規格書が、まともにフォーマルな文面を用いていて、実に素晴らしかったからだ。

最近のDartの動向は追いかけていないが、なかなか面白そうではある。

ただし、それはDartの独立した実装が複数出てきてからの話だ。現状で、Googleの独壇場なのは危険だ。

C++03とC++11の違い: テンプレート編

京都C++勉強会の宣伝のために、C++03とC++11の違いを、少しづつ解説することにした。

今回は、テンプレートについて、C++03とC++11/14の違いを取り上げる。

C++11では、export機能が廃止となった。

exportは、実装例が極めて少なかったために、C++11では廃止となった。

この変更による互換性の問題は、ほとんどないだろう。というのも、export機能自体が使われていなかったのだから。

C++11では、入れ子となったテンプレートの連続したアングルブラケットの間に、空白文字を挟む必要がなくなった。

template < typename T >
struct S { } ;

// C++03では違法
// C++11では合法
S<S<int>>> s ;

C++03では、右シフト演算子、operator >>と文法上曖昧になるため、必ず空白文字を挟まなければならなかったのだ。

// 空白文字が必要
S<S<int>> > s ;

このような些細な文法上の問題は、利用者の混乱を防ぐために、コンパイラーの努力で何とかするべきだという意見により、C++11では、このような場合、演算子ではなくテンプレートのアングルブラケットだと解釈するようになった。

この変更により、C++03では、右シフト演算子と解釈されるために合法だったコードの解釈が変わってしまう。

template <class T> struct X { };
template <int N> struct Y { };

// C++03では合法、1 >> 2は右シフト式
// C++11では違法、文法上の誤り。
X< Y< 1 >> 2 > > x;

ただし、このようなコードは稀であろうから、おそらくは大丈夫だろう。

C++11では、内部リンケージを持つ関数を依存呼び出しできるようになった。

C++03では、非修飾名での依存呼び出しの際には、外部リンケージの関数しか考慮されなかった。内部リンケージの関数はオーバーロード解決に置いて考慮されなかった。そのため、以下のようなコードは、厳格に規格準拠のC++03の実装とC++11の実装で実行した場合、挙動が異なる。

void f( long ) { } // #1
static void f( int ) { } // #2


template < typename T >
void g( T x )
{
    // C++03では#1を呼ぶ
    // C++11では#2を呼ぶ
    f( x ) ;
}

int main()
{
    g( 0 ) ;
}

C++03では、外部リンケージの関数しか考慮されないので、#2が呼ばれることはない。C++11では、単に実装の簡単化のため、内部リンケージも考慮されることになったので、#2が呼ばれる。

このこととは直接関係ないが、依存呼び出しにおいては、プログラムの全翻訳単位の、その文脈で発見できない名前も含めたすべての外部リンケージを持つオーバーロード関数の候補で、もし、オーバーロード解決の結果、より最適な候補となる関数が存在した場合は、プログラムは違法となる。

例えば、unit_1.cpp, unit_2.cppという、2つのソースファイル、2つの翻訳単位からなるプログラムがあったとする。

// unit_1.cpp
void f( int ) { } // #1

// unit_2.cpp
void f( long ) { } // #2

template < typename T >
void g( T x )
{
    f( x ) ; // 依存呼び出し
}

int main()
{
    g( 0 ) ; // 違法
}

このコードは違法である。なぜならば、依存呼び出しで#2が最適関数となるが、別の翻訳単位で、名前は見つからないものの、より最適な関数があるために、プログラムは違法となる。

これは、テンプレートの特殊化が翻訳単位ごとに異なる結果となることを防ぐためである。

依存名というのは厄介だ。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

当日はUstreamによる配信もある

http://ustream.tv/channel/hatenatech

また、私の書いたC++11のコア言語を完全に解説した参考書もある。

Gumroadで購入： C++11参考書：C++11の文法と機能

今すぐ閲覧： C++11: Syntax and Feature

誤りがあればGitHubでPull Requestせよ: https://github.com/EzoeRyou/cpp-book

誤字脱字
筆者の規格文面の解釈間違い
規格文面の誤り

だけである。まだ、世の中の安定版コンパイラーはC++11の規格をバグフリーで完全に実装していない。

JavaScriptへVimを移植

Vim.js - JavaScript port of Vim

なんと、JavaScriptへVimを移植したのだそうだ。準備に時間がかかり、さらに反応も悪いが、たしかにこれはVimだ。いや、Vimそのものだ。

Hacker Newsでは、さっそく、Atwordの法則を引用するものがいる。Atwordの法則、「JavaScriptで書かれ得るプログラムは、いずれJavaScriptで書かれる。」

この法則は、Tim Berners-Leeの the Principle of Least Powerをもとにしている。Tim Berners-Leeは、WebでJavaScriptのような貧弱なプログラミング言語が使われていることを大変喜んでいる。なぜならば、JavaScriptは比較的簡単に解釈できるからだ。そのため、データやプログラムは、他人にも比較的簡単に処理できる。これがもし、Javaアプレットとか、Flashなどで書かれていたならば、なるほど、確かに見た目はいいかもしれないが、とても他人にとって使いづらいデータになってしまう。

Design Issues for the World Wide Web

歯の詰め物がとれた

自宅で遅めの昼食を認めていたところ、右下の歯の詰め物が取れてしまった。

思えば、ここは確か人生初に虫歯になって歯医者にかかったところだ。たしか、7,8年前だったと記憶している。保険の範囲内の治療で、7,8年持てば、まあ平均的といったところだろうか。

どうせこの箇所は、ここ数ヶ月、水を飲んだり、冷たいサラダを食べたりしただけで、わずかに痛むようになっていたので、そろそろ歯医者に行って、診てもらわなければならないと思っていたところなのだ。ただ、その痛むというのが、食べ始めのほんの数秒痛むだけで、痛み自体も僅かなものなので、ついつい放っておいてしまっていた。

しかし、冷たいものが痛むとか、食事で詰め物が取れたということは、中で虫歯にでもなっているのかもしれない。鏡でみてもわからないので、やはり歯医者に行かなければならない。

しかし、残念ながら、今日はあいにくと普段行っている歯医者が開いていない。幸い、土曜日もやっている歯医者なので、明日行くことにしよう。

追記：幸い、とれた詰め物は無事だったので、付け直すだけですんだ。

C++03とC++11の違い: 特別なメンバー関数編

京都C++勉強会の宣伝のために、C++03とC++11の違いを、少しづつ解説することにした。

今回は、特別なメンバー関数について解説する。

C++11では、デフォルトの実装が違法になる暗黙に宣言される特別なメンバー関数は、delete定義される。

delete定義はC++11からの機能だ。これにより、宣言は参照するが、定義を使わないために問題にならなかったC++03のコードが、C++11では明確に違法になる。

いまいちいいコード例が思い浮かばない。

C++11では、デストラクターが暗黙で無例外指定になった。

これにより、デストラクターから例外で脱出すると、std::terminateが呼ばれる。

struct S
{
    // call std::terminate
    ~S() { throw 0 ; } 
} ;

これは、デストラクターは例外を投げるべきではないという原則による変更である。もし、C++11で、どうしてもデストラクターから例外を投げたい場合は、noexcept(false)を明示的に使わなければならない。

struct S
{
    // OK
    ~S() noexcept(false)
    { throw 0 ; }
} ;

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

当日はUstreamによる配信もある

http://ustream.tv/channel/hatenatech

また、私の書いたC++11のコア言語を完全に解説した参考書もある。

Gumroadで購入： C++11参考書：C++11の文法と機能

今すぐ閲覧： C++11: Syntax and Feature

誤りがあればGitHubでPull Requestせよ: https://github.com/EzoeRyou/cpp-book

誤字脱字
筆者の規格文面の解釈間違い
規格文面の誤り

だけである。まだ、世の中の安定版コンパイラーはC++11の規格をバグフリーで完全に実装していない。

2013-12-12

Vimにclang_completeを導入した

NoeBundleを得て、Vimのプラグイン導入を恐れなくなった私は、さっそく、Vimにclang_completeを導入した。

Rip-Rip/clang_complete

NeoBundleを使った。とりあえず色々と試した結果、、以下の設定に落ち着いた。

" Install clang_complete
NeoBundle 'Rip-Rip/clang_complete'

let g:clang_periodic_quickfix = 1
let g:clang_complete_copen = 1
let g:clang_use_library = 1

" this need to be updated on llvm update
let g:clang_library_path = '/usr/lib/llvm-3.4/lib'
" specify compiler options
let g:clang_user_options = '-std=c++11 -stdlib=libc++'

他にもテンプレートや関数の引数まで保管してくれるスニペットや、最長一致のものを自動的に入力してくれるオプションもあるのだが、私はテキストエディターが勝手に文字列を入力するのが嫌いなので、有効にはしなかった。

さて、この結果として、私のVim環境は最強のC++IDE環境になってしまった。今や私のVimは、以下のことができる。

Makefileを使ってC++11までのコンパイルや実行ができる
clang_completeを使ってC++11までの補完ができる
Wandboxを使ってC++14のオンラインコンパイルができる

ああ、なんということだ。Windows環境を離れて、唯一心残りのあった、Visual StudioによるInteliSense以上のものが、今ここにある。しかも、もはやMSのような不自由ソフトウェアの追随を許さないほどの高機能だ。しかも、全て自由ソフトウェアだけで実現できている（ただしWandboxは私が支配力を持たないSaaSSであるが）。いや、不自由ソフトウェアでは実現できないことだ。ああ、C++といえばWindowsという時代（一時期MSVCの方がテンプレートのサポートが優れていた時代があった）は、本当に終わってしまった。

ああ、はやくClang 3.4とGCC 4.9が安定リリースされ、C++14が正式発行されて、C++14の補完とローカルでのコンパイルができるようになりたい。

C++03とC++11の違い: 宣言子編

京都C++勉強会の宣伝のために、C++03とC++11の違いを、少しづつ解説することにした。

今回は、宣言子だ。

C++11にはリスト初期化のNarrowing Conversionが禁止された。

以下のような合法なC++03コードが、C++11では違法となる。

// C++03では合法
// C++11では違法
int a[] = { 1.0 } ;

C++11では、リスト初期化というものを新たに導入し、従来aggregateにのみ許されていた{ }による初期化を、ユーザー定義型のクラスにももたらした。この心機能の追加にあたって、リスト初期化では、浮動小数点数から整数型や、より表現できる範囲が狭い可能性のある型への暗黙の変換(例：doubleからfloat、intからshort)を、縮小変換(narrowing conversion)と名付け、明確に禁止した。

もし、どうしても型変換を行いたい場合は、明示的なキャストが必要になる。

// well-formed
int a[] = { static_cast<int>( 1.0 ) } l

そもそも、このような暗黙の型変換には頼ってはならないのである。強い静的型付けによって、コンパイル時にくだらない不具合を発見できるべきで、暗黙の型変換はその妨げになる。

いつか、暗黙の型変換が一切廃止される日をこの目で見たい。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

当日はUstreamによる配信もある

http://ustream.tv/channel/hatenatech

また、私の書いたC++11のコア言語を完全に解説した参考書もある。

Gumroadで購入： C++11参考書：C++11の文法と機能

今すぐ閲覧： C++11: Syntax and Feature

誤りがあればGitHubでPull Requestせよ: https://github.com/EzoeRyou/cpp-book

誤字脱字
筆者の規格文面の解釈間違い
規格文面の誤り

だけである。まだ、世の中の安定版コンパイラーはC++11の規格をバグフリーで完全に実装していない。

2013-12-11

C++で、(a/b)*b + a%b != aとなる例

C++では、整数a, bにおいて、"(a/b)*b + a%b"の結果が、"a"と等しくない場合、a/bとa%bの挙動は未定義である(5.6 paragraph 4)

この条件に当てはまるaとbの値が、さっぱり思いつかなかった。b = 0の場合はそうなのだが、それは一つ前のセンテンスでカバーされている。わざわざ書く以上、b = 0以外の例があるはずだ。そこで人に聞いた。一瞬で答えを教えてもらった。

aとbがint型で、int型は2の補数で表現されていて、INT_MIN == -2^(n-1) (nはintのビット数)の場合における、a = INT_MIN, b = -1

なるほど、2の補数だから、最小値と最大値の絶対値が1ずれるわけだ。ずれは最小値の絶対値の方が1大きくなる。-1で割るということは、つまり最大値が最小値の絶対値になるということで、オーバーフローする。

#include <limits>
#include <iostream>

int main()
{
    int a = std::numeric_limits<int>::min() ;
    int b = -1 ;

    int c = (a/b)*b + a%b ;

    std::cout << c << '\n' ; 
}

興味深いことに、GNU/Linux x64のGCCとClangでコンパイルすると、標準出力にFloating point exceptionと出力され、その時点でプログラムの実行が止まる。

xkcd What if?: 星の王子様に出てきた小さな惑星が本当にあったらどうなるの？っと

またもやxkcdから。

小さなお星様

もし、小惑星がとても小さく、しかし超密度であれば、星の王子様みたいに生活できるの？っと

Samantha Harper

先週、我々は巨大な惑星における生活を考察した。今週は、小さな惑星に目を向けよう。

アントワーヌ・ド・サン＝テグジュペリ著の星の王子様は、遠く離れた小惑星からの旅人のお話だ。読みやすく、どこか物悲しく、印象深い絵本だ。[1]。子供向けの本だが、対象読者を限定するのは難しい。ともかく、大衆受けしていて、歴史的にもベストセラーになっている。

[1]: 星の王子様のような話をもっと読みたければ、Mallory Ortberg著のこの素晴らしい小説を下までスクロールするといい。

星の王子様は1942年に書かれた。これは小惑星について書くにあたって、とても興味深い年代である。というのも、1942年には、我々はまだ、小惑星がどのような形をしているか知らなかったのだ。当時の最高の望遠鏡を使っても、最大の小惑星は、単なる光の点としてしか観測できなかった。実は、asteroidという名前の由来はそこから来ている。意味は「星のような」だ。

我々が小惑星の形について初めて確認できたのは、1971年、Mariner 9が火星に到達して、フォボスとダイモスの写真を撮影した時だ[2]。この、当時小惑星と信じられていた月[3]は、現代風のポテトのような形の小惑星のイメージを形成した。

[2]: コレがフォボスの画像だ。典型的な小惑星の見た目をしている。この計画に画像アーカイブは、NASA Space Science Data Centerにあるが、奇妙なことに、NSSDCは、実際の画像閲覧は、どっかの個人サイトTripod pageに丸投げしている。

[3]: 興味深いことに、フォボスとダイモスは小惑星の形をしているが、最近の研究によれば、小惑星ではないという。Craddock, Robert AのAre Phobos And Deimos The Result Of A Giant Impact? Icarus (2010)を参照。

1970年代以前、SFでは小さな小惑星も、惑星のように丸いものであるとの考えが一般的だった[4]。

[4]: 皆がそういう考えだったわけではない。だいぶ正確な考えの人もたくさんいた。ヘンテコな考えもあった。

星の王子様はこの考えをさらに飛躍させた。小惑星が、小さな惑星で、重力があり、空気があり、バラもある。ここで科学的に糾弾するのはあたらない。なぜならば、(1) これは小惑星の話ではないし、(2) 大人が物事を真面目に考えすぎることを茶化すためのものだからだ。

そこで、お話を変更するのではなく、科学的に考えればどうなるのかについてみてみよう。もし、歩き回れるほどの表面重力を持った超密度の小惑星があるとする。その小惑星は、とても面白い特性を持っている。

もし、小惑星が半径1.75メートルであれば、地表で地球と同等の重力を有するためには、その質量は500万トンなければならない。これは、地球上に存在するすべての人間分の質量と同じ程度の質量だ。

地面に立つと、潮汐力を感じるだろう。頭より足のほうが重く感じるので、ゆっくりとストレッチしたような感覚を覚えるだろう。あたかも、丸まったゴムボールの上でストレッチしているような感じ、あるいは、頭を中央に向けてメリーゴーラウンドに寝そべったような感覚だ。

地表における脱出速度は、秒速5メートルだ。これは全力疾走よりは遅いが、それでもそれなりには速い。目安として、もし読者がバスケットボールをダンクシュートできなければ、垂直跳びで脱出するのは無理だ。

しかし、脱出速度の面白いところは、進む方向は関係がないということだ[5]。もし、読者が脱出速度よりも速く動けば、その方向が惑星に向かうものでないかぎり、脱出できる。つまり、小惑星を水平方向に走って、崖でジャンプしてもオサラバできるのだ。

[5]: ・・・だからこそ、脱出速度(escape velocity)は、本当は脱出速度(escape speed)と呼ばれるべきなのだ。方向がないというのは（それこそがspeedとvelocityを区別するものなのだから）、とても重要な違いだ。

もし、読者が惑星を脱出するほど速く動けなかったとしたら、軌道上を回ることになる。読者の軌道速度は約秒速3メートルだ。これはジョギングの速度である。

だが、これはとても奇妙な軌道になるだろう。

潮汐力が読者の複数箇所に対して働くことになる。もし、読者が惑星方向に腕を伸ばしたとすると、その腕は体の他の部分よりより強く引かれることになる。もし、腕を地面に下ろしたとすると、体の他の部分は上方向に押し上げられる。これはつまり、読者の体の他の部分は、重力をより軽く感じることになる。結果的に、体の各部位が、それぞれ別々の軌道を辿ろうとするのだ。

このような潮汐力下における巨大な軌道物体は--例えば、月--は、一般的に、粉々に砕けて輪を形成する。これは読者には起こらない。しかし、軌道はカオス的かつ不安定なものとなるだろう。

このような軌道については、Radu D. RugescuとDaniele Mortariによる興味深い論文[6]で検証されている。彼らのシミュレーションによれば、巨大な長い物体は、中心部を軸に不思議なパターンをたどるのだという。質量の中心点すら、古典的な円を描かない。五角形軌道のこともあれば、カオス的に回転した挙句、惑星に衝突するものもある。

[6]: >Rugescu, Radu D., Mortari, Daniele "Ultra Long Orbital Tethers Behave Highly Non-Keplerian and Unstable" WSEAS Transactions on Mathematics, Vol. 7, No. 3, March 2008, pp. 87-94.

このような解析には、実は実用的な応用対象がある。長年、とても高い、車輪とヒモで、荷台を重力圏内外に運ぼうという提案がなされている。いわば空中に浮かぶ宇宙エレベーターだ。そのようなヒモは、荷台を地表と月間で移動させることができたり、地球の大気圏内から宇宙船を捕まえたりできる。軌道ヒモの不安定性は、この計画における難しい課題となっている。

さて、この超高密度小惑星の住人は、とても注意深く暮らさなければならないだろう。もし速く走り過ぎると、激しく揺さぶられて、昼飯を戻してしまう深刻な危険がある。

幸い、垂直跳びは問題ない。

星の王子様の生活は大変そうだ。

C++03とC++11の違い：式編

京都C++勉強会の宣伝のために、C++03とC++11の違いを、少しづつ解説することにした。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

当日はUstreamによる配信もある

http://ustream.tv/channel/hatenatech

今回は式(expression)について。

C++11では、整数の除算と剰余の丸め方向がゼロに向かう。

これはC99との互換性を向上させるための変更である。

C++03では、整数a, bに対して、a / b の結果が、実数では0.9とか-0.9になった場合、整数の結果の丸め方向がどちらになるのか規定されていなかった。

9 / 10 ; // 0? 1?
-9 / 10 ; // 0? -1?

C++03では、整数a, bで、a, bが、片方、あるいは両方とも正の整数でない場合、a % bの符号は実装依存だった。

3 % 2 ; // 1
-3 % 2 ; // 1? -1?
3 % -2 ; // 1? -1?
-3 % -2 ; // 1? -1?

C++03では、C言語の規格策定で、ISO Fortran 90、つまりISO/IEC 1539:1991の仕様に合わせるのが推奨されていると注記している。

Fortran 90規格の文面によれば、除算の商は、必ずゼロ方向に丸められる。

 9 / 10 ; // 0
-9 / 10 ; // 0

剰余の符号は、以下のようになる。

 8 %  5 ;    //  3
-8 %  5 ;    // -3
 8 % -5 ;    //  3
-8 % -5 ;    // -3

C99はFortranに合わせるによう規定され、C++１１でも、C99との互換性向上のため、この規定に合わせることにした。

それにしてもわからないのが、未定義動作となる条件だ。a / bの商が式の結果の型で表現可能ではない場合というのはいいとしても、(a/b)*b + a%bがaと等しくない場合というのは、どうやったら可能になるのかわからない。そういうハードウェアがあるのだろうか。

参考文献：GFortranStandards - GCC Wiki

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

当日はUstreamによる配信もある

http://ustream.tv/channel/hatenatech

2013-12-10

xkcd What if: お茶をどのくらい激しくかき混ぜたら沸騰するの？っと

xkcdのWhat ifで、お茶をどのくらい激しくかき混ぜたら沸騰するのかということについて考察していた。

What if: 紅茶をかき混ぜる

ぼんやりと熱い紅茶をかき混ぜながら、こう思った。「まてよ、俺は運動エネルギーをこのカップに与えているのではないか？」とね。お茶をかき混ぜると冷めやすくなるけど、もし、高速にかき混ぜたらどうだろうか。かき混ぜることによって、お湯を沸かすことができるだろうか。

Will Evans

ノー

基本的な考えとしては間違ってない。温度というのは単なる運動エネルギーだ。お茶をかき混ぜるということは、運動エネルギーを与えているということだ。そのエネルギーはどこかに行く。お茶がにわかに浮遊したり光を放ったりしない以上、そのエネルギーは熱に変わっているはずだ。

熱に気が付かない理由は、それほど多くの熱を与えていないからだ。水を熱するにはとても多くのエネルギーを必要とする。容量あたりで言えば、水は通常の物質の中では相当に多くの質量あたりの熱容量を持っている[1]

[1]: 水素とヘリウムは、より多くの質量あたりの熱容量を持っているが、これらは気体だ。通常の物質で水に勝るのは、跡はアンモニアぐらいしかない。これら3つの物質は、体積あたりで比較すれば、水に負ける。

水を室温から沸騰寸前まで二分で加熱したい場合、相当の力が必要になる。

\[1\text{ cup}\times\text{Water heat capacity}\times\tfrac{100^\circ\rm{C}-20^\circ\rm{C}}{2\text{ minutes}}=700\text{ watts}\]

注意：沸騰寸前の水を沸騰にまで持って行くには、沸騰寸前までにかかったエネルギーに加えて、さらに大量のエネルギーを必要とする。これはenthalpy of vaporizationと呼ばれている。

この数式によれば、二分でコップ1杯のお湯を得たければ、700ワットの力が必要になる。通常の電子レンジは、700から1100ワットぐらいで、お茶を淹れるぐらいにコップ1杯の水を熱するのに、二分ほどかかる。動くってのは素晴らしいことだ。[2]

[2]: もし動かないとしたら、「非効率」とか「熱源」とかに文句を言うべきだ。

700ワットを二分間というのは、とてつもなく大きなエネルギーだ。水がナイアガラの滝から落ちるとき、運動エネルギーを得て、落下地点で熱に変わる。しかし、相当な距離を落下しても、水は小数点以下の温度ぐらいしか上昇しない[3]。コップ1杯の水を沸騰させるには、大気圏外の高さから落下させなければならない。

[3]: \(\text{Height of Niagra Falls}\times\frac{\text{Acceleration of gravity}}{\text{Specific heat of water}}=0.12^\circ\text{C}\)

オチャアアアアアアァァァァァーーー！！！

かき混ぜることと電子レンジを比較すると？

工業ミキサーの技術レポート[4]によると、筆者の推定では、カップのお茶を激しくかき混ぜると、約百万分の一ワットの熱を与えることになる。これは無視できる範囲だ。[5]

[4]: Brawn Mixer, Inc., Principles of Fluid Mixing (2003)

[5]: お茶はこれよりはやく熱を失う。参照：Ben Harden, Tea temperature vs. Time graph

かき混ぜることによる物理的効果は、やや複雑だ[6]。ティーカップは、その上を対流する空気によって熱が奪われるため、上から冷めていく。かき混ぜるということは、新鮮な温かい水を底からもたらすので、冷却の過程に貢献するだろう。しかし、かき混ぜることによって、空気の流れが阻害され、コップを温めることもある。データ無しでは、なんとも言えない。

[6]: ある状況では、液体をかき混ぜると温度維持に貢献することになる。温かい水は上昇し、水の量が広く十分ならば（例えば海）、温かい層が水面に形成される。この温かい層は冷たい層よりも、ずっとはやく熱を放出する。かき混ぜることに寄って、この温かい層を崩すと、熱を失う速度が減少する。ハリケーンの移動が止まると、力を失うのは、このためである。ハリケーンの波が冷たい水をかき混ぜて、主要なエネルギー源である薄く温かい水の層から遠ざけるのだ。

幸い、我々にはインターネットがある。StackExchangeユーザー、drhodesが、かき混ぜるVSかき混ぜないVSスプーンを連続的に出し入れすることについて、ティーカップの冷却率を計測してくれたのだ。素晴らしいことに、drhodes君は高精度グラフもうｐしてくれたし、さらになんと、生データまでうｐってくれたのだ。どこぞの科学記事よりよほどデキる奴だ。

結論：かき混ぜるかどうか、スプーンを出し入れするかどうかでは、何も変わらない。お茶は同じ割合で冷却されていく（ただし、スプーンの出し入れはわずかに冷却速度が早かったが）

さて、もとの質問に戻ろう。十分に激しくかき混ぜたら、お茶を沸騰させることができるか？

ノー

まず問題なのだ力だ。700ワットとは、約１馬力にあたる。そこで、お茶を二分間で沸騰させたければ、少なくとも馬を一頭用意して、十分に激しくかき混ぜてもらわなければならない。

あの・・・君、もしよかったら、その・・・
スプーンをくわえて、かき混ぜてもらえるかな？

お茶を長時間加熱することにより、必要な力を減少させることはできる。しかし、時間をかけ過ぎると、加熱より冷却速度が勝ってしまう。

仮にスプーンを十分に激しく--毎秒一万回--かき混ぜることができたとしても、液体力学が立ちはだかる。これほど高速になると、お茶にはキャビテーションが発生する。スプーンの軌跡に真空が発生し、かき混ぜ効率を下げてしまうのだ。

それに、お茶にキャビテーションが発生するほど十分に激しくかき混ぜた場合、水面部分は激しく上昇し、数秒で室温に冷却されてしまうだろう。

いくら激しくお茶をかき混ぜようとも、それ以上に温かくはならないのだ。

C++03とC++14の違い：標準型変換編

京都C++勉強会の宣伝のために、C++03とC++14の違いを、少しづつ解説することにした。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

当日はUstreamによる配信もある

http://ustream.tv/channel/hatenatech

さて、今回は標準型変換だ。私は便宜上、Starndard Conversionのことを、標準型変換と呼んでいる。

C++14では、リテラルのみが整数nullポインター定数として扱われる。

C++03/11では、コンパイル時に値が0になる整数型もリテラルとして扱われていた。

C++14では、無用の混乱を避けるために、リテラルのみをnullポインター定数とするように改められた。

この違いは、オーバーロード解決などに影響を及ぼす。

void f( void * ) ; // #1
void f( ... ) ; // #2

template < int N >
void g()
{
    // C++03/11では#1を呼ぶ
    // C++14では#2を呼ぶ
    f( 0*N ) ;
}

この例で、依存式、"0*N"　は、Nの値がどうなろうと0になる。そのため、C++03では、nullポインター定数として扱われ、オーバーロード解決の結果、ポインター型が最適関数に選ばれる。C++14では、リテラル("0")のみをnullポインター定数と制限したため、0*Nはポインターではなく、#2が呼ばれる。

ただし、C++11/14では、nullポインター定数には、特別なキーワード、nullptrを使うべきであり、0やNULLマクロの使用は、既存のC++03コードを未改変で使う場合のみに留めるべきである。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

当日はUstreamによる配信もある

http://ustream.tv/channel/hatenatech

2013-12-09

Linus、CPUの信頼性について語る

CPU reliability (Linus Torvalds)

2007年のLinusのメールだが、Hacker Newsで話題になっていたので。

From: Linus Torvalds <torvalds@linux-foundation.org>
Newsgroups: fa.linux.kernel
Subject: Re: [patch] CFS scheduler, -v8
Date: Fri, 11 May 2007 16:52:21 UTC
Message-ID: <fa.oZhj8hj7kSDLnitsqrEJcRJN+RE@ifi.uio.no>

On Thu, 10 May 2007, Pavel Machek wrote:

そもそも、今のCPUは300年も稼働するようには設計されていない。50年以上稼働するハードウェアが設計された後で考えても遅くはない。

そうだな。CPU屋はそういうことをあんまり話したがらないようだな、intel.comをgoogleで検索したらこんなのを見つけた。

故障率と平均故障間隔(Mean Time Between Failure: MTBF)のデータは現在、このWebサイトにはございません。情報についてはIntel® カスタマーサポートまでお問い合わせください。

これは要するに、「俺らそんなこたぁ話したかねーや」ってことを丁重に言ってるんだろう。それが実際に悪いとかじゃなくて、単にそういうことを考えていないのだろうし、CPU屋が、顧客にそういうことを考えてほしい理由もない。

ところで、サーバーのCPUは、たいてい低い周波数で稼働しているが、これはMTBF問題によるものだ。思うに、デスクトップCPUは、たいてい5年間稼働ぐらいのスペックなんだろう。（しかも、電源を落とすこともあるし、たいていの時間はアイドルだ）。しかし、サーバーCPUは、もっと長く稼働するし、もっとアクティブだ。

（「アクティブ」 == 「熱」 == 「原子移動とかのダメージがより大きい等」。オーバークロックすべきでない理由はこれだ。そりゃ、快適に動くかもしれんが、CPUの予測寿命を90%落とすことになる）

もちろん、他の部品にだってMTBFはある。（思うに、電源はたいていCPUより先に壊れるだろう）。もちろん、数十年稼働する機械だってあるにはある。だが、機械はすべて、それほど信頼性を持たないと考えるべきなのだろう。

Linus

私の経験からすると、デスクトップコンピューターで壊れやすいのは冷却のためのファンだ。特にGPUカードに内蔵してあるファンが壊れやすい。もう何度も、GPUのファンが壊れたためにGPUを交換している。また、CPUファンが壊れたこともある。

電源ユニットが壊れたこともあるのだが、どうもこれは、電源ユニットのファンが壊れたらしい。しばらくは動くのにいきなり電源が落ち、しかもやたらとPCケースが熱くなっているので、CPUのファンが壊れたかと思って、よく調べたら、電源ユニット内蔵のファンが回っていなかった。

わたしの経験上、CPUが壊れたことはない。CPUファンが壊れて冷却できずに落ちたことなら度々あるのだが（ケースを開けるまでCPUファンの故障に気が付かず、何度か熱で落ちたが）、熱を検知する保護機能によるものか、CPUは故障しなかった。CPUファンを交換後は、全く問題なく動作した。

私が思うに、ゲーム用の高性能なGPUのビデオカードは、長期間稼働することを全く考慮しない設計になっているのではないかと思う。過去に二台しかデスクトップPCを持っていないのに、グラフィックカードは6枚ぐらい故障のために交換している。これは異常な故障率だ。

C++03とC++11の違い：字句編

京都C++勉強会の宣伝のために、C++03とC++11の違いを、少しづつ解説することにした。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

C++11の新しい文字列リテラル

C++11では、新しい文字列リテラルが導入された。特に、その文字列リテラルのプレフィクス、R, u8, u8R, u, uR, U, UR, LRは、C++03では合法なプログラムで違法になるものがある。例えば、そのような名前をマクロを使っていた場合だ。

#define u8 "abc"

// C++03では"abcdef"
// C++11では"def"
const char * ptr = u8"def" ;

このことからもわかるように、Cプリプロセッサーマクロは危険であり、使ってはならない。

C++11のユーザー定義リテラル

C++11では、ユーザー定義リテラルが導入された。これにより、C++03で合法なプログラムで違法になるものがある。たとえば、ユーザー定義リテラルの場所でマクロを使った場合だ。

#define _x "def"

// C++03では"abcdef"
// C++11では、ユーザー定義リテラル
"abc"_x ;

このことからもわかるように、Cプリプロセッサーマクロは危険であり、使ってはならない。

C++11の新しいキーワード

C++11では、以下の新しいキーワードが導入された。

alignas, alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert, thread_local

これらのキーワードは、C++03ではキーワードではないので、当然、以下のようなコードを記述することができた。

// C++03では合法
// C++11では違法
int alignas = 0 ;

たまたま新しいキーワードを使っていた既存のコードは、C++03では合法だが、C++11では違法になる。

C++では、標準化にあたって、既存のコードで慣習的によく使われている名前をキーワードとすることは避けている。そのため、通常はこれらの新しいキーワードと既存のコードが衝突することはないだろう。

整数の型

C++では、サフィックスを用いていない整数リテラルの型は、その値によって変わる。もし値がint型で表現できない場合long int型、符号付き整数型で表現できない場合、符号なし整数型になる。

C++11では、C99との互換性のため、long long intを取り入れた。このため、C++03では、unsigned long型になっていた整数リテラルが、C++11では、signed long long int型になる可能性がある。

江添とボレロ村上の京都C++勉強会 | 集客ならイベントアテンド

wandbox-vimで最高のC++14環境を体験

ClangがC++14の機能完全に到達した話はすでにした。しかし、現状ではClangでC++14が使いづらい。

今、ClangでC++14を使うためには、まだ安定リリースされていないレポジトリにある最新のglibc、最新のGCC、最新のClangを落としてビルドして配置して適切にパスを通すことが必要になる。そのような作業は面倒すぎて、個人のローカル上ではやってられない。

そもそも、GNU/LinuxでClangとlibc++を適切に配置してパスを通すのも難しいのだ。そのようなパッケージ化は、メンテナーの手によって行われて欲しいが、それには安定リリースを待たなければならない。はやくても来年後半の話だ。

そこで活躍するのがWandboxだ。

[Wandbox]三へ( へ՞ਊ ՞)へﾊｯﾊｯ

なんと、Wandboxでは、常に最新のレポジトリHEADのClangが使えるのだ。コードを送信すれば、コンパイルして、実行して、結果を返してくれる。

これは素晴らしいが、しかし、コードはVimのような本物のテキストエディターで書きたいものだ。そして、コンパイル程度のことは、Vimから行いたいものだ。

Vimではコマンドを呼び出せる。また、makeには特別な対応がなされていて、コンパイルの処理をMakefileで書いておけば、Vimから簡単に呼び出せる。

そして、VimはGCCのような有名コンパイラーのエラーメッセージをパースして表示し、直接問題箇所に飛べる、quickfixという機能を標準で提供している。

これにより、Vimは何もプラグインをインストールしなくても、コーディングに最適なテキストエディターとなっているのだ。

しかし、Wandboxはオンラインのサーバーで提供されているSaaSSだ。ああ、なんとかしてVimで簡単に扱えないものか。

実は、そのようなプラグインがある。その名も、wandbox-vimだ。

rhysd/wandbox-vim

Wandbox-vimでは、vimで:Wandboxとコマンドを打つだけで、現在のバッファーをWandboxに送って、結果を表示してくれる。

しかもしかも、このwandbox-vimは、機能の更新で、エラーや警告のメッセージをquickfixに流しこんでくれるようにもなったのだ。

今すぐC++14の環境使いたいですよね？

さあ、今すぐアクセス！

GCC 4.9が安定リリースされ、GNU/Linuxのディストロがパッケージ化するまでの間は、とりあえずWandboxでC++14を試すことができる。

2013-12-08

予定のメモ

来週はやることが多いので、メモ代わりに書き出してみる。

16日の夜に、はてなのセミナールームを借りて、江添とボレロ村上の京都C++勉強会を行う

勉強会が終わった後に、ボレロ村上さんを囲んで鍋をする。

17日、おそらく朝は吉田寮にいる。

18日の夜、依頼が会ったので、東京でC++の歴史について講演。（いずれ機会があればスライド資料を使って公開された場でも行うかも）

たぶん卓球ハウスに泊まる。

19日以降、

ギークハウスを見学する。少なくとも、ギークハウス水道橋とギークハウス文京護国寺を見学する。他のギークハウスはどうしよう。

妖怪ハウスにも行く。

さて、これを考えると、18日からその週末まで東京でぶらぶらするべきなのかもしれない。

また、17日のうちに東京入りしてしまうのも手かもしれない。

せっかくだから、この機会に都内のギークハウスに連絡して、行ける場所に一日一件見学に行ってみたい。問題は、東京都内だけでも10件以上あるということだ。

квашеная капустаの肉炒め

квашеная капуста（クヴァーシュナヤ　カプーシュタと聞こえる）の肉炒めを食べた。ロシア風のザワークラウトだそうだ。要はキャベツの塩漬けだ。人参が入るのがロシア風なのだとか。

酸っぱいキャベツと肉を一緒に食べると、とてもうまい。

ついでに、日本語入力経由でキリル文字で入力してもらった。

あとで、試みにiBus 1.5でロシア語キーボードレイアウトを追加してみた。キリル文字が打てるようになったが、残念ながら私にはキリル文字は読めないので、もとに戻した。