Steam：Rock Life: The Rock Simulator
https://store.steampowered.com/app/2056560/Rock_Life_The_Rock_Simulator/
> Built from the ground up,
もう説明文すら洒落に見えてくるな
らりお・ザ・何らかの🈗然㊌ソムリエ(@lo48576@mastodon.cardina1.red)の投稿
Steam：Rock Life: The Rock Simulator
https://store.steampowered.com/app/2056560/Rock_Life_The_Rock_Simulator/
> Built from the ground up,
もう説明文すら洒落に見えてくるな
このアカウントは、notestockで公開設定になっていません。
struct Foo<T, const X: usize, const Y: usize>([T; X * Y]);
みたいな型作れないのややしんどいな
MVP (Minimum Viable Product) じゃない方の const generics なぁ
[[T; X]; Y] を持って誤魔化しといて、 unsafe な pointer cast か transmute でどうにかする手はあるやもしれん
しかしなんですでに一旦やりとりしてるはずなのに「DMで相談」なんだろう（いや文字通りの意味ではないのかもしれんが）
これが事実なら勘違いした方も赤っ恥で可哀想だし誤解された方も真っ当なアクションでこんなことになって可哀想だな
このアカウントは、notestockで公開設定になっていません。
私も最近 URL の正規化 ( /foo/bar/.././baz/./../qux みたいなのを /foo/qux にするようなの) をメモリアロケーションなしで書いたときは自分で神だなと思った
メモリアロケーションなしで、長さに制限なく、先頭から結果を出せる方法で書けたので、安心して core::fmt::Display を実装できた
やっぱり文字列化は Display 経由にしたいし、動的メモリアロケーション不要だと気持ちええんじゃ
やってることは単純なんだけど、「固定長 queue に上位セグメントから range を詰めていって、吐き出したら先頭をトリムして残りを処理」の繰り返し
走査中に queue に入らないくらい深いセグメントに突入しても深さカウントだけ続けて浅いところに戻ってこられたら、次スキップできる長さもデカくなるし確定で先祖側セグメントを吐けるよね？ というのが発見だった
べつにそれはそうという感じなので、天才！ とはならなかったが、顧客の欲しいもの！ とはなった
まあ queue の長さより深い階層のパスだったら再走査が走るので、線形オーダーの処理ではなくなったけど。案外8階層より深いパスってそんなにないし、平均計算量は (ちゃんと計算してないけど) だいたい線形の対数倍くらいになりそうなので、十分許容範囲
実は最適化の余地があるけどスルーしている (というか今書いていて思い付いた)
たとえば queue size が 2 のとき
/foo/bar/baz/qux/../../../../a/b/c
みたいなのがあったら、最初の走査で /a/b まで見ないといけないので、走査自体では文字列全部を見ないといけなくて一見非効率なんだけど、この場合次の走査では /c しか残っていない。つまり意地悪なパスだとその分読み飛ばしが多いので、実は割と楽できる
むしろ /a/b/c/d/e/f/g/h みたいなパスの方が、最初8セグメント読んで、次は /c/d/... から6セグメント、次に4セグメント、みたいな感じで一番効率が悪くなるんだけど、結局それは queue size をデカくすると吸収して 1 pass で済まされるので、内部キューをデカくすればするだけ効率が上がる
結局 8, 12, 16 でどうするか悩んだんだけど、8にしたんだよな。
queue: [Option<&str>; QUEUE_SIZE] なので、amd64 では深さ1あたり16バイトなんだけど、まあ128バイト (ポインタ16個) くらいならスタックに載せても責められることはなかろうと。
そんで深さ8以上のパスってのも案外少ない (ないことはないが)
どうせ深さ9以上でも16以下なら2パスになって残り半分 (期待値) が再走査されるだけだからコストは精々1.5倍だし、まあ許容範囲やろと。
実は案外越えるようだったら12とか16くらいに増やせばいいし、チューニングがお手軽なのも楽で良い
しかも毎回ケツまで読むので no dots なのがわかるから全部書いて終わりでええやんということやね
そういうこと。
書いてるときは「思ったよりコストかからんなwww」つって調子乗ってたから全然気付かなかったけど。
あとは悪意ある人工的な入力を考えすぎていて素朴な入力の高速化に気が向いていなかったというのもある ()
https://mastodon.cardina1.red/@lo48576/108709381194032523
期待される平均計算量、バッファサイズ無制限の場合に比べてたかだか2倍だな。
Σ_{i=0}{n/QUEUE_SIZE} len/{2^{i}} なので。
N log N にさえならないとは、思ったよりいい感じだった
このアカウントは、notestockで公開設定になっていません。
やっぱり Intel + nvidia か amd + amd が安牌か……
9月になったら今使ってるﾃﾞｽｸﾄｯﾋﾟ (Ryzen 3800X + RTX 3090) がｲﾝﾄﾞｯｽﾞ機になる予定だが、不安が出てきたな (まあ今更考えてももう遅い)
#MyNextGpuWontBeNvidia ！ 今度こそ！！
フィクションにおける『夏祭り』の描写は概ね“夜店”と“花火”に尽きている事に気づいて面白くなった「盆踊りもいつしか見なくなった」 - Togetter
https://togetter.com/li/1920628
ご老人の皆様方は「物語に必要ないから」とか「邪魔だから」みたいなこと仰るが、普通に「んなもん縁がなかった」に尽きる
子供時代はそこそこ田舎に住んでいたが、それでも祭りで夜店と花火以外の要素には縁がなかった。
山車か神輿か盆踊りも開催されていたのかもしれないが、子供が皆参加するわけでもないのでマジで関係ないのである
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
雑に cherry-pick してから rebase -i で pick を reword なり edit なりにしてやれば、必要なものだけ必要な範囲を弄れる
/dev/neru
#今すぐ寝ることで救える命があります
選択肢があることは苦労を生むが、選択肢がないことは苦痛を生む
AT はエンジンブレーキかからなすぎて停車や減速が気持ち悪い (ってこれ前にも言ったな)
回生ブレーキ未経験マンなんだよな、教習所でハイブリッドとか EV みたいなのも経験しなかったし
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
このアカウントは、notestockで公開設定になっていません。
