Arrival、メッセージ、あるいはあなたの人生の物語

テッド・チャンの傑作短編「あなたの人生の物語」映画化、見てきましたよ。タイトルArrival、邦題は『メッセージ』だったっけ?

IMG_20161120_165339.jpg

とうぜんみなさんも原作は既読だと思いますが、結論から言うとこれはよい映画化の成功例。なにもかも原作通りということでもなく、しかし原作の基本的な方向性とエッセンスをそのまま、うまく映画のかたちに構成している。これ映画にしてどうするの?と思ってたけれど、なんとびっくり、あれもこれもある。

見終わった後、これは再読せねばと思い読み返してみたところ、基本的なエッセンスだけじゃなくてかなりいろいろ原作のネタを拾って映画として再構成していたなあ、ということがわかって再度感心。カンガルーの語源の俗説とか、そういう小ネタもきちんと原作に出てきたものを拾っているのかーと思ったりしました。

ちょっと意外だったのは変分原理の話が(たぶん)出てこなかったところ。というかやはり、映画では細かい設定について一つ一つ説明したりはできないわけで、結果的にあれとか超能力めいてしまっているのだけれど……まあこれはこれでよいのかもなあ。

まあ俺みたいな小うるさい原作厨でもこれは良かったですよ。ヒットするような作品ではないと思いますが、ぼくの友達とかには当然おすすめ。個人的には実はちょっと序盤はちょっと展開がかったるいので眠くなってしまいましたが、最終的には楽しめる作品になっていましたので、飽きっぽい人間の皆様も頑張って起きてください。


それにしてもタイトルのArrival、ちょっと意味わからないのですが。邦題の『メッセージ』のほうがなんとなく意味が通じる気もしないでもないこともないでもない。

 

『シン・ゴジラ』北米初日に観た

img_20161011_191255

10月11日から一週間だけ北米で上映中の『シン・ゴジラ』をようやく観ました。

ともかく、満足。大満足。よかったよかった。観られてよかった。

内容や感想はともかく周辺状況を記録しておくと。

私のいったところはモール内の映画館でしたが、客の入りは4割ぐらいかな……。平日の夜だし、まあこんなもんじゃね?という気がします。日本人はぼくら以外いたのかなあ、普通に地元の人々が大多数でした。もちろん、地元といってもそういうのが好きなコアな人々が見に来たというところでしょう。

意外とアメリカネタのセリフがありましたが、そのたびに客席がいちいちウケていたのも面白かった。客層が、日本のものが好きな人々だからってのはあるのでしょうけれど。もともとのセリフでは「あちらさん」とか婉曲表現だったものが字幕ではほぼそのものズバリ The US とか America とか大変直裁的表現になっていたのもあったのがまたちょっと面白い、というのがあるかもしれないですが。

北米では不評、というニュースをいくつか目にしますが、現時点で Rotten Tomatoes は 78%、 IMdb では10点満点で7.7というスコアは決して悪いものではない……というかそれなりに高い評価だと言えると思います。もちろん今スコアをつけているのは相当コアなマニアたちなので、これから点数がどう推移していくかはわかりませんが、不評ということではないのでは。……とはいえ北米ではわずか一週間のみの公開、しかも上映は各館一日一回だけ、というスケジュールなので、これはまあ届くべきマニアに届けることを考えたものであるのもまた間違いないことでしょう。

てなわけで、当然ながら北米の配信はマニア向けでありまして、その当初の目論見どおりごく一部のマニアに届く感じになっていたということではないかなと思います。

はーそれにしてもこれでようやくネットの情報に触れることができるな。

TypeScriptのStructural Subtypingの話2

前回の記事ではNode.JSのCモジュールなどTypeScriptの世界だけで完結しない話について型システムがどう扱うか、ということを書いた。

今回は近いところでちょっと違う話。

前回の話を考えているとき、TypeScript自体のソースコードをちょっと調べていて気づいたパターンがある。それはたとえば https://github.com/Microsoft/TypeScript/blob/master/src/compiler/types.ts#L13 などに特有なのだが、 brand という特殊なフィールドを持つ型が何箇所かで定義されている。

この例では

export type Path = string & { __pathBrand: any };

という定義で、これはPathという型を定義しているのだけど、実質的にはPathはstring(文字列)だということを言っている。Node.JSではパスに対しては文字列が使われているという現状からそのようになっている。

