PCを別のケースに入れ替えた話

先代の Antec P182 が、先日の分解清掃の際にフロントパネルの爪をいくつか折ってしまったりなどだいぶ老朽化した感じもあり（また、マザーボード取付部にメンテナンスホールが無いなど設計も古いので）、新しいケースに入れ替えることにしました。ケースには SilverStone SST-FT02 を選びました。

発売からそれなりに時間が過ぎていることもあり、流通状況はあまり良くありませんが、オークションに出るのを待つなどしなくても通販系のショップなどにたまに入荷するようです（ただし、異常に高額で売ってる店もあるので注意）。FT02 と RV02 の、マザーボードの90度回転配置と（通常の配置では後部になる側が、上部になる）、左右が逆の配置（マザーボードを右側面ではなく左側面に取り付ける）は、同様のものを他に見ないユニークなもので、しばらくはこのケースを使う予定です。

1枚目の写真ですが、組込み前にファンを全て換装しました。下部の3連180mm吸気ファンは SST-AP181 から AP182 に、上部の120mm排気ファンは Noctua の風量特化型ファン NF-S12A を付けています。AP182 は可変範囲が広く、また可変範囲であれば任意の速度に設定できるので、冷却重視にも静音重視にもベストの選択かと思います。ボリュームのつまみをいったん外す必要がありますが、ケースの元々は速度設定スイッチがあった場所に同じネジで取り付けできます（LとHのマークが逆になりますが。あと配線の向きが合わないので、周辺と干渉するのを避けるために曲げざるをえませんが、その際に端子を折ってしまわないよう注意）。

また排気ファンは、吸気をメインとする「正圧」がコンセプトの SilverStone のケースでは、正常動作中であれば静圧は必要ないわけですから、やはり風量特化型ファンがベストの選択かと思います。

CPUクーラーです。メーカーの公称では165mmまでとなっていますので、Cryorig のハイエンドクーラーなどでなければたいていは入るでしょう。Noctua NH-D15 がやはりちょうど公称165mmです。

こちらのクーラーは、別のパーツの店頭在庫がありそうだった店に偶然に残っていた、サイズの「無限 大」（Mugen Max, SCMGD-1000）を、SST-FHP141 のデュアルファンにしたものです（こちらも現在、かなり流通が細くなっていますが……）。ちょっと特殊で38mm厚のため、25mm厚ファン用クリップで取付けられるよう、長さ28mmのスペーサーを加工してクリップ取付用の台座にしています。まぁはっきり言って無駄なこだわりですので、普通には、このファンを挟むようなほぼ専用の設計と言える SST-HE01 を使えばよいでしょう。HE01 であればトリプルファン化も可能ですし。

組み込み後の写真です。電源の部分のパンチングメタルは、かなりでかい（長い）電源でないと位置が合いませんので、たいていの場合、電源の吸気はケース内側からにせざるをえないかと思います（あるいは正圧設計を活用してファンレス電源を組み合わせるのも良い手かも。SST-NJ600 が出るのを待ってるんですが……いつ出るのやら）。狭い設置場所で無理に撮影したため（ライカ判に換算して14mmのレンズ）、不自然に奥行きが強調された、不動産屋のイメージ写真のようになっていますが、全体の感じはだいたいつかめると思います。

技術書典に申し込みました

詳細は後日（の予定）

えーと、詳細です。

技術系よろず(？)同人誌「ElectroComplex」創刊号*1を持っていきます。（サークル名と同名ですが、〆切ぎりぎりに寝不足状態で作業していたためか、サークル登録にはtypoがあります）

内容は記事1本になってしまいましたが、ライフゲームの実装についてです。ありがちなテーマですが、内容的には初出ではないとは言え詳しく解説している例を他に見ない*2ものである、という自負は（だけは）あります。

では当日（コピー誌なのでこれから大詰めなんですが、それが無事に進行すれば）お会いしましょう！

*1:はたして2巻は出るのか？

*2:初出文献では、解説はごくあっさり流していたため。

「IME文節」という謎のジャーゴンについて

はじめに

日本の仮名漢字変換関連の某システムの一派の方面が発信元のようですが（その集団ないし個人を糾弾することが目的ではないので、ここでは明示しませんが）、「IME文節」という謎の（良くない）ジャーゴンが広まっているようですので、注意喚起の意図で本稿を書きます。

結論

それは、「複合語」や「接辞」や「造語成分」などに関する処理ではないですか？　そうであればそのまま、例えば「複合語の分割と変換」などのように表現すべきです。

なぜ「IME文節」などという表現がされるのか

