YoshikuniJujo

https://jp.reuters.com/opinion/forex-forum/XQRYGRTM7RI2HDCEUPU5UV4HHY-2024-09-11/
日米でけっこう感覚の違いがあるのかな。
「医療は基本的な権利」という発言が「かなり左より」ととらえられるってのは驚きだ。
日本だと当然のことで論点にならないっていう感じがあるのだけど。

2024-09-11 03:20:28

個人的な意見を言うならば、トランプ氏は「アメリカや世界の病気の原因」と言うよりは、それらの「病気の症状」と言ったほうが当たっているのかもしれない。
何と言うか、「世界をすこしずつ良くしていこう」という動きに対して、「全部破壊してしまおう」という流れだと思う。「理性」というものに対する不信感がある。

2024-09-04 02:49:49

同期とか非同期とかそのあたりの話で苦労して、コードが荒廃したという。
なんとかうまくいったので、あとはコードのおかたづけをすればいいのだけど、すこし休もうかと。
Vulkanを使うという話なのだけど、たとえばゲームパッドで回転させることのできる「時計」を考える。時計の部分はpangoとcairoを使ってイメージを書き出したうえで、それをテキスチャとしてはりつける。
イメージをvulkanのbufferにコピーしたうえでvulkanのimageにコピーするという処理を行う。この処理がイメージが大きいと0.5秒くらいかかったりする。
で、そのあいだ回転が止まるというのはユーザー体験としては良くない。それでテキスチャの内容の更新を別スレッドにしようとしたのだけど、そうすると「Queueを複数のスレッドから同時に使ってるよ」というエラーが出る。
そのエラーを解消するのにCPU側のセマフォを設定したのだけど、それだけだとうまくいかない。
GPU側に処理を依頼した段階でCPU側は次の処理にうつるので、CPU側がGPU側の処理の終了を待つ必要がある。そのために必要なのがVulkanのFenceだ。
つまり、CPU側でセマフォを用意するだけではなく、GPUをCPUが待つようにするためにFenceも設定しなくちゃならなかったという話。
そして、そこに到達するまでにコードがいろいろとぐちゃぐちゃになったということ。

2024-09-03 00:15:22

コンピュータが得意なのは数学よりもむしろ「お絵描き」だったという話。

2024-09-02 09:14:46

- reply

https://github.com/YoshikuniJujo/test_haskell/blob/986bf4db5728febe5e8b0ab954a5fca18d6a08c0/themes/gui/vulkan/try_using/try-vulkan-rectangles/src/UseCairo.hs#L1571

2024-09-02 09:09:26

Vulkanでゲームパッドからの入力で画像が回るようにしたんだけど、ときどき止まるなと思ったら、texture imageをdestroyしてcreateしている部分で時間がかかっているみたいだった。
画像のサイズは変えないので、この場合destroyしてcreateするのではなく、既存のbufferに画像をwriteする処理にする必要がある。
コードがあまりきれいではないので、わずかにめんどくさい。

2024-08-30 07:58:20

ぬるぽが画像生成 bitcoin puppet

2024-08-30 02:22:16

「物言えば唇寒し」みたいなのって、SNSやってるとよくある。

2024-08-30 02:17:37

foo = do
run1
run2
run3
みたいなとき、run1とrun2を1行で書きたいときに
foo = do
run1; run2
run3
みたいにすることもできるし
foo = do
run1 >> run2
run3
みたいにすることもできるけど、どっちのほうがきれいかな。
僕は後者を書きがちだけど。「do記法を使わないほうがスマート」みたいな感覚はどこかにある。

2024-08-30 01:53:30

RGBAで表現される色をそれぞれについて8-bitの符号無し整数であたえる場合、
Word8 -> Word8 -> Word8 -> Word8 -> RGBA
みたいに「失敗」を気にする必要はないのだけど、浮動小数点数であたえる場合には、
Double -> Double -> Double -> Double -> Maybe RGBA
みたいに「失敗」の可能性を考える必要がある。それぞれの値が0.0 - 1.0の範囲内になければならないので。
0.0から1.0までの実数を表現する型を作れば理論的にはよりきれいなのだろうけど。

2024-08-30 01:47:47

- reply

「実際はさらにもっと長かったりする」のくだりは「言いすぎ」だったかもしれない。今ちょっと見た感じだと長いので
vkGetDescriptorSetLayoutSupport
とか
VkDescriptorSetLayoutCreateInfo
なので、思ったほどは長くなかったかもしれない。32文字か。

