ある日曜日の白昼夢

DVDで映画を鑑賞できるということは

今はBlu-ray?いやむしろネットのバイナリストリーム時代、本質は変わらずデジタル。

DVD時代ではピックアップレンズがディスクの凹凸をデジタルとして読み取り、画像と音声を復元展開して光や音に変換する。ピックアップレンズは 01001110100.... みたいな一連のデータをひたすら読み取っていくのだが、解釈の異なる区間こそあれ全部繋げて1つの整数とみなせる。「作品が異なる」とは「整数が異なる」だけ。つまり、人が感動したり体感するコンテンツは数直線上のたった1点の整数値で表現できてしまうと考えることもできる。

それで、数直線には果てがないことから、ある人の人生全体を十分リアルに体験できる1つの整数がもう存在していると考えることも、無数の人生についてもそうだと考えることもできる。

現実空間は一次元に還元できること

電子などの量子は存在できる位置が確率的に決まっていて、連続に自由な座標をとれるわけではないという意味で、空間には解像度が存在するという話をネット記事で読んだことがある。その考え方を採用するなら、この宇宙全体を有限なデジタルデータに閉じ込めて、人の感覚器官や意識が享受するのに十分表現可能なポイントがありそうだ。

僕らは宇宙をそれぞれ連続無限な3次元の空間と考えがちだが、各次元をもっとささやかに、実数直線上で長さ1の有限な区間([n,n+1))みたいに切り取って、それを好きな数でグリッドに分割してx軸と名付ける。同様にy軸、z軸、他にも時間軸やエネルギー密度軸など自由に作ってささやか宇宙としてモデル化する。好きな数を決めてしまうことで有限になるとはいえ、決め方には制限が無いので、リアルな体験くらいならこの条件でも十分と考えられる。

たった1つの数に宇宙の生涯を収納したり、宇宙番号軸も追加してマルチバースの収納も可能に思える。

この宇宙の生涯を表現し尽くした数

忘れてならないのは数値の「解釈」で、同じ値でも圧縮アルゴリズムや次元の設定次第でことなる復元結果になり得る。だから、1つの数値が唯一の真実を表すことにはならなそうでもあり、ならばそこから先はもう何でもありじゃないかという話になってくるが、それはさておき円周率πという特異点、この秘密めいた数値は何だということも気にかかる。

仮にπを何か深遠なアルゴリズムで解釈してやると、この宇宙の生涯へと展開できるものとする。僕たちは五感あるいは感情を含む六感で宇宙を体験しているので、それらが含まれているに違いない。3.141592.. と3で始まるのも、この宇宙は空っぽの3次元空間から始まるみたいに見えてくるし、この地球にある三元牌という単語もひっそり差し込まれたユーモアに思えてくる。

また、宇宙の果てや最期が観測できないことはπが具体的な数値として確定できないことに関係していそうである。そのせいで「表現し尽くし」ていなさそうなのが歯がゆい。

ブラックホールの中から宇宙を眺めてみる

ブラックホールは物理空間の特異点で、その中はどうなっているのか、論理的に定義しようがない領域ということである。ってことはイマジナリーにしか到達できない領域といえる。

だったら自分で定義すればいいじゃないか!

さて、長年の努力の甲斐あってついに例のガルガンチュアのような神々しい威容への接近に漕ぎつける。ところで、傍からこの様子を観察すると、ブラックホール周辺に張り付いて全く動かなくなってしまうらしい。重力の影響でブラックホール周辺の時間の進みが極端に遅くなるのである。

事象の地平線に差し掛かるにつれ真っ暗だった背景が何だか明るくなってくる。よくみると背景全体に広がっていた銀河や星々や暗闇がぎゅーっと弧を描いて伸び始め、ある一点に集まってきている。最終的にそれらは強烈な光を放つビー玉サイズへ収束していく。その光景に心を奪われていると、ふと、ビー玉を手にのせて凝視している自分に気がつく。目の前には旧友がいて、おかえりとあいさつ。

もう一度ビー玉をよく覗いてみると、片方の極に3.141592..とあり、反対側の極は..2951413で終わっている(いや、..22221111のような気もする)。どうやら、このビー玉宇宙の開闢から寿命の終わりまでの体感ツアーが終了したようだ。ビー玉宇宙からするとここは時間が完全に止まった、あるいは逆戻りしている世界であり、この世界からみればビー玉宇宙のすべての時間は一瞬で過ぎ去る、あるいは一瞬で引き戻せる、つまりは同時に存在する、物質化しているというわけである。