そしてTypeScriptはインタフェースさえ合っていれば同じように引数に渡せるため、この型システムではPathとstringを区別することはできない(なぜなら同じ型だから!)。引数の順番を間違えたとか、そういうケアレスミスによって間違った文字列が渡されても間違いが検出できない。

そこで __pathBrand というフィールドを Path 型の定義に追加している。ただの文字列にはこのフィールドはない。またPath型を返す関数は文字列をType assertion (キャストのようなもの)によって変換しているため、実際のコードには __pathBrand は出現しない。

これによって全く同じ型の値をそのまま扱いつつ、些細なミスをコンパイラが検出してくれるようになる。

似たような仕組みは構文木にも現れていて、特定の構文要素をグルーピングするのにこのようなbrandのようなものを使い、間違ったものを渡すようなケアレスミスを防いでいる。

もちろんこのテクニックは完全ではなくて、やろうと思えば適当に __pathBrand のようなフィールドを追加してやることでチェックを迂回できる。でもいかにも意味のありげな名前だし、コメントにも明記されている(vscodeなどではこういうコメントも付随して定義されているし)。そして何よりこのテクニックは正確に検証するというよりはケアレスミスを減らすためのテクニックなので、意図的に回避したい人を止めるものではない、っていうところだろう。


こういうことをやりたければ、ふつうの関数型言語であれば新しい型を定義したり、 phantom type を使ったりするところだと思う。

Go言語であれば普通に新しい型を定義して元の型と互換性をなくすといったところかな。

こんな具合に「構造上は全く同じだが何らかの事情で処理系上は区別したい型」というのは、現実のプログラミングでは意外とほしくなることがあり、インタフェースの一致だけに限定したシステムだけではこういう区別はできない。そういう事情でTypeScriptにはこんなテクニックが使われている、という話でした。

Ruby 3ではこういう問題をどう扱うのかな、というのは気になっています。

TypeScriptのStructural subtypingがうまくいかない場合

少し前にTypeScriptを勉強していて、この型システムだと実装を隠蔽した型というものをうまく表現できてないな、と思ったことがあったのでメモしておく。

TypeScriptはJavaScriptに型情報を与えられるように拡張した(それ以外にもいろいろ拡張のある)言語だけど、JSらしいゆるさを残した仕様になっていて、基本的には構造の同じものは全て受け入れるようになっている(Structural subtypingという)。

interfaceという定義がGoのinterfaceのような感じになっていて、継承関係は全くなくても同じインタフェースのオブジェクト(ようは特定のフィールドを持つオブジェクト)であればコンパイラは通してくれる。

interface Foo {
  foo: string;
}

function foo(f: Foo) {
  console.log(f.foo);
}

foo({foo: 'foo'});  // OK
foo({foo: 1});      // NG: foo is not string
foo({bar: 'foo'});  // NG: interface mismatch

で、世の中には実装を隠蔽したいことがあるのと、TypeScriptだけではうまく完結しないものがある。ある種のファクトリーから生成されるオブジェクトだけを受け入れたい、とか。Node.JSのCモジュールが関連するオブジェクトなので内部実装がJS/TSでは表現不可能だとか。

こういう状況をTypeScriptではうまく表現できないように思える。

内部的なデータ構造は表現できないので、

interface Foo {
}

のように書くと、Foo型の変数にはおおむねどんな値でも代入できてしまう(指定されている構造に一致するため)。そこで本当には存在しないけれども、内部的に何らかのものを持っていますよ、ということを意味する適当なフィールドを入れてみる。

interface Foo {
  _impl: ...
}

だがこの場合でも、_implの型はなんであれ、その値を適当に作って _impl に入れることで簡単にこのインタフェースを実現できてしまう。

まあ実用上はコメントでも書いておけばよいのだろうけれど……。

なお、TypeScriptにはクラスもあるが、クラスもインタフェースが一致していれば通すためこの目的には合致しない。

class Foo {
  foo() {
    console.log('foo');
  }
}

function fooer(f: Foo) {
  f.foo();
}

class Bar {
  foo() {
    console.log('bar');
  }
}

fooer(new Foo());  // No problem
fooer(new Bar());  // OK, Bar is compatible with Foo

ただ、プライベートなフィールドを勝手に設定すると、この問題は解消できる。

class Foo {
  private _impl: any;
  foo() {
    console.log('foo');
  }
}