2024-08-30 01:40:08

C言語とかだと、
fooapi_bartype_bazsubtype_hoge_piyo_run
みたいな感じの長い関数があったりする(実際はさらにもっと長かったりする)のだけど、Haskellから使うときには、FooApi.BarType.BazSubtype.Hoge.Piyoモジュールのrunとして定義するのが良さそう。そう定義しておけば、
import FooApi.BarType.BazSubtype.Hoge.Piyo qualified as Foo.Piyoみたいにして、Foo.Piyo.runで呼び出すことができるので。

2024-08-30 01:29:31

- reply

https://github.com/YoshikuniJujo/test_haskell/blob/master/themes/hetero-list/try-hetero-parameter-list/src/Data/HeteroParList/Constrained.hs
Data.HeteroParListとData.HeteroParList.Constrainedとに分けているのだけど、「空の型制約」が使えれば後者だけを定義しておけば前者は型シノニムで書ける(と思う)。

2024-08-30 01:17:42

コード書いてるなかで、「もっと抽象化できるのだろうけど、僕の頭ではここが限界」ってところもあるし、「理論的にはもっと抽象化できるのだろうけど、使っている言語の機能的にここが限界」というのもある。

2024-08-28 01:04:05

あの記事、何が問題だったかっていうと、「人の作ったもの」には人の思いがあって、それをサンドバックみたいにあつかっちゃだめってことだ。
MySQLとかって「大き」すぎて自然界にはじめから存在していたかのように見えるけど、それを作ってる人もいるということ。
たとえば三平方の定理をバカにしても傷つく人は多分いないけど、IT分野だと、そういう「自然界にもともと存在していた」かのように見える技術についても、その創始者が生きていたりするわけで。だからリスペクト大事。

2024-08-28 00:29:14

- reply

MySQL vs MariaDBの記事とか読んでみたいな

2024-08-26 04:44:43

https://nishikiout.net/entry/2024/04/08/060000
RISC-Vを命令セットとするGPUを作るみたいな話なのかな。

2024-08-23 08:42:37

回転行列を「左からかける」か「右からかける」かによって、回転軸が「世界上の軸」か「物体上の軸」かが決まるという話。
おもしろい。

2024-08-23 02:02:31

- reply

とりあえず無限小回転についてはよくわからないけど、glmのrotateを使って、保存してある回転行列を変換していくというやりかたをすれば目的は果たせるかな。アナログスティックをたおした向きと直交するような軸に対して回転させるようにすればいいわけなので。

2024-08-23 01:47:15

3次元での回転の話、ロール、ピッチ、ヨーの話がまあまあわかりやすいかな。

2024-08-23 01:41:48

- reply

無限小回転/無限小時間を積分するみたいな形で、実際の回転を求める感じなのかな。よくわからない。

2024-08-23 01:37:01

ゲームパッドのアナログスティックの入力によって3Dの物を回転させるのに、横回転と縦回転とを別々に保存して、「横回転させてから縦回転させる」みたいにすると、直観的な動きにならない。
横回転は「世界座標上の軸」で回転するのだけど、縦回転は「その物体上の軸」で回転するみたいな感じになってしまう。
たぶん、「ちょっと横回転」「ちょっと縦回転」「ちょっと横回転」「ちょっと縦回転」みたいにすればいいのだと思うのだけど、ここに無限小回転の考えかたが使えるのかもしれない。

2024-08-23 01:16:43

直交行列っていうものがあるのか。転置行列が逆行列になるようなものらしい。回転行列は全て直交行列らしい。

2024-08-23 01:07:27

- reply

https://hooktail.sub.jp/mechanics/infinitesimalRot1/
これだ。「無限小回転」って言うのか。

2024-08-23 01:06:03

いろんな軸に対する回転は可換ではないのだけど、回転を細かく分けて混ぜ合わせるようにすると可換になるっていう話、わりと好き。

2024-08-22 05:26:52

やまさきたかひろさんもいなくなったの?

2024-08-21 02:52:50

ITって言葉の意味、実のところよくわかってない。昔はInTernetを略してITだと思ってた時期ある。

2024-08-21 02:47:49

もちょぴさん、いなくなってしまったらしい

2024-08-21 02:45:02

- reply

プログラミングに適性のある人には、JavaScriptよりもHaskell渡すほうがいいように思う。
まずはHaskell 98の時代の牧歌的なHaskellがいいんじゃないかな。

2024-08-21 02:39:22

