5時です。もはや今日です。まぁ今日はおやすみの日なので良いということにしちゃいましょう。
直感主義の意味論の1つで ((P→Q)→P)→P を計算する図です pic.twitter.com/ry8bw1pblZ
— phi16 (@phi16_) 2020年5月28日
ここ2日延々と直観主義について考えてきた成果がちゃんと出て私はとても満足です。これでもう当分 Kripke semantics のことは考えなくてよいでしょう。
まぁ Rieger-Nishimura ladder 置きたい気持ちはあるんですけど。急ではない。絶対。
服といい、これといい、どうにもサブタスクに数日取られるのはしんどいですね。しょうがないんですけど。まぁメインタスクで何を作業するのか決めて無いのが悪い。
実際のところサブタスクとして「解説を書く」が3つくらいあるんで、まぁまたそれに走ってしまう可能性はないとは言えないんですが、文章書く欲求は日記で結構発散しているのであまりそうはならないかも。
ということで、今度こそメインタスクに手をつけようと思います。少なくとも寝るときは純粋にこれについて考えられるというのは幸福です。まぁ眠いからあまり考える余裕ないけど。
がんばっていこ。どうなるかは明日考えます。
今日この動画を撮っていたらブタジエンさんがやってきてくださって、ひさびさになんかそれっぽい話をできました。
可視化というのは「わからないもののわかる側面を提示する」という部分なわけで、「これをみてわかった気になれた」のはめちゃうれしいわけです。「わかった気になる」のが正しいわけで。
ので、いいものになっていたならよかったな、と思えました。はい。
おまけ。
アレの同期について云々考えていたんですが、自明なことを含む考察をここにおいていきます。
同期させたい値というのはやっぱり複数種類あって、1つは「今までの過程」、もう1つは「最後の入力」。前者は基本的に UdonSynced をベースとし、後者は CustomEvent をベースとするのはある程度基底として正しそうです。
何故なら前者は1度でもイベントの解釈ミスがあるとそれ以降永遠に同期されないが、後者は1度のイベント発行で必ず同期するからです。これは「分散処理の怖さ」というものが念頭にあって、「イベントの解釈ミスは起きる」し「イベントが遅延することは常識的にある」という考えをベースとしています。
UdonSyncedだがイベント発行でも反映させたい場合は「1F前のUdonSynced変数の値」を保持しておいて、基本的にはローカル計算に見えるけどUdonSynced変数の値が書き換わったらそれに合わせるのがいいのかなと思います。UdonSynced変数がそのうち同期したらちゃんとそれは反映されるわけです。一時的にローカル計算の値が同期値と違うことがあるけれど、一度更新が入ればもう大丈夫です。
CustomEventベースの場合は、これはこれでUdonSynced変数を用意しておいて常にそれも同時にOwnerが記録。late-joinerはStart時にその値で初期化することで同期ができ、以降のイベントでのみ値を書き換え、ということになるかなと思います。late-joinの瞬間以外はUdonSynced変数を利用しないわけですね。
今回はこれでうまいこといきました。もう毎度こうやって同期について考えるたびにやりかたを考えるしかないんだろうなという気はちょっとだけします。
そういえば、この辺の基本的な考え方で「実験して問題がないから大丈夫」というのはわりと危険なわけですが、その危険性を認知しているのかどうか判断しかねる気持ちを持つことがあります (婉曲表現)。
まぁ、それがエンジニアリングなのかもしれませんが。単純に私の筋量が足りないだけかも。
うまくいくことが保証された世界でやっていきたいものです。
おわり。
