[obsidian] vault backup: 2025-08-01 13:05:00[

content/Entity Component System.md

@@ -0,0 +1,23 @@
+#programming 
+
+
+主にゲームエンジンなどで採用されるプログラミングのパラダイム。
+
+最近のUnityでも内部的に採用されている。
+
+[[Rust]]だと[[Bevy]]が有名。
+
+[[オブジェクト指向]]と比べると、データのメモリ分布が、オブジェクトごとに並ぶのではなく個別のメンバー変数ごとに並ぶことになり、CPUのメモリキャッシュに乗りやすいなどの利点がある。
+
+[\[Rust\] ECSアーキテクチャ \[bevy\_ecs\] | DevelopersIO](https://dev.classmethod.jp/articles/ecs-rust-bevy/)
+
+[Intro to ECS - Unofficial Bevy Cheat Book](https://bevy-cheatbook.github.io/programming/ecs-intro.html)
+
+## データのモデリング方法としてなにがうれしいのか
+
+オブジェクト指向と比べた時の利点が基本的にさっきのような、パフォーマンス面での利点が強調されることが多い。ただ、何かパフォーマンスのためにせっかくプログラミング言語が用意してくれたデータのモデリング技法を犠牲にしているような気がしてならず、あんまり旨味がよくわからなかった。
+
+ただ、Bevyの設計をいろいろ読んでいると、モデリングとしての核心は、「集合の中から特定の要素を持つもの部分集合を指定して挙動を個別に操作する（依存性がない操作同士はどういう順番で実行してもいい）」ということかなと思った。
+
+
+

content/Gluon.md

@@ -0,0 +1,7 @@
+#programming-language 
+
+[[Rust]]で書かれた、[[Lua]]のような埋め込みを想定しつつ静的型付けの言語。
+
+モジュールの読み込みの文法とか複雑な型情報をRustと相互でやり取りする時のやりかたとか、参考になる
+
+[Gluon](https://gluon-lang.org/)

content/Hackett.md

@@ -0,0 +1,9 @@
+#programming-language 
+
+[[Racket]]上で実装された、静的型付けなうえで、型安全なマクロシステムを搭載したプログラミング言語
+
+[1 The Hackett Guide](https://lexi-lambda.github.io/hackett/guide.html)
+
+["Hackett: a metaprogrammable Haskell" by Alexis King - YouTube](https://www.youtube.com/watch?v=5QQdI3P7MdY)
+
+

content/Olia Lialina.md

@@ -4,3 +4,9 @@ date: 2024-10-04 13:31
 #person 
 
 [[Not Art&Tech - On the role of Media Theory at Universities of Applied Art, Technology and Art and Technology.]]
+
+---
+
+[Turing Complete User](https://contemporary-home-computing.org/turing-complete-user/)
+
+[[橋本麦]]さんによる試訳 [『チューリング完全ユーザー』試訳 - baku](https://scrapbox.io/glisp/%E3%80%8E%E3%83%81%E3%83%A5%E3%83%BC%E3%83%AA%E3%83%B3%E3%82%B0%E5%AE%8C%E5%85%A8%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%80%8F%E8%A9%A6%E8%A8%B3)

content/Red Green Syntax Tree.md

@@ -0,0 +1,13 @@
+#compiler-design 
+
+[Red-Green Trees: an Overview. Six months ago I dug into Roslyn’s… | by Bayastan | Jun, 2025 | Medium](https://medium.com/@krendelia2021/red-green-trees-an-overview-17bae2d84e8c)
+
+[[抽象構文木]]というか[[具象構文木]]の実装方法の一つ。
+
+構文の途中で差し込まれたコメントなどのトリビアなどを保持して、完全なソースコードに戻せるけど実行効率などをよくしたままにできるやり方。
+
+部分的に構文木を書き換えたりするとソースコードのロケーション情報がずれたりするので、文字幅とオフセットを別々に持たせるというやり方をしている
+
+ながいけどこれがわかりやすい
+
+[Ruby Parser開発日誌 (19) - 最高の構文木の設計 2024年版 - かねこにっき](https://yui-knk.hatenablog.com/entry/2024/08/23/113543)

content/Rune.md

@@ -0,0 +1,9 @@
+#programming-language 
+
+[The Rune Programming Language](https://rune-rs.github.io/)
+
+[[Rust]]で書かれた埋め込みプログラミング言語。
+
+Rustの文法ほぼそのままに動的型付けの言語をつくるとこうなる、みたいな感じ
+
+[[Moonbit]]とか[[Rhai]]も近い感じ（Rhaiは直接影響を受けたとのこと）

content/mimium.md

@@ -30,7 +30,12 @@ https://github.com/mimium-org/mimium-rs
 - [[mimiumのMIRコンパイル過程を真面目に考える]]
 - [[lambda-mmm(実用版)]]
 - [[mimiumグローバル環境評価について]]
-- [[多段階計算を命令型VMインストラクションで表現したい]]
+
+
+## マクロ
+
+- [[mimiumと多段階計算]]
+	
 
 ### ランタイム周りについて
 
@@ -46,6 +51,13 @@ https://github.com/mimium-org/mimium-rs
 
 ふと思ったけど、[[SuperCollider]]や[[PureData]]と比べると、これらの言語は組み込みに使おうと思うとLinuxが動く環境を想定することになる（[[Heavy]]はそれを全く別の処理系作ることで対応してたけど）。シーケンサとかスケジューラーがあるような、[[Faust]]だと難しいタイプのプログラムを[[Arduino]]とかに持っていくには向いているのではないか([[Extempore]]だって仕組み的に言えばそうかもしれないけど)
 
+- できれば教育用途とかに持ち込めるのが一番いい
+- ブートストラップできるといい
+	- いろいろな人がmimiumで拡張やライブラリを書けるようになってからが本当の本番
+	- 言語自体の拡張機能をその言語上でたくさん作れるとよい
+	- しかし、極端に自由度が高いとそれはそれで参入障壁が高い
+
+
 [[mimiumでのシーケンサ]]
 
 [[mimiumでのライブコーディングエンジン]]

content/mimiumでのバリアント.md

@@ -7,4 +7,32 @@ date: 2025-07-03 18:34
 
 二重インクルードの問題とかもあるので、先に分割コンパイルの仕組みを整える方がいい？
 
+型の環境の中に変数解決が必要になってくる
+
+内部的には幽霊、Opaque、バリアントで分かれててもいいかもな
+
+```rust
+enum Variant{
+	Phantom(Symbol),
+	Opaque(Symbol,TypeNodeId),
+	Union(Box<Self>,Box<Self>)
+}
+enum Type{
+	...
+	
+	Variant(Variant)
+}
+```
+
+Foldでネストするくらいなら`Vec<Box<Self>>`に収められるかな？
+
+パーサーとASTとしてはmatch節も加えないと意味ない
+
+で、型推論に加えなきゃいけないコードは、
+
+- 型コンストラクタを関数として使えるように型→値環境に追加し、App式の評価で使えるように
+- match式の型推論
+
+matchのコード生成がジャンプテーブルとか出てくるとめんどくさいんだよなあ
+
 

content/mimiumでのライブコーディングエンジン.md

@@ -19,3 +19,6 @@ ChucKではエフェクトのテールが更新時にぶちぎれる問題があ
 
 各トラックごとのエフェクトのライブ切り替えとかも実現しようと思えばできるかな
 
+...これ、結局[[SuperCollider]]のJITLibと同じことかもな
+
+[jitlib\_basic\_concepts\_01 \| SuperCollider 3.14.0-dev Help](https://doc.sccode.org/Tutorials/JITLib/jitlib_basic_concepts_01.html)

content/mimiumと多段階計算.md

@@ -0,0 +1,71 @@
+#memo #mimium 
+
+
+
+- [[多段階計算を命令型VMインストラクションで表現したい]]
+	- 一時期考えていたが、あんまり筋が良くないのでやめた
+
+
+[Implement multi-stage computation intepreter by tomoyanonymous · Pull Request #136 · mimium-org/mimium-rs · GitHub](https://github.com/mimium-org/mimium-rs/pull/136)
+
+シンプルに構文木レベルでのインタプリタを別途作ることで実現できそう。
+
+
+## 課題
+
+- 組み込みの関数の型情報がマクロ用（レベル0）とVM用（レベル1）で分かれているので、両方にあることを別々に宣言しなければならない
+	- 逆に、ベクターのappend・removeや文字列操作など、メモリを確保する操作はレベル0でのみ利用できる組み込み関数として制限すると、便利かもしれない
+	- 逆に、`self`や`delay`はレベル1でのみ利用できる関数とする
+	- レベル0，1両方で利用できるpersistentなモジュールは、上記2種類のいずれも使わず、かつescapeとBracketも利用しないものであればよい、ということになる
+- もともとディレイの最大サイズはリテラルで指定しなければいけないという問題があったが、これを`make_delay(size:float)-> <(float,float)->float>`（レベル0で最大時間を指定すると、入力と遅延時間をとる関数のコードを返すという関数）にできるかも
+	- ただ、これやるとディレイが絡む関数はすべてレベル0定義になるのかな
+	- なんかそれよりは、[[数値プリミティブ型に常に範囲をつける]]とかのほうが筋がいいかも
+
+```rust
+fn fbdelay(max_time){
+  `|input,time,fb| {
+    (input + self*fb, time) |> make_delay!(max_time)
+   }
+}
+```
+
+- こういうfbdelayを2個以上つかうときのコードはどうなるのかな
+	- というか、fbdelayで生成されたコードをMIRに持ってくときにどうなるのか？
+	- Value型を単なるCodeじゃなくてDelayとして特別な値にリダクションすればいいのかな
+
+[[otopoiesis]]でパラメーターを生成するのにも使える？
+
+```rust
+fn synth(freq,gate){
+  osc(freq)*gate
+}
+
+fn synth_module(freq:()->float,gate:()->float){
+ `||{ synth(freq(),gate()) }
+}
+```
+
+これのモジュールを評価すると、freq,gateがUIに現れるという感じでできるのかな（そして、ここでUIの範囲制限をするためにも数値型が範囲を持っていた方がいいということになりそう）
+
+うーん、サンクを手動で使わず表現できるような何かが欲しいなあ
+
+```rust
+fn wrap_module(param:Param, synth:(Param)->float ){
+  `{ | | synth(param |> invoke) }
+}
+```
+Param型はinvokeでuiからの値を取れる、サンクをアンラップするようなメソッドを持つ型クラスに属している、という感じで、ジェネリクスが実装出来たらいけそうね
+
+
+## マクロを提供するプラグイン
+
+プラグインも、各関数が返す型と同時にどのレベルでその関数が使えるかをコンパイラに渡す必要がある
+
+
+### ファイル読み込みはどうなる？
+
+[[mimiumのファイルIO]]の話。マクロの展開より先に型の評価が行われるので、例えばファイルを読み込んでからチャンネル数が分かる、みたいな場合型情報を読み込む段階でファイルを読みこまなければならない、がその評価のためにはマクロを実行して文字列の値を受け取らなければならない、、、ということで、結局[[依存型]]がないと多段階計算でも対応できない。
+
+結局、読み込んで返す値として次元数の値を持つ配列を返すしかないのかも
+
+

content/mimiumのレコード型.md

@@ -147,7 +147,7 @@ myugen({ default_v <- freq = 200.0 })
 
 ---
 
-## 部分型と型クラス
+## 部分型と[[型クラス]]
 
 [[構造的部分型]]を採用するつもり。
 

content/otopoiesis.md

@@ -123,6 +123,26 @@ fn reverse(origin:Region)->Region{
 	- 再生前（prepareToPlay)
 	- 信号再生時（process）
 
+## 多段階計算と組み合わせる
+
+[[mimiumと多段階計算]]で、それなりに多段階計算の実装が間に合ってきた。
+
+FadeinOutのようなリージョン→リージョンの関数はステージ0の計算と考えることができる。
+
+また、Generator系も、基本的には周波数や音量といったUIパラメーターは、ステージ0での評価時にUIを生成して値を受け取るチャンネルを作り、ステージ1＝再生中にそのUIからの値を受け取るという方式で捉えられる
+
+```rust
+fn audiofx(param1=100,param2=200){
+	`|input|{... }
+}
+
+fn gen_component(){
+ Param{..} |> sinosc
+}
+```
+`Param`はジェネリックな
+
+
 ---
 以下は昔に考えていたこと
 

content/お菓子くん.md

@@ -0,0 +1,8 @@
+---
+date: 2025-07-05 15:45
+---
+#research 
+
+会議が煮詰まってくると、机にお菓子を投げ込んでくれるデバイス
+
+ https://ipsj.ixsq.nii.ac.jp/records/183464

content/コンパイラを書く時の悩みについて.md

@@ -0,0 +1,10 @@
+#compiler-design 
+
+- ある程度コンパイラのコードベースが大きくなってくると、認知負荷がでかくなってくる
+- かといって、コードをコンパクトに保とうとすると、一箇所の変更がしづらくなっていく
+	- かといって、頑張ってインターフェースを切って分離性を高めていくと、全体の把握はしづらくなる
+- そりゃ全体を把握しなくいても継続的に開発できるようにするのが目的なのでそうなんだけど
+- 例えば、シンタックスツリーに[[Red Green Syntax Tree]]をあとから使おうとすると、さすがに書き換えが大変
+	- だが、Language Serverを作ろうと思ったらいつかは必要
+	- これをインクリメンタルに開発するのは無理だよなあ
+- 

content/コードフォーマッター.md

@@ -0,0 +1,41 @@
+---
+date: 2025-07-22 17:00
+---
+#programming-language 
+
+一般的なコードフォーマッターの実装について。
+
+[How to write a code formatter](https://yorickpeterse.com/articles/how-to-write-a-code-formatter/)
+
+1行当たり最大文字数がこのくらい、としたときに、どういう戦略で折り返すかは結構難しい問題。
+
+文字列→トークン→ASTという順番で変換されるので、この逆順が良いのかとも思ったが、
+
+AST→フォーマッタ用の専用の木構造みたいな中間表現を一度挟んだほうが賢いのかもしれない
+
+[[Rust]]の[pretty](https://docs.rs/pretty/latest/pretty/)クレートがコンビネーターとして定義してあるやつ
+
+[[Tree-sitter]]を使った汎用フォーマッター[Topiary](https://topiary.tweag.io/)とかいうのもある
+
+---
+
+Exprの途中に差し込まれたトリビア（主にコメント）をどうやって抽出するか
+
+ExprNodeIdに対するSecondary MapがSpanに対して作れているのだから、Trailng Triviaとしてコメントを保持するのは一応できるか？
+
+パーサコンビネータでどうにか処理できるもんか？
+
+```rust
+fn parse_expr_top<Output>()->impl Parser<Token,Output,Error>{
+   not(comment()).padded_by(comment().repeated())
+}
+
+```
+
+[Parser in chumsky - Rust](https://docs.rs/chumsky/latest/chumsky/trait.Parser.html#method.map_with)
+
+`map_with`使えばいけるかしら
+
+Stateにトリビアを書き込んでおけばいいのか
+
+

content/パッケージマネージャー.md

@@ -0,0 +1,14 @@
+---
+date: 2025-07-09 19:14
+---
+#programming-language 
+
+言語のライブラリなどをリモートリポジトリから取得、管理する仕組み。
+
+バージョンの依存性解決なども機能のうちに含む。
+
+
+[[Suwa Takashi]]さんの記事がパッケージマネージャとは何かをよく解説してくれている
+
+[パッケージマネージャを自作するときに考えること - gfnweb](https://gfngfn.github.io/ja/posts/2023-02-15-on-creating-package-managers/)
+

content/型クラス.md

@@ -0,0 +1,15 @@
+#programming-language 
+
+[[Rust]]におけるTraitとかに近いもの
+
+あるメソッド群を持つジェネリックな型の分類
+
+パラメトリックなジェネリクスに対して、対象が広すぎるものを、アドホック多相的に制限する
+
+["Hackett: a metaprogrammable Haskell" by Alexis King - YouTube](https://youtu.be/5QQdI3P7MdY)
+
+この動画の説明わかりやすかった（12:10～）
+
+式をもとに型を生成するのが[[型推論]]、型情報をもとに式を生成するのがジェネリクスというループ
+
+[[Hackett]]

content/多段階計算.md

@@ -32,9 +32,18 @@ http://www.cs.tsukuba.ac.jp/~kam/lecture/gairon2-2012/gairon2.pdf
 
 λ○□：両方を統合
 
+[[SATySFi]]：組版言語だが、マクロのシステムとして多段階計算が導入されている。
+
+[多段階計算の型システムの基礎 - gfnweb](https://gfngfn.github.io/ja/posts/2022-05-12-slides-type-system-matsuri-2020/)([[Suwa Takashi]])
 
 [SATySFi の多段階計算入門](https://sankantsu.hatenablog.com/entry/2022/08/19/215024)
 
+## 用語
+
+**Cross-Stage Persistence**：基本的にステージ0/1でのコードはそれぞれステージ0/1の中でしか使えない。何らかの方法で両方のステージで跨いで使える仕組みを作れると便利
+
+**Run**プリミティブ：
+
 ## [[依存型]]との組み合わせ
 
 [A Dependently Typed Multi-Stage Calculus](https://arxiv.org/abs/1908.02035)

content/多段階計算を命令型VMインストラクションで表現したい.md

@@ -18,9 +18,9 @@ VMは最初、マクロ評価時に自分の現在の評価ステージを0と
 
 VMは、命令記録モードと実行モードの2種類で、現在の評価ステージが0のときに実行モードになる
 
-mainプログラムの先頭はマクロ展開のため必ずincl_levelからスタート＝命令記録モードから開始
+mainプログラムの先頭はマクロ展開のため必ずincr_levelからスタート＝命令記録モードから開始
 
-命令記録モードでは、decl_levelがでてくるまでバッファに実行した命令をコピーし続ける
+命令記録モードでは、decr_levelがでてくるまでバッファに実行した命令をコピーし続ける
 decl_levelでレベル0になったら...うーん
 
 ```ocaml
@@ -62,3 +62,7 @@ endescape
 ret 1
 ```
 
+
+VMの構造にメタプログラミングを埋め込むよりも、MIR生成段階でなにかしらのサンクを呼び出すということにして一時的に空にしておく、みたいなやり方のほうが素直かもな
+
+

content/小数から近い分数を求める.md

@@ -0,0 +1,122 @@
+---
+date: 2025-07-24 17:54
+---
+#memo #mathematics 
+
+例えば、[[双方向プログラミング]]的なもので、数値をスライダーで調整できるようになっていた場合、実際のところは5/7とかわかりやすい有理数だったりとか、整数に近い値を表したいのにめちゃくちゃ長い小数点の数値が残ったりする。
+
+これを、適当なグリッドにスナップするUIの一つとして、許容できる誤差範囲と整数の複雑さを指定して分数に変換するのが良いのではないか。
+
+ChatGPTに聞いた。[[連分数展開]]というのを使うと良いらしい。[[Rust]]のコードを書いてもらった。
+
+```rust
+/// 任意の実数 x を近似する収束分数・半収束分数を求める
+///   x: 近似したい実数
+///   eps: 絶対誤差許容値
+///   max_den: 分母の上限
+///   max_num: 分子の上限
+fn rational_approx(
+    x: f64,
+    eps: f64,
+    max_den: u64,
+    max_num: u64,
+) -> Vec<(u64, u64)> {
+    // 連分数展開の a_k リストを構築
+    let mut a: Vec<u64> = Vec::new();
+    let mut r = x;
+    for _ in 0..64 {
+        let ak = r.floor() as u64;
+        a.push(ak);
+        let frac = r - (ak as f64);
+        if frac.abs() < f64::EPSILON {
+            break;
+        }
+        r = 1.0 / frac;
+    }
+
+    let mut candidates: Vec<(u64, u64)> = Vec::with_capacity(a.len());
+    let (mut p_nm2, mut q_nm2) = (0u128, 1u128);
+    let (mut p_nm1, mut q_nm1) = (1u128, 0u128);
+
+    for &ak in &a {
+        // 収束分数
+        let p = ak as u128 * p_nm1 + p_nm2;
+        let q = ak as u128 * q_nm1 + q_nm2;
+        if q > max_den as u128 { break; }
+        let num = p as u64;
+        let den = q as u64;
+        if num <= max_num {
+            let approx = (num as f64) / (den as f64);
+            if (x - approx).abs() <= eps {
+                candidates.push((num, den));
+            }
+        }
+        // 半収束分数
+        for d in 1..=(ak / 2) {
+            let ap = ak - d;
+            let p2 = ap as u128 * p_nm1 + p_nm2;
+            let q2 = ap as u128 * q_nm1 + q_nm2;
+            if q2 <= max_den as u128 && p2 <= max_num as u128 {
+                let num2 = p2 as u64;
+                let den2 = q2 as u64;
+                let approx2 = (num2 as f64) / (den2 as f64);
+                if (x - approx2).abs() <= eps {
+                    candidates.push((num2, den2));
+                }
+            }
+        }
+        p_nm2 = p_nm1;
+        q_nm2 = q_nm1;
+        p_nm1 = p;
+        q_nm1 = q;
+    }
+
+    candidates.sort_by(|&(p1, q1), &(p2, q2)| {
+        let e1 = (x - (p1 as f64)/(q1 as f64)).abs();
+        let e2 = (x - (p2 as f64)/(q2 as f64)).abs();
+        e1.partial_cmp(&e2).unwrap()
+    });
+    candidates.dedup();
+    candidates
+}
+
+/// x を percent% 精度で近似するラッパー
+///   x: 近似したい実数
+///   percent: 相対誤差許容値（%）
+///   max_num: 分母、分子の上限
+fn rational_approx_pct(
+    x: f64,
+    percent: f64,
+    max_num: u64,
+) -> Vec<(u64, u64)> {
+    let eps = (percent / 100.0) * x.abs();
+    rational_approx(x, eps, max_num, max_num)
+}
+
+fn main() {
+    let x = 2.7182818284;
+    let percent = 1.0; // 1%
+    let max_num = 500;
+    let results = rational_approx_pct(x, percent, max_num);
+    println!("近似候補（percent={}%）:", percent);
+    for (p, q) in results {
+        let approx = p as f64 / q as f64;
+        let err = (x - approx).abs();
+        println!("{}/{} = {:.8}, 誤差 {} ({:.4}%差)",
+            p, q, approx, err, err / x.abs() * 100.0);
+    }
+}
+
+```
+
+```
+近似候補（percent=1%）:
+193/71 = 2.71830986, 誤差 0.00002803075492963103 (0.0010%差)
+106/39 = 2.71794872, 誤差 0.00033311045128181505 (0.0123%差)
+87/32 = 2.71875000, 誤差 0.00046817160000012237 (0.0172%差)
+68/25 = 2.72000000, 誤差 0.0017181716000003178 (0.0632%差)
+49/18 = 2.72222222, 誤差 0.003940393822222443 (0.1450%差)
+19/7 = 2.71428571, 誤差 0.003996114114285465 (0.1470%差)
+```
+
+悪くなさそう（ここから5個ぐらいまでを提示するとして、）