function fooer(f: Foo) {
  f.foo();
}

class Bar {
  private _impl: any;
  foo() {
    console.log('bar');
  }
}

fooer(new Foo());  // No problem
fooer(new Bar());  // NG

これはTypeScriptではprivateなフィールドは互換でないと判断されるからだ。

ただしこの手法の場合でも、Fooに相当するクラスが(TypeScriptレベルでは)実在してしまうため、通常のクラス操作であるnewもできるし、Fooを継承したサブクラスも定義できる。Cモジュールなどから得られるデータ型はたいてい何らかのファクトリー関数から生成されるので、データ構造がうまくあわなくなることがある。けっきょく、こういう状況をTypeScriptで表現するのは難しい、ということだ。


……という理解だったのだけど、この記事の草稿を書いてから今に至るまでにTypeScript 2.0がリリースされて、この問題は解決された。

どういうことかというと、TypeScript 2.0からprivateなconstructorを作れるようになった。これにより、外からnewできないクラスというものが定義できるようになった。そしてprivateなconstructorを持つクラスは継承できないとされた。

class Foo {
  private foo: any;
  private constructor() {}
  static create(): Foo { return new Foo(); }
}

function foo(f: Foo) {
  console.log(f);
}

foo(Foo.create()); // OK
foo(new Foo());    // NG: private constructor
foo({foo: 1});     // NG: 'foo' should be private

// NG: cannot extend a class with private constructor.
class Bar extends Foo {}

というわけで、こういうクラス宣言により、うえで書いたような状況はうまく表現できるようになった。現実にはd.tsファイルにこういう定義を書いておき、内部実装はJSとCモジュールに適宜実装されることになる。

それにしてもプライベートなコンストラクタというのは、コンパイルされるとどうなるのだろうか。クラス名が手に入ればJSレベルではnewできるんだけど…………と思ったのだけど、どうもTypeScriptコンパイラは可視性の情報を落とすだけなようなので、JSからは普通にnewできるクラスに見えるらしい。まあそりゃそっか、という話であるし、それでいいよなという話でもあるのだった。

guildっぽい単語

http://rebuild.fm/158/ を聞いてて、 guild でも別にいいし、この辺の単語は一通り検討されてる気がするけれどなんとなく思いついたものを書いてみる。


Rubyの “guild” についてはどういうものかというのは http://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf に書いてあるが、互いに参照関係にないオブジェクトのグループ分けを行うことで、異なる「ギルド」に所属するスレッド同士は独立して(パラレルに)動作できる、という仕組み。

パラレル・コンカレント系の用語なのでスレッドナントカ、とか系の単語がいいのかも、と思ったけれど、話を聞いた感じではどちらかというと概念的にはオブジェクトの所属関係を意味するものなのか、という印象を受けた。

そうすると集団を意味する単語系のtribe、clan、caravan、群れ系のhorde、troop、bandなど、あるいはregiment(連隊)、battalion(大隊)、company(中隊)などの単語はどうかなぁ。

あとは所属関係を地理的なアナロジーでとらえて、continent、planet、universe、world、galaxyとかみたいな単語とか。

あんまりいい案ではないかな……。まあとりあえずそんなかんじ。

ところでスレッドをたばねる単語としたら日本的には「板」(board)なのではないでしょうか、などと言ってみるテスト。

 

tensorflowの型付け

http://shinh.skr.jp/m/?date=20160912#p01

はいその通りです。というか前者の意味なんだとすると、それはなんというかその、一般的に動的言語は全部ダメという結論になってしまうように思うのですけどどうでしょうか。あと変数名typoはJSなら “use strict” で防げたりする、といったこともあるので、型というよりは処理系や言語仕様の話じゃないかなぁという気も。


で、tensorのサイズの型付けなんですが、理論的には依存型(dependent types)で解決済の話題という気もする。確かリストのサイズを型レベルで覚えておいて、空リストへのheadをコンパイルエラーにする話とかあったよなー……と思って検索したら https://www.schoolofhaskell.com/user/konn/prove-your-haskell-for-great-safety/dependent-types-in-haskell みたいな話はあります。

ただまあ理論的な結果があるといっても、現実の問題に実際に適用してみたらいろいろな細かい問題はおこりうるだろうとは思うんですよね。convolutionみたいな引数はけっこうややこしいだろうし、embedded lookupみたいなので値域とサイズが入れ替わる場合とかもあるし。