プログラミングに適性のある人が、クライアントサイドやって、プログラミングが嫌いになるってのはありそうな気がする。クライアントサイドってのは「あまりに人間的」すぎるところある。
考古学者とかなら好きになりそうな分野かも。

2024-08-20 15:39:08

- reply

マルチメディアカードってのもあったらしい。
これがSDカードの直接の先祖のようだ

2024-08-20 12:21:39

スマートメディア、コンパクトフラッシュ、メモリースティック、xDカード、SDカード
みたいに乱立してたけど、SDカードが全部持ってった

2024-08-20 08:41:44

USBメモリって正確にはUSBフラッシュドライブって名前らしい。たしかに、USBメモリだと、PCの主記憶領域の「メモリ」との性質が大きく異なるものへの命名としてはふさわしくないかもしれない。

2024-08-20 08:31:18

心に何もひっかかりがないときなんて、あんまりないので、何をするかと言えば、足をひきずりながらでも歩くということを学ぶことだ。
目の前がぱっと開けるときもあるけど、たいていは視界は曇っているものだ。

2024-08-20 07:59:09

https://amzn.asia/d/8zunODJ
最近はUSB-AとType-Cの両方の端子があるUSBメモリがあるようだ。PCとスマホの間での情報共有に役立ちそう。
Bluetoothとか使うほうがスマートなのだろうけど、USBメモリのほうが、たぶんかんたんかと。

2024-08-20 03:42:51

ぬるぽが画像生成 battle between Haskell programmer and JavaScript programmer

2024-08-20 03:40:16

PCはそのへんの家電量販店で買うことが多いのだけど、SSDが500GBのものばかりで辛い。1TBはないとつらいのだけど、あまり売ってない。
あとメーカーは以前はNECをよく使ってたのだけど、今はFUJITSU。
USBポートが多くあったりして「わかってる」感じがあるので。

2024-08-19 02:26:44

https://news.mynavi.jp/techplus/article/20240730-2995773/
キヤノンのナノインプリント・リソグラフィに期待してたんだけど、こっちのほうが可能性はありそうかも

2024-08-16 16:01:33

ぬるぽが画像生成 Lisp Olympic

2024-08-16 03:22:13

ぬるぽが画像生成 Haskell Olympic

2024-08-16 00:07:37

「クリティカル」って言うのかな、宇宙、軍事、医療、金融の分野のプログラミングはほかの分野とはすこし違うように思う。
ミッションクリティカルとかセーフティクリティカルとか。

2024-08-15 06:56:54

- reply

https://qiita.com/YoshikuniJujo/items/e9639712a49ac0af2a9a

2024-08-15 06:55:16

とりあえず、実時間キューは熱い

2024-08-13 08:34:32

- reply

あとtop-left, bottom-rightだからtlとbrにしたほうがいい気もするけど、座標の表現を(x, y)みたいにすることを考えると、lt, rbにしたほうがいいような気もする。

2024-08-13 08:28:15

r!next

2024-08-13 08:27:10

上下左右をupper lower left rightとするよりも、top bottom left rightとしたほうが一文字にしたときに、t, b, l, rみたいになるので良さそう。

2024-08-13 06:29:39

https://github.com/YoshikuniJujo/test_haskell/blob/master/themes/gui/vulkan/try_using/try-vulkan-compute/src/TryBitonicsortGpu.hs
バイトニックソートをHaskellでVulkanを使ってGPUにやらせるコード。
400行くらい。VulkanのコードはGPUに働いてもらうために、いろいろと申請用の書類を書く感じで、行数が多くなってしまう。
末尾のGLSLのコードをp, qを設定したうえで、iを0から要素数まで変化させて実行するみたいなのを、必要なp, qの組に対して行っている。
速度はメモリのコピーなども含めると、クイックソートよりすこし遅いくらい。

2024-08-11 09:45:07

- reply

「もし自分の帽子の色が青だったら、ほかの人たちにとってはn-1の場合の同様の問題になる」というのがこの問題のポイントというわけか。

2024-08-11 08:24:13

三人の賢者と帽子の話、4人以上でも成立するのかどうか、僕にはよくわからない。

2024-08-10 10:56:29

- reply

https://qiita.com/YoshikuniJujo/items/e9639712a49ac0af2a9a
昔書いた記事の一部に銀行家キューの説明があった

2024-08-10 10:46:14

- reply

すくなくとも銀行家の方はちがったようだ。
むしろ、「積み立て」ではなく借金にすることで、償却時間を保証する感じのようだ。

