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

詳細は後日（の予定）

2018-06-10

「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:国研での用語調査の際の集計対象を文節としたので……といったような話。

2018-05-03

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

結論

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

事実関係

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

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

IEEE Standards Association からの発表 http://standards.ieee.org/news/2017/ieee_tron.html
トロンフォーラムからの英語記事 http://www.tron.org/blog/2017/12/ieee-standards-association-ieee-sa-and-tron-forum-sign-agreement-to-advance-iot-development-and-interoperability/

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

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

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

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

例えば 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 ）とか出るんですかどうなんですか。

2018-04-17

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 の代入可能かのチェックでは、

まず、 T の属性名の中に、U の型のどれにも現れない属性名がないか確認する。どれにも現れない属性名があったら代入できない。この時、その属性の名前のみがチェックされ、型はチェックされない。
次に、U の型について、左から順番に、T が代入可能かどうかについて試してゆく。この時、通常の代入可能のチェックとは異なり、T の側に属性が余ってもエラーにはしない。

（これで、前述の仕様は満たされているはずです。また、以上の規則で説明できない例が確認できましたら、よろしければコメントください）

2018-04-06

「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、わざわざ修正したのだとして、なぜ今更修正したのかがはっきりしてなかったとすると、「なんとなく直した」のではないかという懸念が出てきます。

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

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

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

√4 - 2 は 0になったけど、√ (0.04) - 0.2 = -3.087945572168994e-21 なので、アドホックに修正したか。まぁ仕方ないと思いますが / “Windowsの標準電卓で4の平方根が2でなかった…” https://t.co/oMo5gOPqoY
— 徳丸浩 (@ockeghem) 2018年4月6日

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

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

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

とした時、

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

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

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

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

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

2018-03-01

タッチパッド機におけるブラウザの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を廃止してた - まさたか日記

2018-02-21

JavaScriptのモジュールのimportの循環が必要な場合について

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

実行するには、package.json と package-lock.json を同梱してありますので、まず npm を次のように実行して必要なモジュールをインストールした後*1、

$ npm install .  # 最後の . (ピリオド) を忘れないように

run_webpack.sh を実行すると、webpack が実行されて、ディレクトリ dist1/ と dist2/ の中に NodeJS で実行可能なスクリプトが生成されます。

用語の定義

以降の説明の都合で、JavaScript のスクリプトの実行の流れに関して、少し用語の定義をします。

次のようなスクリプトを実行すると、

console.log(1);
function f() {
  console.log(4);
}
console.log(2);
console.log(3); f(); console.log(5);
console.log(6);

1 から 6 まで順番にコンソールに出力されますが、このような場合の 4 以外の実行の流れを「上から下への実行」、4 の流れを「関数内の実行」と、以下では呼ぶことにします。

循環があっても、関連が疎であり、特に問題が無い場合

src1/ にソースが置いてあり dist1/ に生成されるサンプルは、循環があっても特に問題が無い場合です。

具体的には、mainが次のようで、

import isEven from './isEven';
import isOdd from './isOdd';
console.log(isEven(4));
console.log(isEven(5));
console.log(isOdd(6));
console.log(isOdd(7));

実行結果は次のようになります。

$ node dist1/main.js
This is in isOdd
undefined
========
This is in isEven
[Function]
========
true
false
false
true

また、それぞれの子モジュールの内容は次のようになっているのですが、このように「関数内の実行」からのみの参照であれば問題はありません。undefined が出力されている場所があるように、「上から下への実行」の途中では、import の結果が undefined になっている時はありますが、関数が実行される時には「中身が出来て」います。

// isEven.js
import isOdd from './isOdd';
console.log('This is in isEven');
console.log(isOdd);
console.log('========');
export default x => (x === 0) || isOdd(x-1);

// isOdd.js
import isEven from './isEven';
console.log('This is in isOdd');
console.log(isEven);
console.log('========');
export default x => ! ((x === 0) || ! isEven(x-1));

対称的になっている通り、mainにおける isEven と isOdd のインポートの順序も、どちらでも構いません。

ksmakotoのhatenadiary