検索で見つかるいくつかのウェブページや資料などから、私が推測した所では、以下のような理屈により「IME文節」という概念が必要だと思われているようです。

(1) 日本語の文法では、文は以下の BNF のようになっている（ここでは句読点等は除いて考えている）。

<文>	::= <文節>＋
<文節>	::= <自立語>　<付属語>＊

ここで、自立語とは名詞や動詞だから、仮名漢字変換としては、活用語尾などへの対処は必要であるが、辞書を引いて対処することになる。（付属語についてはたいていはひらがなであり、ここでは考えない）

(2) しかし実際に変換の対象となる文には、「電子情報通信学会定時社員総会において」というような、1語として辞書に用意するのはありえないようなものもよく出てくる。

(3) なので実際の仮名漢字変換では、ここで示したような日本語の文法によるものよりも細かい分解が必要である。

(4) そこでこの、仮名漢字変換で必要な分解の単位を「IME文節」と呼ぼう。

という感じのようです。

どこがどう問題か

前の節で示したうちの、(3) までは問題ありません。問題は (4) です。「IME」という表現が含まれていることから、広まったのは1990年代後半以降であることは確実でしょう（ただしもっと古くから同様な考え方がされていた可能性はあります）。

しかし、そのような自然言語処理の手法はワープロにおいてもっと以前からちゃんとあったものです。仮名漢字変換を実装して出荷されたものとしては最初のワープロである東芝 JW-10 他は、1980年前後のものですから、当然「IME」という語が広まるよりも古いですが、このような「辞書に無い自立語」のことはちゃんと考えて作られています。研究所で研究開発を担当され、JW-10モデル1を設計された天野真家先生が著者に入っている学会発表で「局所意味分析」といったような語が題ないしアブストに入っているものがありますが*1、それが、JW-10モデル1における、これに相当する処理で、後述する「接辞」としての扱いに近い形ですが、このような自立語の処理の実装の報告となっています。*2

そういったように、日本において実用的な仮名漢字変換が最初に実装された時点で考慮されていたものであり、また以降で述べるように、言語学的にも以前からきちんと扱われていたものを、ワープロのような自然言語処理でも扱うようになったものに過ぎませんから、あたかもIMEにおける特異な現象であるかのようなジャーゴンを与え、その名で呼ぶのは不適切です。

国語学的にはどうなのか

ソシュールや*3チョムスキー以後の言語学がとり入れられた現代の日本語文法学を持ち出すまでもなく、橋本文法の解説などにも*4、以上で説明したような「自立語よりも細かい単位」について、実際にはきちんと言及はあります。*5

橋本文法の原典『国語法要説』は、流石に参照はたいへんですが（というか私も見ていません）、山口明穂編『国文法講座 1 文法の体系』（1987）であれば、公共図書館での取り寄せはそんなに難しくもないと思います（CiNiiで見たところ、大学図書館への所蔵で200件以上あります）。それを読むと、より細かい単位について、以下のようなことが書いてあります。

（要約）さらに細かくできそうなものとして、「本箱」や「酒樽」といったような複合語は、「本」と「箱」、「酒」と「樽」といったように分解できるが、分解されたそれぞれは部分にしかなっていない。また、付属語の他に、「お山」の「お」のような接頭辞などの接辞もある*6。

また、古くからあるいくつかの仮名漢字変換システムにおいても、このような語のために、入力の扱い方を変えるモードのようなものとして「複合語変換」というような名前の機能を持っていたり、マニュアル内で「造語成分」といったように説明されていたりします。

まとめ

まとめると、そもそも「文節」ではなく、ちゃんと「複合語」や「接辞」という専門用語があるものを、単に仮名漢字変換において切り分けが必要だというだけで「IME文節」などと呼ぶのはあまりに雑であり、やめるべきだろう、ということになります。

完全に余談

以上の議論では全く触れていませんので（意図的です）、あたかも「文節」というものは、国語学において、橋本文法における文節として自明と言ってしまってよいほどに確かなものと扱われているように思えるかもしれませんが（あるいは、学校の国語の授業ではそのような前提があるかの如く教授されているかもしれませんが）、そんなことはなく、かの水谷静夫先生ですらおおいに悩まされたという話が『国語学五つの発見再発見』（創文社版 p. 107 脚注12）にあります*7。

*1:他、いくつかの講演資料のようなものにも見つかる。

*2:詳細には、「だいいっかい」→「第一回」のような変換において、「第」と「回」には関連があるから、というような話なのですが、「第一階述語論理」が例外だ、というのが「自然言語処理」の講義では余談(？)でした。