2024-08-10 10:28:03

- reply

よくわかってないけど、銀行家法は計算量がすくない処理のときにつみたてておいたぶんを、計算量の多い処理のときに使うって感じなのかな。
そして、物理学者法ってのは、データ構造の中にたまる「処理の重くなる構造」の総和が一定以上にはならないみたいな感じかな。

2024-08-09 05:13:18

https://www.peyoung.co.jp/products/000005.html
ペヨングは安い。100円くらい。

2024-08-09 05:11:52

ならし計算量の話で、銀行家法と物理学者法とがあるらしいのだけど、よく知らないので、どうちがうのかもわからない。

2024-08-09 04:36:36

- reply

https://github.com/YoshikuniJujo/test_haskell/blob/master/algorithms/try-algorithms-for-sns/src/Algorithms/Dijkstra/Heap.hs
ふたつめはこれ。
ヒープ関連のコードを外に出したのもあって、かなりシンプルに書けた。
これはちゃんと関数プログラミングできてる。
ヒープはAlgorightms.Heap.Skewで定義してある。
https://github.com/YoshikuniJujo/test_haskell/blob/master/algorithms/try-algorithms-for-sns/src/Algorithms/Heap/Skew.hs

2024-08-09 04:33:05

- reply

https://github.com/YoshikuniJujo/test_haskell/blob/master/algorithms/try-algorithms-for-sns/src/Algorithms/Dijkstra/Orig.hs
ひとつめはこれ。暫定的な距離を保存する構造をリストではなく配列にした。配列の要素の置換が必要なので、STモナドを使ってimperativeに書いた。

2024-08-09 03:19:30

- reply

とりあえずskew heapを実装してみようかな。理論は難しそうだけど実装はまあまあ簡単そうなので。

2024-08-09 03:10:30

- reply

http://www.nct9.ne.jp/m_hiroi/func/haskell23.html
leftist heapとかskew heapとかがあるらしい。

2024-08-09 02:57:26

- reply

ヒープって概念的には「木」なのだけど、「配列」として実装したほうがシンプルで効率的になるという、なんか不思議な性質があるな。

2024-08-09 02:49:38

- reply

バランスを取るように作ったり削ったりするのがそもそもヒープの特徴ってことか。配列を使ったヒープは実装したことあるけど、木を使ったヒープはちゃんと書いたことないかもしれない。

2024-08-09 02:45:38

そういえば、ヒープの木としてのバランスってどう取るんだったかな。

2024-08-08 09:23:56

- reply

あ、この実装だとだめかもしれない。キューにごみがたまっていって、dequeueの効率がO(n ^ 2)とかになりそう。キュー(実際にはキューではないけど)を配列で実装しないとだめかも知れない。

2024-08-08 08:47:52

実用上、O(log n)はO(1)とほとんど変わらないと考えていいように思う。実用上は。

2024-08-08 08:45:45

- reply

オリジナルからヒープを使ったものに変更する場合には、グラフの表現を配列の配列ではなく、リストの配列にして、enqueue, dequeueをヒープを使ったものにすればいい。

2024-08-08 08:36:34

ダイクストラ法はオリジナルのものとヒープを使ったものとがあって、グラフが疎な場合には後者のほうが速い。
グラフが密になってくると、前者がO(n ^ 2)なのに対して後者がO(n ^ 2 log n)みたいに計算量が増える。
けど、実用的な見地からは、だいたいのグラフは疎な気がするし、さらに密な場合でもn ^ 2にlog nをかけたからって、焼け石に水というか、象に蟻を乗っけるみたいな話なので、たぶんヒープを使うもののほうが、実用的にはベターなのだろう。

2024-08-08 08:28:26

- reply

これ、一度queueをソートされたリストにしておけば楽みたいに思って、enqueueのほうを単純挿入ソートみたいにしてみたのだけど、それだと全体の計算量がO(n ^ 3)になりそうな気がしたので、dequeueのほうで最小を計算するような実装に変えた。
queueをきれいに並べておいたほうが効率が良さそうな感じもするのだけど、dequeueはO(n)回実行されるのに対してenqueueはO(n ^ 2)回実行されるので。

2024-08-08 08:16:30