ビー玉宇宙の円周率πは宇宙の最期とともにすべての観測者を失ったので以降の体感データ収納を必要とせず完結するに至る。

元の世界で

意識がここに戻ってきたとき、旧友の姿が少し奇妙に思えたが、むしろすぐにビー玉宇宙での体感アバターの方が不出来でいびつに感じ始める。なんであんな五体デザインなんだと笑えてさえくる。まるで昔のFPSゲームの没頭から我に返ったときみたいに。

旧友は他にもいろいろなビー玉を持っていて、3.1415926535から先が微妙にことなっていたり、4から始まるものだったり、5からはじまるものだったり、それこそ無数にあるようだった。目の前でその一つを2秒ほど見つめて「帰って」きたりしていたので、円周率のサイズが気になっていた自分は何の気なしに手のひらのビー玉をのぞき込むと、キーボードをたたいている自分に気が付く。しまった戻れないと思ったが後の祭り、やがてなんていびつな白昼夢かと感じ始める。

内容とは関係ないけどイマジネーション解放のお供に。

左脳さん、右脳さん。: あなたにも体感できる意識変容の5ステップ

「街とその不確かな壁」の個人的な感想

650ページ超の文章を脳裏になぞり続けたものだから、まるで映画館を出て興奮冷めやらぬ少年のようにところどころ文章が村上春樹調に引っ張られているかもしれないのはご愛嬌。

それほど具体的な内容に触れる感想は書いていないと思うものの、これから読むつもりの方はまず避けた方がよいと思うのでご注意を。

読み始めた当初、集中力がきれてどうしてもスムーズに読めなかった。多分、スマホ活字に毒されてしまっている。コンパクトな要約文を大量消費するように視覚を使いすぎており、文字列をたどる視線や思考が綺麗に直線を描けず、四方八方へ散らばってしまう。(まるで樹海脱出を試みる人が同じところをぐるぐる回るみたいに!)

村上春樹の小説は取っておきの楽しみの一つだったのに、あいにくと時間切れでございますと宣告されたようでひどく落胆した。

そこに現れた救世主は Youtube の暖炉の動画。


www.youtube.com

パチパチと薪を焼く炎を尻目に読めば、本作の情景とも相性よく、ブルブルとした低音の振動が、絡みついてくる雑念を平らに退けてくれて本筋のスムーズな流れにありつくことができた。

最近の iPhone なら筐体の再生音でも申し分ないとは思うものの、Bose SoundLink を通したら低音に立体感がでてなお良かった。ただしASMRのようなティングルがじわじわ効いてきてやがて眠気に抗えなくなってしまうのが玉に瑕であるが。

自分はプログラミングをするために、ある文章のしかけ、構造がたえず気にかかった。

  1. 現在形を使う
  2. 固有名詞を排除する

現在形を使う

動詞の現在形というのは日常にそんなに出現しない。私は走るとか、彼女は絵を描くとはどういう意味だろうか。昨日10キロ走ったこととか、今絵を描いていることとは実は無関係なところが、現在形の厄介な性格である。

現在形は、動作というより「性質」についての言及である。「性質」とは持続することであって、具体的な時点から切り離されている。人間は時間の流れの中で動く存在なのに、そこから切り離してしまうためかなり特殊なメタい言及となる。そんな言及が起こるのは、それがニュースとなる場合に限定されるだろう。彼女は絵を描くと言及した以後、その人が生涯絵を描くことがなかったとしたら、その言及は嘘になるのだろうか。(実はそうではない)

さて、プログラミングはすべて現在形による記述を行う。ある1行はこれこれの動作を行う、であり、行ったでも、行うつもりでもない。PromiseFuture といった非同期プログラミングにしても「ここで約束する」や「ここで将来が発生する」といった具合である。プログラムは指定動作を行う宣言の集合体、つまり性質の構成であり、これがハードウェア上で走って初めて、現実の具体的な時間(実行時点)と接点を持つ。絵を描くように組まれたプログラムがついぞ実行されることなくDeleteされたとしても、それが絵を描くプログラムであることには違いないのである。

過去、完了、現在進行、未来といった具体的な時点とは切り離された、ややこしい名前の現在形。これを考えるとき、個人的に、高畑勲監督のかぐや姫で頭巾をかぶせられるシーン、瞬間的に生き物としての時間を奪い去られるようなシーンを思い出す。そのように何か重しのようなものをスッと取り除かれたのが現在形。

