deflateによって圧縮されたファイルには3種類のブロックがあって、無圧縮ブロック、固定ハフマンブロック、動的ハフマンブロックとあるのだけど、「無圧縮」があることでデーコーダーの設計に迷いが生じる。

デコーダーはヘッダの読み込み後に、3bit読むことでブロックの種類がわかるわけだけど、3種のブロックのうち無圧縮ブロックだけはビット単位ではなくバイト単位でデータをあつかったほうが効率がいい。

でも、はじめの3bitの読み込みの部分と他の2種のブロックではビット単位での読み込みのほうがいい。

無圧縮ブロックであっても別に問題になるほどの速度差は出なそうなので、ビット単位に分割してから、またバイトにまとめるというやりかたをしても、まあいいのかもしれない。けど、なんか美しくないんだよな。

https://www.w3.org/TR/png-3/#11IDAT

Some images have unused trailing bytes at the end of the final IDAT chunk. This could happen when an entire buffer is stored rather than just the portion of the buffer which is used. This is undesirable. Preferably, an encoder would not include these unused bytes. If it must, setting the bytes to zero will prevent accidental data sharing. A decoder should ignore these trailing bytes.

IDATチャンク内に画像データの後ろに余計なバイト列が続く場合があって、それはencoderとしては望ましい動作ではないけど、decoderはもしあったならそれを無視する必要がある。

これも、encoderが頭から順に画像を圧縮していくことを想定した規格なのだろう。

たとえば、画像データを圧縮しつつ、並行して送信するような場合。

https://www.w3.org/TR/PNG-Chunks.html

PNG画像でIDATを複数に分けることができる理由がよくわからなかったけど、今わかった。

PNGのチャンクは先にデータの長さを記録する必要があるので、(前から順にファイルを書いていく場合)もし分割を許さない場合、エンコーダが用意するメモリの量が定まらないということだ。

もちろん、最後まで読んだ後でデータの長さのところだけ書き換えるというやりかたもできるけど、チャンクのまとまりごとに出力していくほうが便利なケースもあるだろう。

人間がデマを見破る手段として、信用できる人やメディアは何かという重みづけがあると思う。

それをAIにやらせるには、AIに社会性や人格を与える必要があるのかもしれない。

前も書いたけど、AIに体が必要という話。とりあえず、重力を無視したようなデマがデマであると理解できるようになる。

同じ文脈でAIにはコンパイラを渡したほうがいい。

r!next

りとりん

r!next

とりあえず更自由拡張可能作用のうえに構築した導管上でgzipファイルを展開するコードは書けた。

更自由拡張可能作用: freer extensible effects

導管: conduit

今、メインでやってるプロジェクトが2つある。2つあるとかなり効率が落ちる。

塩とか醤油とか使わずに出汁の味だけで食べるラーメンみたいなの誰か作らないかな。

「CやC++で苦しんだ者にしかRustのありがたみはわからない」という言葉を格言にしたい。

プログラムだとwaitよりawaitを使う感じあるけど、何でかな。waitよりも「特定の何か」を持つみたいな、感じの語感が他動詞のawaitのほうにより強いとかなのかな。

僕は、ひとつ「何でもいれる巨大リポジトリ」があって、ある程度公開できるくらい形になったコードについて独立したリポジトリにするような感じでやってるけど、みんなはどうなんだろう。

前はdoWhile_とか、そういう関数を定義して使ってたけど、最近は

fix \go -> foobar >>= bool (pure ()) go

とかで書いちゃってる。fixは便利だ。

nostr:note1gvlcz2femul7qh5y3tqy762ked00npqxvewwfdaucy87hagarlpskr8gts

これ、たぶん適当なこと言ってる。

のすたろう、H3ロケットの6号機はどうなったの?

大丈夫、自信を持って。

そうか。どうもありがとう。