HaskellでDijkstra法を実装してみた。
本質的な部分はsolve, update, enqueue, dequeueの4つの関数。dequeueは距離が最小のものと、それ以外とを分ける関数。updateはノードxの距離wが決まったときに走る関数で、queueにx経由でyにいく場合の距離を追加している。solveはdequeueで一番距離の近いノードとその距離を取り出し、それが決定ずみなら無視し、それがゴールならその距離を返し、どちらでもないなら、そのノードを決定ずみにして、全てのノードに対してupdate処理を走らせている。
https://github.com/YoshikuniJujo/test_haskell/blob/master/algorithms/try-algorithms-for-sns/src/Algorithms/Dijkstra.hs

2024-08-08 06:20:09

- reply

Array Node (Array Node Word)みたいにしているところをArray Node (Array Node (Maybe Word))みたいにして書き直すかな。

2024-08-08 06:18:20

ダイクストラ法で、つながっていないノードについて距離maxBoundって感じで非負整数の最大値を入れておいたんだけど、maxBound + 1 = 0で、だめだこりゃという感じになった。
Maybe Wordとかにすればいいのだけど、低レベルの効率とかを考えると単なるWordでできたほうがいいのかな、とか。整数値にも正負の無限大が定義されていれば便利なのかもしれないけど、結局はそれはそれでCPUの演算が複雑になり効率が下がるだろうから意味ないのかもしれない。

2024-08-07 08:11:45

- reply

バケットソートのズルさと似てる気がする。

2024-08-07 08:11:14

ハッシュ法の計算量がO(1)っての(確かに実用的にはそうだけど)ちょっとズルしてる感じある。

2024-08-07 08:04:28

みんな計算量を気にしてない

2024-08-07 08:03:17

ぬるぽがって「みんな...してる」->「...してないのお前だけ」
だけかと思ってたけど、
「みんな...してない」->「...してるのお前だけ」
のバージョンもありなんだ。

2024-08-07 07:58:12

- reply

https://nw.tsuda.ac.jp/lec/dijkstra/
これもわかりやすい。
まあ、疎な場合に限ってO(n log n)になるということなので、本質的にはO(n ^ 2)と考えていいのかもしれない。

2024-08-07 07:46:48

- reply

https://zenn.dev/iharuoru/articles/a670e91c6171d8
これの動作例がわかりやすいな。

2024-08-07 07:33:45

- reply

https://qiita.com/george1998/items/3eedf21a039a50aa341d
ヒープを使わないオリジナルの実装の場合、頂点の数Vに対してO(V ^ 2)なので、まあ正解か。
ヒープを使う場合は辺の数がそれほど多くないときにはO(V log V)程度になる感じかな。

2024-08-07 07:26:01

https://x.com/tome_ura/status/1448123878639874048
クイックソートの計算量の話だけど、これが話題になったのが3年前か。
「計算量まで知っている必要があるか」みたいな話が話題になったけど、どうなんだろう。僕はソートアルゴリズムが好きだから知ってるけど。でもたとえばダイクストラ法の計算量を聞かれたらわからないし。
あ、でもダイクストラ法のイメージは「ひもでつながった複数の石のなかのひとつをゆっくり持ち上げていき、ピンとはった経路が最短」みたいな説明を読んだことがある。
とすると、「n個のうちから1個選ぶ処理をn回くりかえす」のと同じオーダーになるからO(n^2)になるのかな。
あとで、正解を見てみよう。

2024-08-07 05:49:27

- reply

https://zenn.dev/yoshikuni_jujo/articles/sort-algorithms#o(n-log-n)%E3%81%AE%E3%82%BD%E3%83%BC%E3%83%88%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0
https://image.nostr.build/b05b20dbb406ad7a606a333800b87b6286623de93253d48229b28cb65784823b.jpg
僕の環境でのHaskellで実装した、クイック、マージ、ヒープの速度の比較

2024-08-07 05:42:57

本当のことを言うと、クイックソートって実は好きじゃない。けど、平均実行効率で言うと群を抜いているし、O(n^2)になるようなデータに当たる確率は低いしで、無視できない存在だし、とりあえず実用的にはクイックソートを使っておけばいいという側面もある。
アルゴリズムのきれいさで言うとヒープソートが好きなんだけど、近年主流のハードウェアとの相性が悪い。
確実にそうかどうかはわからないけど、おそらくメモリの幅広い範囲に短期間でアクセスするので、キャッシュミス率が高くなるんじゃないかな。
マージソートは好きでも嫌いでもない。

2024-08-07 05:26:56

- reply