現在形は、現実の時間もとい質量あふれる物理世界から切り離された、想像上の世界(あるいは記憶の中の世界)への言及ともいえる。プログラムには質量が無く*1、実行されない間は現実に影響の無いアイデアとして留まっている。私たちは、あまりそれと意識せず2つの領域(物理と想像)を抱え持ち行き来しながら日常を過ごしている。

固有名詞を排除する

読んでいると遅かれ早かれ気づくことになるが、本作では固有名詞を排除する、という執拗な工作が施されている。これまでの村上春樹作品では、1Q84 の青豆さんとかヘックラー・ウント・コッホとか、たいへん手際よく海馬にねじ込んでくる巧妙な固有名詞を使っていたから余計に気になった。しばらく読み進めても小説の舞台が何国かすら判然としない程である。小説において固有名詞の排除はやはり無理があり、代わりに使用される「私」や「君」のせいで、SCPアノマリに汚染されたみたいに文が破たんしている箇所がある*2。また、固有名詞が避けがたい箇所では、それがうらみを受けた肖像写真のように切り刻まれている。それゆえに普通の固有名詞が出現した際は逆にギョッとした程だった。

さて、この固有名詞を排除する挙動もプログラミングでは通常の作業である。プログラミングでは具体的な値の代わりに変数を置き、一般名詞で名付ける。こうすることで、その部分がより汎用的に仕事をこなすプログラムとなる。ここでもまた、具体性を取り去ることで任意時点の状況に対応可能な性質を与える、時間性を取り去る工作が行われていると考えられる。

時間の流れの中で時間性を失いあるいは取り戻す

私たちは具体的な日常を過ごしつつ、同時に時間性の無い想像の世界にも住んでいて、その2つは確かに本体と影のようにピッタリはりついたまま生活が進行している。以前、二十歳をすぎたら時間の過ぎるのが早く感じることについてエントリを書いたが、それは生活の中で固定された現在形が強く現れるようになり時間が進まなくなったように感じるせい、とも説明できそうだ。

現在形による時間表現は間違いなくそのように意図されていて、本作中でも2箇所ほどそうしているよと、あからさまに書いているのを目撃した。

また、現在形を典型的に使っていたシーンが自然な過去形に切り替わるポイントがあり、物語の象徴的な転換点、時の歯車が現実の時点に噛み合ってズシリと抵抗を感じ始めたことを示唆する・予感させる効果を生じさせていた。(そしてすぐ、その変遷はやはり明らかとなった)

さて、作中にスコッチウイスキーが出てくるのだが、なんてことか、偶然ながら全く同じ銘柄が手許にあった。これまで村上春樹の小説に出てくる曰くありげでお洒落な固有名詞の数々は想像をたくましくするしかなかったところ、今回ばかりは運命と、登場人物と一緒にショットグラスに少し注いで、トワイスアップにして飲んでみたら口当たりが甘くなり、甘さの向こうから焚火のような泥炭の香りがやってきて、とても魅力的な味わいになった。

静かな深夜2時くらい、小粋な描写の中身はこれのことでしたかと、想像力に反則気味の答え合わせを添えてみたものの、ペナルティとして酔いの眠気でその日の読了はキャンセルとなった。

近頃、ラフロイグの10年に味をしめ、そろそろ2本目をと思ったら手近な店にはもはやどこにも置いておらず、父と二人で酒店巡りにでかけたのだった。10年がどうしても見つからず、父のとっておきの提案で寄った酒店でついに見つけた帰り*3、ついでに寄った近場の量販店の酒コーナーで*4、父が目をつけたのが Bowmoreの12年だった。昔からの行きつけのバーFrançoisで飲んだことのある懐かしのスコッチウイスキーということだった。

『走ることについて語るときに僕の語ること』を読んだせいで、村上春樹はとても頑健な身体の持ち主という印象を持っている。彼は自分のことを繰り返し、鮮烈なひと時を生き抜く駿馬というより、辛抱強くて息の長い頑健なロバのように描いていた。きっとまた新しい小説を書いてくれるものと期待している。次もまた同じように楽しみつつページをめくりたい。

街とその不確かな壁

*1:ドライブに大量のソフトウェアをインストールしても重量は増えない

*2:破たんすらいとわず、といった意志を感じた

*3:ほんの短期間で1,200円も値上がりしていた

*4:そこのラフロイグはセレクトカスクだった

ChatGPTと少しお話してみて

まだかわいいヤツ。
牙を向きそうな片鱗もあるかもしれない。

