[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/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/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/mimium.md

@@ -51,6 +51,13 @@ https://github.com/mimium-org/mimium-rs
 
 ふと思ったけど、[[SuperCollider]]や[[PureData]]と比べると、これらの言語は組み込みに使おうと思うとLinuxが動く環境を想定することになる（[[Heavy]]はそれを全く別の処理系作ることで対応してたけど）。シーケンサとかスケジューラーがあるような、[[Faust]]だと難しいタイプのプログラムを[[Arduino]]とかに持っていくには向いているのではないか([[Extempore]]だって仕組み的に言えばそうかもしれないけど)
 
+- できれば教育用途とかに持ち込めるのが一番いい
+- ブートストラップできるといい
+	- いろいろな人がmimiumで拡張やライブラリを書けるようになってからが本当の本番
+	- 言語自体の拡張機能をその言語上でたくさん作れるとよい
+	- しかし、極端に自由度が高いとそれはそれで参入障壁が高い
+
+
 [[mimiumでのシーケンサ]]
 
 [[mimiumでのライブコーディングエンジン]]

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

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個ぐらいまでを提示するとして、）