*3:「四大文法」のひとつ、時枝文法にはソシュールの影響がある（批判的だとも、誤解であるとも言われているようだが、ともかく影響があったということはそうだろう）。

*4:いわゆる「学校文法」のベースが橋本文法であるということは事実ですが、義務教育で扱っていることが橋本博士の文法の全て、などというわけはありません。

*5:ましてや、書店にはむしろそちら側の本しかないというような状況の、俗説の入り込む隙などは全く無い。

*6:「付属語と接辞の違いは、根本的なものでなく程度の差に過ぎない」ともあって、これはちょっとわからないのだが……。

*7:国研での用語調査の際の集計対象を文節としたので……といったような話。

「トロン―国産ＯＳが世界標準になる」とかいう見出しの記事について

結論

いつものアレなのになんで今回はこう騒ぎになってるの？

事実関係

2017年11月のニュースとして、μT-Kernel（従来のμITRONにおける小さめのプロファイルに相当）を、IEEE標準の「2050」にするために、著作権の移管などがあった。（IEEE 754（浮動小数点）とかIEEE 802（LAN）などと同様なワーキンググループのひとつ。他にどういうものがあるかは http://standards.ieee.org/develop/project/computer_technology.html で見られる）

この件に関する情報としては、

はあるが、日本語でちゃんとした内容を伝えるものは、なぜか（いつものことだが）出ていない。

今後何が変わるか（予想）

以下の内容は私の予想だが、そう大きくは外れないだろう。

結論としては、何も変わらない。

例えば ISO/IEC 14576 (STbus) は、元はTRONプロジェクトで開発されたTOXBUSであり、「TRONプロジェクト発の世界標準」のひとつだが、それで何が変わっただろう？

IEEE P2050のページ（ http://standards.ieee.org/develop/project/2050.html ）の右の「PAR」（Project Authorization Request）と書かれている所にあるPDFに、プロジェクトのスコープやミッションなどが書かれているが、要するに、今あるμT-Kernelの仕様書をレビューし、IEEE標準のひとつとする、ということだけしか書かれていない。つまり、μT-Kernel以外の、（μでない）T-Kernelをはじめとするその他のTRON全てについては、全く無関係な話でしかない。

また、最も強く懸念されることとして、以前の（1.0の頃の）ITRONの仕様書がそうであったように、1万円以上の価格で購入しない限り、仕様を見ることができなくなるかもしれない、という点があるが（実際に現状で「IEEE P2050　IEEE Draft Standard for Real-time Operating System (OS) for Small-scale Embedded Systems　IEEE P2050/D2, October 2017」を入手するには、268ドルで購入する必要がある）、2017年のうちに移管されている（はずである）μT-Kernel2.0の仕様が、2018年4月現在、英日版とも、tron.org のウェブページから閲覧可能であることから（単に更新されてないだけにも見えるが）、もし、著作権の移管により見られなくなるものならば、現状がそれに違反していることになるので、恐らく問題ないものなのであろうと、強く推測される。

その他

坂村先生の風呂敷はいつものことだし、アンチが「Linuxという世界標準があるのに」とか意味のわかんないこと言うのもいつもの後継なんですが、なんで今回はこんなにバズってるのというか。読売新聞効果ですかね？

先生の威勢のいい談話が出るのは結構ですが、教育用キットT-Car（リンク先画像 http://ascii.jp/elem/000/001/089/1089654/img.html ）とか出るんですかどうなんですか。

TypeScriptにおけるobject typeのunionの、あまり期待されてないのではないかと思われる挙動について

結論

Discriminated Union （ http://www.typescriptlang.org/docs/handbook/advanced-types.html#discriminated-unions ） を使おう

サンプルコード

'use strict';

type A = { a: string }
type B = { b: number }
type C = { c: boolean }
type T = A|B|C

const v1: T = { a: '1', b: '1', c: '1' }
const v2: T = { a: 1, b: 1, c: 1 }
const v3: T = { a: true, b: true, c: true }
const v4: T = { a: false, b: '0', c: 0 }

何が「期待されてないのではないかと思われる挙動」なのか

ここで（v4ではエラーになるのはともかく）、v1〜v3に代入している値は、型 A, B, C のどれにも代入できないにもかかわらず、それらの union である A|B|C 型には、コンパイル時のエラーにならず、代入できてしまう。これは、（静的な）強い型付けを期待しているプログラマの想像に、多分、反している。

仕様ではどう言っているのか