あと自然言語処理みたいな応用例だと数万次元とかあるわけですが、サイズをナイーブにチャーチ数でエンコードしたらパフォーマンス的に大丈夫なんだろうか、とか。

まあそれなりにやってみたら面白いのでは、というのが素人考えですが、理論的には大して面白くないかもしれない。

ドラマ『シリコンバレー』シーズン3

HBOのテレビドラマシリーズ Silicon Valley のシーズン3がGoogle Playに来てたので観た。今回も面白かった!

シリコンバレーの大企業Hooliから飛び出したリチャード・ヘンドリクスが創業したスタートアップ、Pied Piperの面々の活躍(?)を描いたコメディシリーズのシーズン3。Hooliとの訴訟を乗り越えたものの最後の最後でいきなりの解任騒ぎとなったシーズン2のラストでしたが、そこからそのままつながったシーズン3も見どころは多く、いろんな小ネタがてんこ盛り。

ネタ的には、主人公のリチャード・ヘンドリクスがタブ派であることを明言し、せっかくできたfacebook社員の彼女とタブ・スペース論争で喧嘩して別れるあたりがおかしいし、冒頭でベンダーのエンジニアがコーディング規約に従ってくれない……という話からの展開はまあ見事。ただ一番面白かったのは Pipey。あれは声を上げて笑ったし本当になんというか、完成度が高い……。

それにしても、ギークネタの使い方もうまいですけど、毎回毎回いろんな小ネタをはさみつつ、各回でもきちんと起承転結がついていながら、思わぬ伏線が回収されて綺麗な結末に着地していく流れが本当に見事だなと。シーズン2の判決シーンも好きなんだけど、シーズン3のラストも謎の感動がありました。


ところでオープニングも毎シーズン微妙に細かく変わっていていろいろ芸コマ(YouTube)。シーズン2で出現したUberのバルーンは脇に出てきたLyftのバルーンとぶつかってるし、ドローンが飛び交ってるし、Yahoo!のところに阿里巴巴があるし、Googleの上にAlphabetの看板が立ってるし。

Screenshot 2016-09-06 at 00.08.53

比較のためにシーズン1の動画を見てたらsgiが崩れてGoogleになったりNetscapeがChromeになったりMyspaceがあったりNapsterのバルーンがしぼんで落ちたり、とにかく芸コマですし、ちゃんと時流を合わせててすごいなぁ。

Screenshot 2016-09-06 at 00.11.44.png

手もちのChromebookにもPlay Storeが来たので

手元のChromebook Pixel2にもGoogle Play Storeが来ていて大半のアンドロイドアプリが利用可能になってました。

喜び勇んでいろいろと入れてみた。

Screenshot 2016-09-01 at 20.27.39

しかしまぁなんだな。思ったよりも「これを入れねば!」というアプリってあんまりないんだよなぁ。Kindleはクラウドリーダーはいろいろしょぼいので良いかも、というのとあとはSkypeぐらい? てかまあSkypeも、もう何年も使っておらず、そっちで繋がってる人々はそんなにいないし。

微妙にウェブ対応がしょぼいやつで、モバイルアプリのほうが良いやつとかもあるんだろうけど、あんまりデスクトップで使うものというのもないものですね。アンドロイドアプリはモバイルコンテキストで使うものが多いしな。

あとはゲームとかなのかなぁ。

とりあえずFirefox(モバイル)を入れて「おーChromeOSでFirefoxがうごいた!」って遊びをしている……

猫を飼う

本当に唐突ですが、猫を飼うことになりました。

IMG_20160818_194922

以下、適当に体験談の羅列です。日本とアメリカの違い的なことを言おうかと思いましたがよく考えてみたら日本のことも知らんしアメリカの一般論はわからないので。

猫の引き受け元

検索してみたり、先達からの教えに従い、Silicon Valley Animal Control Authority (SVACA) という施設に行きました。いわゆアニマルシェルターで、里親から引き取ってしばらく育てながら引き取り手を探したりするような団体のようです。サンタクララにあり、我が家からは激近。

ほかにもサンノゼだとThe Dancing Catという猫カフェ(兼シェルター)があったり、ほかにもペットショップもあるようですが、なにぶん行っていないのでわかりません。