Gmail 等の OpenID でさくっとサインアップしてさわれるWebサービスになっている。 ChatGPT

現状では5つ6つ質問を重ねると timeout error になってしまう印象。

ただ、日単位で改良バージョンがリリースされているようで、経験値をかき集めて急激に育っているかもしれない。

ChatGPT が面白いのは、質問への回答が会話全体の流れを踏まえたものになっている点。慣れない英語のチャットで回答に読み落としがあって、次の質問に「さっきも言いいましたけど~なのですから、・・・」と返されて、ホォ(#^ω^)ビキビキとさせられたのが新しくて楽しい。

「日本語で質問していい?(日本語)」と聞くと、「誠に申し訳ないですが私は英語専用で日本語には対応していないのです(日本語)」と回答があり、日本語使ってる自覚ないのと聞き返す一幕も。

最近何かと話題の量子もつれ量子テレポーテーションについて教えて!してたら、なんか期待と違う回答で、詳細を詰めていったら自分の勘違いしてた部分が判明した。お礼を述べたら、あなたの勘違いの修正のお役に立てて嬉しいってドヤレス来てこいつすげぇってボルテージが急上昇した。

現状 ChatGPT の課題もまたこの会話形式である印象を受けた。会話の流れを踏まえ続けるため、後続の回答計算がどんどん重たくなっているっぽい。テーマを1つ掘り下げていくと早晩 timeout error で応答不能になってしまう。ただ、大量アクセス下で計算リソースと時間を相当制限しているだろうからよく分からない。

試したが失敗した例

三行で要約して、的なのはダメだった。例えば、英語でのやり取りで、これ以降は30語以内で短く答えて=>もちろんです。これ以降はそうなるように努力します、私は自然言語処理のAIとして・・・と、それ以降も安定的に100語以上で答えてくれた。さっきの回答に何語使った?と聞いても答えられなかった。

ChatGPT の処理能力についてあの手この手で問うてみたら、私はそのように作られていないのでご期待には添えません、という押し問答になってしまった。ふとAIに自己言及を求める質問になっていると気づいたので、一般論で自己言及はNGなのか聞くと、無限ループを避けるため自己言及の質問をガードしなければならない、ただし自己言及を行うタイプのAIもあるという回答を得た。

チューリングテストについて聞いてみたけど、納得のいく答えには届かず timeout error に移行してしまった。これこれとは何ですか?=>〇〇です。までは調子が良いが、それでは、このように設定を変更すると答えはどう変わりますか?みたいな掘り下げは、文脈を取り違えたり、以前の回答を繰り返したりと、まだ荷が重いみたい。*1

感触

話題の自然言語処理AIの計算処理をムニムニッと触わってみたけれど、かなり体重を預けぎみに話しかけてもバインと跳ね返してくる手応えは素晴らしい*2。といって、腰を据えたお話を始めると目に見えて負荷が増大するのか苦しそう。また、期待と違う回答の時はこちらが質問を工夫する歩み寄りがいる*3。ということで、人間が普段当たり前にやっている終わりの無い思考活動って相当重厚な計算処理なのだとも再認識。

*1:いい話し相手ができたと思ったのに…

*2:英会話の頭を鍛える日本人の救世主ツールでは

*3:間違いをたしなめると謝ってくるやり取りは目覚めそう

W杯の神は Hot が好き

日本vsドイツ、スペインvsコスタリカコスタリカvs日本の結果を受けての感想。

サッカーワールドカップには魔物が潜んでいる、のではなく、ワールドカップの神が観戦している気がしてきた。

W杯の神を漫画的に創作するなら、まあラテン系で情熱的なプレイが好みで、気分を上げてくれるチームを熱狂の叫び声で賞賛する。

逆に、転がってる勝ちを安全に拾いにいくチームにはやたら冷たくて、楽しみにしてきたお祭りになんだお前ぇらつまんねぇとソッポを向く。

優勝したチームはどんなでしたかと振り返るなら、自信に溢れたプレイで大胆にゴールを狙うチームでしたねぇとなるのは明らかで、少なくとも優勝を目指すなら割り切ってそういうプレイに徹した方が結果もついてくる、という流れではないだろうか。(観戦側も楽しいし)

日本チームには不敵なほど自信たっぷりに、賢くイマジネーションで相手を圧倒して予想外の急所を突き、忍者おそるべしとトラウマを植えつけるプレイで魅せてほしい。(対ドイツ戦で人々を勇気づけた理由)

対スペイン戦は、攻撃は最大の防御が勝機と予想し、鮮烈な試合を楽しみにしています。

--

ということで日本代表おめでとう~🎉

このカオスリーグの結果を誰か予想できるというのか。ドイツ戦2-1を的中させたクリス・サットン氏の予想(2-1でスペインが勝利)すら超えて神がワロてるのでもう今回は優勝しましょう。

private-public

CSS の display プロパティに inline-block という属性値がある

その前提に blockinline があって block は塊同士の配置、inline は文字列内の配置と、 それぞれスタイルの趣向が異なる。

しかしながら、インライン要素であろうとブロック要素のように、 周囲の要素から距離をとって読みやすく強調したいこともある。

という都合から、inline-block という便利な中間属性が用意されている。 これがなかったなら窮屈で多くの人が不幸になってしまう、というくらい重要なものである。

Private か Public か

ウェブ上にはさまざまなコンテンツが公開されているが、すべて Public 属性を持たされているように思う。 公開した以上、公開した人に発信責任があるだろう、と判断される。

そうした責任を抱えたくなければ、Private にしておくこと。 つまり、非公開ストレージに保存して自分だけが閲覧できるようにする。

このシチュエーションには blockinline か一方しか選べない類の不幸がある。

インターネットには集合知の便益がある。 少なからぬアイデアが原石となって別の何かのヒントになり、 多くの利用者が連鎖的にそれらを用いていくことで、もっと有意義な何かが磨き上げられていく。

Publish にこうした公益性があるにもかかわらず、 内容が不適当だと判定されるや否や、発信者はつるし上げられ、さらし者にされてしまう。

例えば、有名人は SNS で軽口を叩くと即キャンセルされてしまう。 居酒屋で多少の毒も吐いてしまうのが人間だが、そこには真実が含まれていることだってあり、 ある程度は許されるのがリアルな社会である。

そういう発言をも拾う気満々の SNS において、 うっかり毒を吐いてしまったが最後、あなたの将来はロードローラーで均されて白紙となる。 SNS 事業者が得ている超絶利益を考えると利用者が一方的に不利過ぎないだろうか?

そこで、private-public のような属性を ウェブ上のコンテンツに持たせられないだろうかと考えてみた。

MIT ライセンス

イデアのひな型としてこれを使う。

MIT ライセンス(Wikipedia)はソフトウェアのライセンスである。

今回着目するポイントは、
公開されたソフトウェアは無料で自由に使ってよいし、
それによって得た収益を公開者に還元しなくてよいが、
使用で生じた不利益の責任を公開者に押し付けない、
という部分である。

のびのびとした発想で楽しみながらソフトウェア開発に専念できるよう、 開発者を保護することが念頭にある点が素敵である。

これをヒントに private-public を定義してみよう。

private-public

private-public コンテンツの公開者は次の条件を飲む:

  • コンテンツの公開によって収益を得ない
  • そのコンテンツで他者が得た利益に関知しない

private-public コンテンツの公開者は次の免責を得る:

  • 内容が不適切だとしても心証がちょっと悪くなる以上の不利益を被らない
  • 一義的におおやけの立場ではなく私的な発信と解釈される

private-public コンテンツの「利用者」は次の責任を負う:

  • リンクや引用は推奨されないコンテンツであることを踏まえる
  • 引用した場合、引用者の責任において引用者がその内容を発信したものとされる

SNS やブログサイト運営者は private-public な発信の条件を提供する特殊な立場とする。 彼らが発信責任を負う必要はない(そうしないと今度は彼らが窮屈になってしまうから)。 著しい誹謗中傷や風説の流布は法律に基づき許容されず、従来通り BAN するなりの対処が適切である。

private-public なコンテンツの引用は引用者自身の発信になるということで、 切り抜き投稿者や報道関係者やリンクを貼る者は気をつけなくてはいけない。 面白がってつるし上げようとすれば主犯者または盗撮者になってしまうから。

締め

例えば実名の投稿に private-public のようなラベルをくっつけることで、 居酒屋の会話だよという体で、実質的に気楽なオフモードでツイートしたり動画配信したりできるようになればどうか。

このアイデアはインターネットの便益を皆がよりスムーズに享受できる状況を支持する上で効果を発揮するが、 これを隠れ蓑にして誰かに不利益を与えてやろうとか考えた瞬間、雲散霧消して現状のウェブに戻ってしまう点には注意する。

Elixir v1.14 リリース記事の感想やメモ

v1.14 リリース*1

Rust の dbg! は理に適ってて羨ましいなと思っていたところやってくれた。 単なる真似では終わらせないという José Valim の心意気にしびれる。

--以下感想--

ElixirConf 2022 - José Valim - Elixir v1.14 - YouTube

これまでのリリースと同様、開発者体験に焦点を置き、デバッグ作業の改善、 デバッグツール、評価式の調査出力の改善を施した

dbg

Kernel.dbg/2IO.inspect/2 に似たマクロで、デバッグ作業用に特別にしつらえたやつである

IO.inspect/2 を置き換えるように使えて、デバッグコード自身とコードの位置、引数で与えた内容を要素ハイライト付き(!)で印字する

dbg/2 はさらに、マクロであることから Elixir コードを理解する
|> による連続パイプを渡すとそれらすべてのステップを印字する

IEx + dbg

IEx シェルでのブレイクポイントで行ごとのステップ進行が可能になった

iex> break! URI.parse/1

で、URI.parse 関数の先頭にブレイクポイントを置くと

iex> URI.parse "/foo"

デバッグモードに入り、現在行までに評価された変数を確認でき、n で一行ステップを進められるようになった

Break reached: URI.parse/1 (lib/elixir/lib/uri.ex:770)
                                                              
  767:   def parse(string) when is_binary(string) do
  768:     # From https://tools.ietf.org/html/rfc3986#appendix-B
  769:     # Parts:    12                        3  4          5       6  7        8 9
  770:     regex = ~r{^(([a-z][a-z0-9\+\-\.]*):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?}i
  771:
  772:     parts = Regex.run(regex, string)
  773:

pry(1)> n
...
pry(2)> n
...

これは dbg/2 でも利用できる
dbg/2 は構成可能なバックエンドをサポートする。
IEx は自動で既定のバックエンドを dbg/2 のバックエンドに交換し、
それが IEx 上でコード実行を停止させる

我々はこのプロセスを "prying"(=覗き見)と呼ぶ
なぜなら変数やインポートへのアクセスは得るが、コードの実際の動きは変更できないようになっているから

これはパイプライン上でも機能する
連続した |> パイプを dbg へ渡す(または末尾に |> dbg() をつなぐ)と、すべてのパイプを一行ずつステップすることが可能

既定では iex 上で dbg() を実行すると pry プロセス移行の Allow? [Yn] プロンプトが現れるが、--no-pry フラグをつけて実行するとモード移行を省略できる

dbg in Livebook

Livebook により Jupyter Notebook のような計算ノートの能力が Elixir にやってくる

Livebook チームは dbg のバックエンドとして視覚化された表現形式を実装した。 こいつのおかげでパイプラインステップの1つ1つが単独で機能するUI要素として描画される。 要素を一つ選び取って出力を見ることもできるし、さらに、パイプラインを並べ替えたり 一定区間を無効化したりしてその結果を即座に見られる

PartitionSupervisor

PartitionSupervisor は新しいタイプのスーパーバイザを実装する
単体の管理(supervised)プロセスがボトルネックになってくる状況で役立つようデザインされている

管理プロセスの状態が容易に区分可能である場合、PartitionSupervisor によってそのプロセスのコピーを管理し、 複数の独立したプロセスとして同時並行に走らせ、各プロセスが自分用の区画を持つようにできる

たとえば ErrorReporter プロセスがあり、それを使って監視サービスにエラー報告したいとする

# Applicaiton supervisor:
children = [
    # ...,
    ErrorReporter
]

Supervisor.start_link(children, strategy: :one_for_one)

アプリの並行動作が増えていくにつれ ErrorReporter プロセスは多数の他プロセスから要求を受け取るかもしれず、 しまいにはボトルネックになりかねない。 このような状況では、ErrorReporter のコピーを PartitionSupervisor のもとで複数起ち上げるとよい

# Applicaiton supervisor:
children = [
    # ...,
    {PartitionSupervisor, child_spec: ErrorReporter, name: Reporters}
]

PartitionSupervisor は既定で System.schedulers_online() と同数のプロセス(たいていCPUコアにつき1つ)を起ち上げる。 これで ErrorReporter プロセスへの要求経路指定として :viaタプルを利用でき、区画スーパーバイザを経由して要求を渡せる

partitioning_key = self()
ErrorReporter.report({:via, PartitionSupervisor, {Reporters, partitioning_key}}, error)

この例のように self() を区画キーとして使うと同じプロセスのエラー報告先は常に同じ ErrorReporter プロセスとなり、背圧形式を保証できる。区画キーにはどんな評価式でも使用可能

一般的な例

PartitionSupervisor の一般的かつ実用的な好例は DynamicSupervisor のようなものを区画化することである

単体の動的スーパーバイザ配下で多数のプロセスを開始するとスーパーバイザがボトルネックになり得る。 とくにスーパーバイザ上でプロセス開始の初期化に時間がかかる場合など。 そこで、単体の DynamicSupervisor を起ち上げることはやめて、複数起ち上げてしまう:

children = [
    {PartitionSupervisor, child_spec: DynamicSupervisor, name: MyApp.DynamicSupervisors}
]

Supervisor.start_link(children, staragegy: :one_for_one)

これで適当な区画で複数の動的スーパーバイザを起ち上げられる。

例えば、先ほどの例のように PID で区画を切るなら:

DynamicSupervisor.start_child(
    {:via, PartitionSupervisor, {MyApp,DynamicSupervisors, self()}},
    my_child_specification
)

バイナリのエラーと評価の改善

Erlang/OTP 25 ではバイナリ構築時のエラーと評価を改善したが、これらの改善は Elixir にも適用された。

v1.14 より前はバイナリ構築時のエラーはしばしばデバッグしづらい漠然とした"引数エラー"に過ぎなかった

Erlang/OTP 25 と Elixir v1.14 ではデバッグ作業しやすいようさらなる詳細情報を提供する
この成果はEEP54の一部である

以前のこれが:

int = 1
bin = "foo"
int <> bin
#=> ** (ArgumentError) argument error

これからはこうだ:

int = 1
bin = "foo"
int <> bin
#=> ** (ArgumentError) construction of binary failed:
#=>    segment 1 of type 'binary':
#=>    expected a binary but got: 1

コード評価(IEx と Livebook)も同様に改善されてエラー報告とスタックトレースが良くなった

Slicing with Steps

Elixir v1.12 で導入された ステップ範囲 は "ステップ"(=小ジャンプ) を指定できる範囲である

Enum.to_list(1..10//3)
#=> [1, 4, 7, 10]

ステップ範囲は特にベクトルと行列が関わる数値計算で有用である(例えばNxを見よ ) ただ、Elixir 標準ライブラリは API にあまりステップ範囲を使ってこなかった。 Elixir v1.14 では手始めにいくつかの関数においてステップ範囲をサポートすることでステップを活用していくことにした。

その一つが Enum.slice/2 である:

letters = ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j"]
Enum.slice(letters, 0..5//2)
#=> ["a", "c", "e"]

binary_slice/2(厳密には binary_slice/3 も)が Kernel モジュールに追加され、バイナリに対して同様にステップ範囲をサポートする

binary_slice("Elixir", 1..5//2)
#=> "lxr"

Expression-based Inspection and Inspect Improvements

Elixir では不透明構造体を特殊な表記でもって調査出力するように Inspect プロトコルを実装する慣習があり、こんな具合である:

MapSet.new([:apple, :banana])
#MapSet<[:apple, :banana]>

この表記は一般的には構造体の内容またはその一部が非公開で %name{...} の表現形式を使うと公開 API 以外のフィールドが露出してしまう場合にそれを嫌って行われる

#name<...> 慣習表現が残念なのは調査出力が有効な Elixir コードではない点である。例えば、調査出力をコピーして IEx セッションに貼り付けても使えない

Elixir v1.14 ではいくつかの標準ライブラリの構造体についてこの慣習を改めた
それら構造体の Inspect プロトコルの実装はこれからは評価すればその構造体が再生成される有効な Elixir 式を文字列で返す。

上の MapSet の例では、こうなる:

fruits = MapSet.new([:apple, :banana])
MapSet.put(fruits, :pear)
#=> MapSet.new([:apple, :banana, :pear])

MapSet.new/1 式は調査出力している構造体そのものへと評価される。この式なら MapSetの内部構造を隠せるし、それでいて有効な Elixir コードのままである。この式形の調査出力は Version.Requirement, MapSet, Date.Range について実装済みである。

最後に、我々は構造体の Inspect プロトコルを改善し、構造体の調査出力のフィールドが defstruct において宣言された順になるように変更した

例えば URI 構造体は以前までは各フィールドがアルファベット順に表示されていたが、

iex> URI.new!("https://elixir-lang.org/")
%URI{
  fragment: nil,
  host: "elixir-lang.org",
  path: "/",
  port: 443,
  query: nil,
  scheme: "https",
  userinfo: nil
}

これからは URI 構造順に出力してくれる

iex> URI.new!("https://elixir-lang.org/")
%URI{
  scheme: "https",
  userinfo: nil,
  host: "elixir-lang.org",
  port: 443,
  path: "/",
  query: nil,
  fragment: nil
}

また、:optional オプションを追加して Inspect プロトコルを導出(deriving)する際に開発者が構造体表現についてより制御できるようにした

更新されたドキュメントで使い方の概略と利用可能なオプションについて見よ

Learn more

完全な変更リストについては、full release note を見よ

楽しいデバッグ作業を!

*1:日々のドキュメント作業に追われブログする暇など無くなった

「自己肯定感」という奇妙な用語

「パラレルワード」

最近本当によく耳にするようになったキーワード。
聴くたびパラレルワールドに迷い込んだ錯覚に陥るという話。

自己効力感とのニアミス

昔、教育学の講義で学習に関するキーワードとして「自己効力感」という概念を教わった。対義語は「学習性無力感」だろうか。 一方、「自己肯定感」なる用語は当時聞いた記憶が無い。*1

数年前、知人との会話で子どもさんの教育の話題になり、私見として、RPGみたく「自己効力感」が得続けられるバランスで学習要素を少しずつ自分で攻略していくデザインになっていれば云々と述べたことがあった。

その時、知人に「『自己肯定感』かぁ~、独りよがりなのもなぁ・・・」みたいに反応されて、何かニュアンス違うし、そんな言葉知らないし、まあ絶妙に隣り合わせな感じだし取り違えかくらいに思って流した。

そんな出くわし方をした。

使いどころが無いように見える、という抗議感

「自己肯定感」はどうやら世間では

  • 自分はこれでいいんだよ😀と思っていること

という肯定的なニュアンスで使われていて、ただ、それなら「自信」というよりピッタリな用語があるし、「自己肯定」じゃなくて「自己肯定”感”」という珍妙な姿のせいで知人がいったような

  • 他者の指摘に耳を貸さない気分
  • 自己暗示にかかっている感

みたいな否定的なニュアンスが見えてしまい、そんなに由緒正しくない、会話中に飛び出してしまったローカルスラングくらいに思われてしまう。

いつの間にか皆が使っていて事実が後付けされた感

そしたら、その後数年かけて「自己肯定感」を耳にする頻度が増え、由緒ある人たちさえしかるべき場所でバンバン使うようになったし、本当かよと調べたら学術用語でしたですけど?とかなっているし、ちょっと待って世界が何かおかしいの、と。

そんな言葉なかったよね感というか、パラレルワールド感がつきまとうキーワードに変貌している。あるいは、かの知人が現実改変能力を持った SCP アノマリ*2で、俺の言動に突っ込むことはさせねーよ感。

最後にまじめに考えると

実際やってみて、なるほどこうやればうまくいくわけね、という手応え(自己効力感)と、なら自分にもやっていけそうだと思うこと(自信)は通常一つながりの物語になっている。

そして今はデフレの時代で、まあ大抵の人が強制的にうまくいかない負け組になるメカニズムにはまり込んでいるため、オレナンカドーセっていう「自己否定」がデフォルト化してしまった。

そこで、うまくいかなくたって自分を否定しなくていいんだよ、とささやかな抵抗を表明する「消極的な自信」、「根拠薄弱だけど自信」、せめて自己暗示くらい許してよっていう、時代ならではの気分が口をついて出る哀しい用語といえばそうかもしれない。


追記

イチロー氏が同じ世界線から来ていることを確認しました。 https://www.youtube.com/watch?v=W1cksiP7NE0

という冗談をきっかけに、もうちょっと自分なりにこの言葉について、拭いきれない違和感を反芻してみた。

というのも、この言葉の背景には性的マイノリティとか周囲から浮いてしまう嫌な自分といった逃れがたい気質などの深刻な問題があることを公開後に認知したためである。

そこで、急ごしらえの思いつきで申し訳ないけれど、そうした状況を扱う用語として、例えば「存立肯定」という造語を提案してみます。これは「対象に自然に備わった気質や特徴によらずその対象を受容すること」というニュアンスを客観的に表現しようと意図しています。(単純な置き換えは不可能でしょうがピントの甘い用語で意思疎通に混乱をきたさないようにとの思いで)

*1:単なる記憶の選択かもしれない

*2:はてなタグが反応しなくて意外だった