仕様 （ https://github.com/Microsoft/TypeScript/blob/master/doc/spec.md ） では（以下、2018年4月現在のバージョンである Version 1.8 を前提とする）、§3.4 Union Types に、次のようにある。

A type T is assignable to a union type U if T is assignable to any type in U.

(訳: 型Tの値は、union型Uに、Uのどれかの型に代入可能である場合に、代入可能である。)

ここで、次のようではないのは意図的なものなのではないか、と思われる。

***NOT*** / A type T is assignable to a union type U if and only if T is assignable to any type in U.
(訳（こうなってはいない）: 型Tの値は、union型Uに、Uのどれかの型に代入可能である場合、かつその場合に限り、代入可能である。)

つまり、このあたりの挙動については、型によって安全を保証することを諦めている（のではないか）と思われる。理由としては、最初に結論として述べたように、Discriminated Union を使えば、こういった問題は避けられるからである。

想像される実装

以下は tsc の実装を読んだわけではなく、いくつかの例で試した結果からの想像である。

複数個の object type のある Union型 U への object 型 T の代入可能かのチェックでは、

  1. まず、 T の属性名の中に、U の型のどれにも現れない属性名がないか確認する。どれにも現れない属性名があったら代入できない。この時、その属性の名前のみがチェックされ、型はチェックされない。
  2. 次に、U の型について、左から順番に、T が代入可能かどうかについて試してゆく。この時、通常の代入可能のチェックとは異なり、T の側に属性が余ってもエラーにはしない。
（これで、前述の仕様は満たされているはずです。また、以上の規則で説明できない例が確認できましたら、よろしければコメントください）

「Windowsの標準電卓で4の平方根が2でなかった仕様がようやく修正」の件について

「Windowsの標準電卓で4の平方根が2でなかった仕様がようやく修正」というニュース（ pc.watch.impress.co.jp ）がありました。現時点では私の手元にそんなに情報が無いので、

  • 以下で述べる内容
    • 以前の仕様のあらまし
    • 修正に関する憶測と心配事
  • 以下で述べない内容
    • 以前の仕様の正確な理由はなぜか
    • 具体的にどう修正されたのか

という感じになります。

以前の仕様について

プレスリリース（ https://blogs.windows.com/windowsexperience/2018/04/04/announcing-windows-10-insider-preview-build-17639-for-skip-ahead/ ）の中の Windows Calculator Improvements という節の中でリンクされているMSDNで開発者が書かれたブログエントリ（ https://blogs.msdn.microsoft.com/oldnewthing/20160628-00/?p=93765 ）と、そこからさらにリンクされている、もっと前のエントリ（ https://blogs.msdn.microsoft.com/oldnewthing/20040525-00/?p=39193 ）にあるように、大昔はもっとエエカゲンだった「電卓」ですが、近年は「an arbitrary-precision arithmetic library」により、「四則は無限精度」「それ以外の関数などは32桁の精度」で計算する、という仕様になっていました。

（明確には書かれていませんが、挙げられている例から見て、四則演算の間は除算の結果などは内部で分数として保持するようなライブラリ（すなわち、有理数演算の機能も含んでいるライブラリ）なのだと思われます）

そして、平方根は四則演算ではないので、有限精度で計算され、（後述の追記参照）、また、正の値であればどんな場合であれ全て exp(ln(x)/2) で計算していることから、√4 のような場合でも誤差が発生する場合がある（そして、それは気にしないでしょ？）、となっていました。

これ自体には問題はありません。コンピュータで以上のような計算のしかたをすれば、必ず起きる可能性があるものとして、受け取らねばならないものです。

なお、1.99999999999999999989317180305609 という数がどうやって出てくるのかについては、いくつか検討してみましたが、まだ糸口がつかめていません。（どうやら見つかりました。次の追記を参照）

追記: 平方根の計算に使っている ln と exp については、拡張浮動小数点演算を使っている（のだろう）と、小飼さん（@dankogai）から指摘がありました。十六進小数にすると 1.ffff_ffff_ffff_fffe0784a26b6c0c... ですので、上位の1の連続が、ちょうど拡張浮動小数点の64ビット（ケチ表現無し）と一致します。確かに！

憶測

以下は、これの修正に関する、あくまでも「憶測にもとづいた」議論です。具体的にどう修正されたのかがはっきりすれば、心配の必要は全てなくなります。

最も想像される修正

おそらく最も可能性が高いと思われるのは、入力の値が整数になっていて（これは前述のライブラリであれば、正確に判定できるはず）、整数平方根により正確な値が得られたならば（これも微妙な点は無いはず）、それを結果とする、という処理が、平方根の前処理として追加された、というもので、基本的に安全な範囲の修正と言えます。