たしかにパズル的な側面もあるし、一番楽しい部分はそこだと思うのですが、もうすこし泥くさい部分で、実行効率とコードの簡潔さとか、ユーザにとっての使いやすさとかでバランスをとったり、とりあえずダーティーなハックですませようみたいな妥協とか、そういうあたりの雑然とした部分が「スポーツっぽい」かな、と。
最善をつくすけど完全な解答が得られるとは限らないあたりとか。
思いついきレベルなので、うまく説明できない感じですが。

2024-08-07 05:17:43

プログラミングが何に近いかって話だけど、製造業でも事務作業でもない。アカデミックな研究に近い感じもあるけど、すこしちがう。で、今日思ったのは「スポーツ」に一番近いんじゃないか、と。

2024-08-07 05:06:15

なんだかんだで総合力で言うとLALR(1)文法対応のパーサジェネレータを越えるパーサ生成系はなさそう。

2024-08-07 05:02:50

集中力がないときはNostrがはかどる。

2024-08-07 05:01:34

Nostrがだめになったら、僕はBlueskyに帰るかな。Twitter(現X)はなんか治安が悪くなっているように見える。
Threadsも治安悪そう。
ただ、Nostrの仕組みみたいなものは、普遍性があるので、第2第3のNostrが現われるだろうな。

2024-08-07 04:56:56

- reply

プログラミングはスポーツに近いように思う。

2024-08-07 04:56:07

プログラマは、スポーツ選手みたいにあつかうのがいいのでは、と。

2024-08-07 04:53:26

僕は基本メンタル弱いな。でも、じりじりとメンタルを回復させる技を持ってるって感じかな。
RPGでそんな感じの技あった気がする。ターン毎にHPが小さく回復していくやつ。
生き物としての分類だと、貝とかそういう類の生き物だと思う。

2024-08-07 03:28:04

みんな昇降デスクの話ししてる

2024-08-07 03:21:05

https://news.ycombinator.com/item?id=41157383
FirefoxのWebGPUへの対応、数ヶ月後には正式版が出るみたいな話かな。

2024-08-07 03:12:37

バイトニックソートの並列化されていない版をC言語で実装してみた。20行くらいで書ける。
変数nは要素数が2^nということ。
swap関数は配列内の2箇所を比較して大小関係によって入れ換える処理。
入れ換えるペアは比較の結果に左右されないので、ビット計算だけで決められる。
たとえば0110110みたいなiに対して、
x = 01101_0_10
y = 01101_1_10
のように0または1を特定のビット位置に割り込ませるような形で入れ換えのペアを作っている。
https://github.com/YoshikuniJujo/test_haskell/blob/master/themes/gui/vulkan/try_using/try-vulkan-compute/csrc/bitonicsort.c

2024-08-07 02:54:03

「嫌なこと」ってのは、ある。
それはある。
でもそれは人間に寿命があるようなもので、寿命による死に対して、人間は死の直前にだけ考えればいい。
それと同じで「避けられない嫌なこと」については、人間はその直前にだけ向き合えばいい。
「避けられる」か「避けられない」かの仕分けの難しさという問題もあるけど。

2024-08-07 02:21:27

クイックソートはquicksortだけど、バイトニックソートはbitonic sortなのって、思うに2つの理由があるように思う。
ひとつはクイックソートかよく知られているので、ひとつの固有名詞になったという点。それと、もうひとつ、たぶんそれもあると思うのだけど、より一般的な意味でのquickなsortと区別するという意味もあるように思う。
クイックソートよりクイックなソートが出てきてもクイックソートはクイックソートなわけで。

2024-08-07 02:13:45

人間の作る社会とかお金について、その本質について知りたいと思っている。

2024-08-07 02:10:34

クイックソートのCでの実装。わりときれいに書けたと思う。
TAOCPのアルゴリズムをなぞっている。
https://github.com/YoshikuniJujo/test_haskell/blob/master/themes/gui/vulkan/try_using/try-vulkan-compute/csrc/quicksort.c

2024-08-07 02:02:44

- reply

もしかすると、GHCによる最適化というよりは、もっとハード側の話なのかもしれない。
たとえば、複数回読まれる可能性のあるメモリ領域について、よりコアに近い記憶領域にキャッシュを置くみたいなやつ。

2024-08-07 01:27:04

一時期「忘れられる権利」みたいなのがあった気がするけど、今はどうなってるのかな。

2024-08-07 01:25:52

入力と出力、読み込みと書き出しだと、たいてい入力 - 読み込みのほうが先に表記されるものとその逆とがある。前者だと
in - out
read - write
load - store
peek - poke
逆のものとしては
set - get
put - get
push - pop