さてこのSVACAという施設も、特に予約などはせず、ある週末いきなり行ったのですが、ふつうにいろいろ見せてくれました。猫はたくさん、ほかにウサギと犬がいくらか、といったあたり。猫は2-6ヶ月の仔猫が多かったですが、年のいった子も多少いました。引っ越しとか飼い主が去らざるを得なかった事例とかなのかな。猫はどれも(もとの飼い主からつけられた)名前がついていました。動物の分布はタイミングにいっても変わるでしょうけど。

で、実際に行ってみて、さらに部屋に入って実際に戯れたりしてみた結果として「この子にしよう」と決まった場合は係の人にその意思を伝えて引き受けるということになります。

猫の引き受けの手続き

ただうちの場合、ほんとうにいきなり手ぶらで行ったもので、そのままでは引き受けることはできませんでした。最低限、猫のキャリーを持ってこないと引き受けても連れて帰ることができないため、手続きをしてくれません。その他、こちらも猫を飼うのは初めてということもあり、必要な用具もよくわかりませんので、アニマルシェルターの人に教えてもらいました(その後、適当に日本語で本も買った)。

行ったのは夕方ということもあり、もろもろ買い揃える時点でその日は終了。残りは翌日以降ということですが平日は引き受けに行くのは難しい……。ともあれ、24時間はホールドできるとのことで、押さえてもらってその日は退散。

そのあいだにいろんな用具を買い揃えつつ、ちょっと忙しくて引受に行けない……となったのですが、やっと金曜に引き受けられる目処が立った、という感じ。

実際の引き受けの手続きはもろもろの書類手続きと注意事項があって、adoption feeというのが$150でした。medical recordもくれました。

13996031_1025917497503624_2490766977086030669_o

引き受け後

わたしはアパート住まいなので、管理会社に確認をしないといけません。事前に確認を取ったところでは猫は問題なし、ただしdeposit(敷金みたいなものですかね)が追加で$300、また家賃が毎月$50上がるということでした。なので引受後にまた受付に行って、猫の名前と特徴(色とか)を記した書類に改めてサインしてdepositを払って完了、ということになります。

またこの子はマイクロチップは埋め込む処置が行われていたので、その登録も行いました。避妊手術は処置済のようです(英語で検索すると生後8週間程度以降からは避妊手術は安全とされているようです)。

なお猫は室内飼いが原則になっています。これは書類にも明記されているし、またアニマルシェルターから引き受ける際の書類にも明記されていました。現実問題として車に轢かれるなどの危険性が大きいので、猫は部屋から出さないほうがいいのだろうと思います。そもそも野良猫や半ノラみたいな猫は見かけない気がしますし。

というわけで、猫を飼う話でした(案外書くことないなぁ)。

IMG_20160817_200113

Suicide Squad

IMG_20160806_190730

ううーん、微妙!

あんまり期待せずに見に行くと面白いかもしれませんが、傑作とかではないなぁ。なんというか、話が薄いというか話がないというか……キャラを出しすぎてメインのプロットが崩壊している気がする。序盤から手際よく主要キャラクターを紹介していく流れはずいぶん飛ばしているなーとは思ったんですがしかし……。

その分キャラはまぁ魅力的。ハーレイ・クインは事前の評判どおりの良さでしたが、ウィル・スミスのデッドショットが個人的にはけっこう良かった。他の人たちと違ってデッドショットさんは職業的な暗殺者なので、性格破綻者ぞろいのチームの中で比較的まともな性格な感じで割りを食っているかんじなんですよね。

でもやっぱりキャラが多すぎると思うんだよな……。この人もまあこの人でいいけど、出てこなくても話は成立しましたよね?というキャラはいる。けっこういる。テレビシリーズなら人が多くても話数で掘り下げられるけれど、2時間の映画でこの人数で話も掘り下げて敵側の話も描いて……というのはどうしても無理がある。その歪みはそのまま放置されていてしわ寄せされている箇所がおおいという印象。キャラを減らしてメインのストーリーラインにうまく絡めるのが映画としての常道ではあるはず。が、そこをあえてこの方向性にふったわけだ、という捉え方はある。

が、それはそれとしてこういうキャラいいよね?という楽しみ方の映画なのだとすれば、面白くて魅力的なキャラたちが出てくるので、ありなのかもなと。でもそれはちょっと私が求めていたものとは違うかなぁ。

あとジョーカーさんもう少し活躍シーンあるのかと思ってましたね……。