確率は低いと思われるが、懸念される修正

以前のMicrosoftにはあった悪癖として、数値を扱うアプリでアドホックな手当をする、というものがありました（詳しくは、奥村先生が2001年2月に書かれた（と思われる）、「Excelの演算誤差」という記事（ https://oku.edu.mie-u.ac.jp/~okumura/software/excel/roundoff.html ）の、「恐ろしくて数値計算に使えたものではない。」と閉じられている最後の段落あたりを参照）。

元々のこの問題のチケットが、単に放置されていたのではなく、もし「WONTFIX」になっていたものを*1、わざわざ修正したのだとして、なぜ今更修正したのかがはっきりしてなかったとすると、「なんとなく直した」のではないかという懸念が出てきます。

アドホックに手当する、というのは、こういった問題で一番やってはいけないことで、もしそうだったら、という不安があります。

こうすればもっと良かったんじゃないかという気もする修正

徳丸さんのツイートによれば、

とのことなので、以下で私が考えるような「さいきょうの修正」は、されていない模様ですが、参考のために書いておきます。

平方根には「荒っぽい近似が得られれば、ごく簡単に精度の桁を倍近く伸ばせる」という性質があります。具体的には、ニュートン法の反復の1回の追加、すなわち:

  • 平方根を求めたい値を x
  • 得られている sqrt(x) の近似値を y

とした時、

  • y := (y + x/y) / 2.0

とすれば、1回でもかなり改善されます。また、見ての通りこの演算には四則演算しか使いませんから、Microsoftが「電卓」の実装に使っているライブラリで任意精度で計算できますので、これを1回（か2回）実行してから、例の「32桁」に四捨五入で丸めれば、

  • 全ての場合で精度が改善される
  • 問題だったような、「トリビアルに自明な結果」を外すことも無くなる（はず）

だと思うのですが、どうでしょうか。

*1:後述のように、平方根の計算には、簡単かつ確実に精度を上げる方法がありますから、それなりに意図的にそのままにしたものではないか、という気がします。

タッチパッド機におけるブラウザのJavaScriptの、エミュレートされたマウスイベントと、インタラクティブなコンテンツとの干渉について

サンプルを https://github.com/metanest/mobileBrowserMouseEmulationInteraction に置いてあります。

仕様としては、W3Cによるタッチイベントの仕様 https://www.w3.org/TR/touch-events/#mouse-events に含まれているのですが、タッチパネル操作のスマートフォンやタブレットのウェブブラウザのJavaScript では、タッチ操作のイベントの後に、（既存アプリ用の）マウス関係のエミュレートされたイベントを発生させることが、仕様で考慮されており、多くの実装がそのような挙動をします。

仕様中に、

If the contents of the document have changed during processing of the touch events, then the user agent may dispatch the mouse events to a different target than the touch events.

とあるように、先に発生したタッチイベントでコンテンツを書き換えた場合などは、同じ場所で後から発生する（マウス）イベントは、同じ場所に新しくできた違う対象に対して発行されるかもしれない、ということになっています。

これは実際のところ、厄介な挙動になり得ます。サンプルは、あるエリアをクリックするとオーバーレイが表示され、そのオーバーレイをクリックするとオーバーレイが消える、というものですが、スマートフォンのブラウザに表示させて試してみると、オーバレイがすぐ消えてしまうような挙動をする（場合が多い）はずです。実際にどんなイベントが起きているかは JavaScript コンソールに出力しているので、そちらで確認できます。

なお、仕様では、

If the preventDefault method of touchstart or touchmove is called, the user agent should not dispatch any mouse event that would be a consequential result of the the prevented touch event.

となっているので、（あるべしとされている通り実装されていれば）それに従うことで抑止できるはずです。

特に、各種のフレームワークの内部でこれが起きている場合、把握するのはなかなかに厄介です。

例えば、こちら（ https://github.com/callemall/material-ui-webpack-example/tree/master/src/app ）にある（2018年2月末現在）Material-UI のサンプルでは、react-tap-event-plugin というプラグインを利用して onTouchTap というハンドラで処理をしています。そしてこのサンプルを、onTouchTap の利用をやめ onClick のみに変更されている、バージョン 0.19.0 及び、それよりも後の Material-UI で動かすと、開いたダイヤログの背景の onClick が呼ばれて、ダイヤログがすぐに消えてしまう、という現象が起きます。*1

*1:こちらの記事も参照 Material-uiがreact-tap-event-pluginを廃止してた - まさたか日記