第３０回世界コンピュータ将棋選手権の頂点を目指せだぜ☆（＾～＾）＜その１＞
2020-01-30(Thu) 21:15 - 24:00
「 確定申告の書類作りが進まず……☆」
「 もういい、寝ろ☆」
「 １月３１日に ひばりが丘駅南口のコンビニが潰れるから コピー機使えなくなるわよ！」
「 コピー機がないと不便だよな☆」
「 きふわらべ でもいじるか……☆」
「 これは ＷＣＳＣ２８版じゃないか☆ 去年のはお蔵入りか☆？」
「 ＷＣＳＣ２８版は どうぶつしょうぎ、 ＷＣＳＣ２９版は 大橋流バージョンか……☆ はあ～☆
最近の流行りに書き直そうぜ☆？ チェス風にするのが ふつうなんだろ☆？」
「 はあ～☆
Rust の 2018エディション以前に書いたから、新しい Rust ではコンパイルが通らないぜ☆」
「 どう 書き直したらいいのかしら？」
「 配列の初期化って 書き方 変わったんだろうか☆？」
cargo check 2> ./error.log
「 ↑ とりあえず、エラー出力を ファイルにリダイレクトしよう……☆」
/// こういうコメント
「 ↑ なんか ドキュメント・コメントは 書ける位置が決まってるみたいだな……☆」
//! こういうコメント
「 ↑ ファイルの先頭のコメントにも 書き方があるのかだぜ☆？」
error[E0433]: failed to resolve: use of undeclared type or module `teigi`
--> src\consoles\asserts.rs:4:5
|
4 | use teigi::shogi_syugo::*;
| ^^^^^ use of undeclared type or module `teigi`
「 ↑ モジュール・システムも だいぶ変わってしまったのか☆？」
main.rs:
Before:
mod teigi;
After:
pub mod teigi;
「 ↑ 適当に 書きかえてみるか……☆」
use super::a::*;
use self::b::*;
「 ↑ 絶対パスでエラーがでるから、相対パスにしてみるか……☆」
use super::super::a::*;
use super::super::super::b::*;
「 ↑ super が どこ指してるか分からん……☆ ../ とかにしてくれればいいのに……☆」
muzudho/rust-kifuwarabe-wcsc30
「 ↑ モジュール・システムを書き直して ギットハブにあげるぜ☆」
2020-01-31(Fri) 20:25 -
「 うー 寒（さぶ）☆」
rustup update
「 Rustの環境 更新しよ……☆」
error: could not remove 'rustup-bin' file: 'C:\Users\むずでょ\.cargo\bin\rustup.exe'
error: caused by: アクセスが拒否されました。 (os error 5)
error: backtrace:
error: stack backtrace:
0PS C:\Users\むずでょ\source\repos\rust-kifuwarabe-wcsc30> : <unknown>
1: <unknown>
2: <unknown>
3: <unknown>
4: <unknown>
5: <unknown>
6: <unknown>
7: <unknown>
8: <unknown>
9: BaseThreadInitThunk
10: RtlUserThreadStart
```
「 なぜなのか……☆？」
`[Windows] + [R], cmd`
rustup component add rls rust-analysis rust-src
info: component 'rls' for target 'x86_64-pc-windows-msvc' is up to date
info: component 'rust-analysis' for target 'x86_64-pc-windows-msvc' is up to date
info: component 'rust-src' is up to date
rustup install nightly-2018-12-06
# 2020-02-01(Sat) 12:00 -
「 駒の名称を チェスに合わせよう☆ 世界を視野に入れると それが普通だからな☆」
Bad: PB
Good: PromotedBishop
「 ↑ ２０１０年の後半あたりからだろうか、２０２０年現在は 頭文字を使った略称ではなく、名称にするのが 流行りだぜ☆」
「 英語で発声できる名前の方が 今の映像配信時代には 口頭で コミュニケーションしやすいのよね」
「 可視性より 伝達性の方が重要なんだろうな☆ また１０年後には どうなるか知らんが☆」
「 駒を裏返すと 何の駒になる、というのは switch 構文や、 match 構文を使うのが高速だが、しかし待ってほしい☆
リンク・リスト形式も ワンチャンあるのではないか☆？」
「 駒の種類を オブジェクト型定数 にするのかだぜ☆？ それも どうだか☆」
```rust
use super::piece::Piece;
pub struct PieceStruct {
piece: Piece,
/// 駒→成駒 （成れない駒は、そのまま）
promoted: Piece,
}
impl PieceStruct {
pub fn from_piece(p: &Piece) -> Self {
use super::piece::Piece::*;
match *p {
King1 => PieceStruct {
piece: King1,
promoted: King1,
},
Rook1 => PieceStruct {
piece: Rook1,
promoted: PromotedRook1,
},
Bishop1 => PieceStruct {
piece: Bishop1,
promoted: PromotedBishop1,
},
Gold1 => PieceStruct {
piece: Gold1,
promoted: Gold1,
},
Silver1 => PieceStruct {
piece: Silver1,
promoted: PromotedSilver1,
},
Knight1 => PieceStruct {
piece: Knight1,
promoted: PromotedKnight1,
},
Lance1 => PieceStruct {
piece: Lance1,
promoted: PromotedLance1,
},
Pawn1 => PieceStruct {
piece: Pawn1,
promoted: PromotedPawn1,
},
PromotedRook1 => PieceStruct {
piece: PromotedRook1,
promoted: PromotedRook1,
},
PromotedBishop1 => PieceStruct {
piece: PromotedBishop1,
promoted: PromotedBishop1,
},
PromotedSilver1 => PieceStruct {
piece: PromotedSilver1,
promoted: PromotedSilver1,
},
PromotedKnight1 => PieceStruct {
piece: PromotedKnight1,
promoted: PromotedKnight1,
},
PromotedLance1 => PieceStruct {
piece: PromotedLance1,
promoted: PromotedLance1,
},
PromotedPawn1 => PieceStruct {
piece: PromotedPawn1,
promoted: PromotedPawn1,
},
King2 => PieceStruct {
piece: King2,
promoted: King2,
},
Rook2 => PieceStruct {
piece: Rook2,
promoted: PromotedRook2,
},
Bishop2 => PieceStruct {
piece: Bishop2,
promoted: PromotedBishop2,
},
Gold2 => PieceStruct {
piece: Gold2,
promoted: Gold2,
},
Silver2 => PieceStruct {
piece: Silver2,
promoted: PromotedSilver2,
},
Knight2 => PieceStruct {
piece: Knight2,
promoted: PromotedKnight2,
},
Lance2 => PieceStruct {
piece: Lance2,
promoted: PromotedLance2,
},
Pawn2 => PieceStruct {
piece: Pawn2,
promoted: PromotedPawn2,
},
PromotedRook2 => PieceStruct {
piece: PromotedRook2,
promoted: PromotedRook2,
},
PromotedBishop2 => PieceStruct {
piece: PromotedBishop2,
promoted: PromotedBishop2,
},
PromotedSilver2 => PieceStruct {
piece: PromotedSilver2,
promoted: PromotedSilver2,
},
PromotedKnight2 => PieceStruct {
piece: PromotedKnight2,
promoted: PromotedKnight2,
},
PromotedLance2 => PieceStruct {
piece: PromotedLance2,
promoted: PromotedLance2,
},
PromotedPawn2 => PieceStruct {
piece: PromotedPawn2,
promoted: PromotedPawn2,
},
Kara => PieceStruct {
piece: Kara,
promoted: Kara,
},
Owari => PieceStruct {
piece: Owari,
promoted: Owari,
},
}
}
pub fn piece(self) -> Piece {
self.piece
}
pub fn promote(self) -> Piece {
self.promoted
}
}
「 ↑ つまり こう☆」
「 どうなんだろなあ☆？」
「 人間がボトルネックなのだから、コーディングは 人が目視確認できることが重要なのよ。
コンピューターが最高の成功を発揮できないことより、人類のポカが足を引っ張ることの方がデカいのだから、
人力で管理しやすいように作りなさい」
「 発想が 開発（部） だな☆」
「 升も 番号で持ってるんだが、この番号はよく変換処理入るんで、オブジェクトにしてメソッドを持たせられないか……☆」
「 あっ、バグった☆」
「 くそっ☆！」
「 最後まで指さないと テストにならんか……☆」
「 わたしは しつこい☆ バグが出ない版まで遡り、ソースコードと睨めっこだぜ☆
ここの 順番を入れ替えたところが ＢＡＤ だったぜ☆」
「 直せだぜ☆」
2020-02-04(Tue) 21:30 -
「 そろそろ お父んは 頂点になった頃だろうか……☆（＾～＾）？」
「 グローバル変数に universe と名前を付けているが、その下に game を作りたいぜ☆
対局という意味だぜ☆」
「 search で十分なんじゃないのか☆？」
「 それより winner （勝者）の方がよくない☆？」
「 それはありだな☆」
「 次の話題☆ Rust のメモリの思想からすると、
アプリケーション起動時に 駒を全種類作っておいて、
盤の上には その駒の名前のようなもの、Ｃ言語で言うならポインターを置いておくのが いいのだろうか☆？」
「 何を言っているか分からないが、最適化の話しなら 後にしろだぜ☆」
「 はっしゅ とか言うのを使うのが常套手段そうよ？」
「 それは やりたいところだな……☆ PieceHash とかいう列挙型を作るといいのかもしれないが……☆」
「 列挙型のことをハッシュとは言わない☆」
「 アプリケーション起動時に作った駒の 実体 を application 変数に入れておいて、それとは別に 盤面の上に 実体を指す名前 を置いておけば いい気もするが……☆」
「 じゃあ position （局面）は駒を持ってない ただの目録かだぜ☆」
「 駒を 0～15 の数で表すのは 普通では☆」
「 先後があるので およそ３０駒な☆ それでいくか☆」
&universe
.get_application_part()
.get_piece_struct_master()
.get_piece_struct(
universe
.get_search_part()
.get_current_position()
.get_piece_by_square(&square),
)
.phase(),
「 ↑ これは クソコード かだぜ☆？」
「 階層が深いのは クソコード だよな☆
駒の実体は search_part に持たせた方がいいのか……☆？」
universe
.get_search_part()
.get_piece_struct_by_square(&square)
.phase();
「 ↑ ひとまず、 search_part から見て 見た目上 １階層で呼び出しているように見えるようにしておくぜ☆」
for pc in KM_ARRAY.iter() {
g_writeln(&format!("利き数：{}", pc));
let s = universe.kaku_number_board(&Phase::Owari, *pc); // Error
g_writeln(&s);
}
「 ↑ イテレーターで取ってこれるの参照だから、* を付けて実体にするが、これを関数の引数に渡すと ボローと取られるのかだぜ☆
.clone() で逃げれるかな……☆？」
2020-02-09 (Sun) 14:00 -
「 ↑ 繰り返し作業のとき こういうタイピングミスをしやすいぜ☆」
「 お父んの Rust-RLS、 オート・コレクトなんで働かないんだろうな☆？」
2020-02-14 (Fri) 20:45 -
「 バック・プロパゲートを調べようぜ☆？」
「 ↑ やねうら王の learn 部を見ようぜ☆？」
「 ↑ 2,800行ほどある……、萎え……☆」
「 お父ん、微分は 見つかったか☆？」
「 急ぐなだぜ☆ のんびり☆」
「 微分の連鎖律とか、さっぱり見当たらん☆
シグモイド関数と その導関数が見つかるだけだぜ☆」
https://github.com/yaneurao/YaneuraOu/blob/master/source/learn/learner.cpp:
// 995行目
// 普通のシグモイド関数
double sigmoid(double x)
{
return 1.0 / (1.0 + std::exp(-x));
}
// 1009行目
// 普通のシグモイド関数の導関数。
double dsigmoid(double x)
{
// シグモイド関数
// f(x) = 1/(1+exp(-x))
// に対して1階微分は、
// f'(x) = df/dx = f(x)・{ 1 - f(x) }
// となる。
return sigmoid(x) * (1.0 - sigmoid(x));
}
「 この式は 何年か前に見たやつじゃない。象さんなんでしょ」
「 ひとまず ここから解説していこうぜ☆」
「 ↑ 数学には いろいろな話しと出会うと思うが、 飯を食べれば うんこをするように、
疑問を抱かずに受け入れて欲しいのが 空っぽのことをゼロ、満タンのことをイチ と呼ぶことだぜ☆」
「 空っぽ だの、 満タン だの、中途半端 だの そんなに最初に もったいぶって 説明するほどのことかだぜ☆？」
「 ０．９ というのは ０と１ があって、そこから遠回りして やっと出てくる数だし、
２ というのは １ と １ があるから出てくる数だし、 ゼロ と イチ は 種とか 卵とか そういう全ての原因だぜ☆」
「 じゃあ ゼロ と イチ だけ極めれば どんな数も作れるんじゃないの？」
「 卒業だぜ☆ 数学は終わった☆」
「 まだ 飯を食べて うんこをするところしか 始まってないのでは☆？」
「 さらに進んで、もう１つの見方がある☆」
「 １に満たないか、満ているか の２択だぜ☆」
「 ０か、 中途半端か、 １か、 の３択なんじゃないの？」
「 それは 中途半端を許せば そうなるな☆ そうではなく、中途半端を許さない場合は
『空か または 何かがある』、
また そうでない場合は
『足りないか または 足りた』
の ケースだぜ☆」
「 どっちでもいい……☆」
「 わたしは このポンプを見ているだけで 面白くて 満足感がある……☆」
「 中途半端なものを数えないのなら、 ０ と １ だけあれば いいんじゃないの？」
「 これは 数学の特徴というより、人類の特徴なのかも知れない☆
切り捨ての不思議 だぜ☆ 例えば……☆」
「 ↑ これぐらい いっぱい入った ドリンクが ４本あったとしよう☆」
「 ↑ 満タンではなかったのだから、内容量 ゼロ のドリンク４本 飲んだのと同じだよな☆」
「 理解に苦しむ……☆」
「 ↑ 総量で数えていいのなら ３本と さらに１本弱 飲んだと言っていいはずだぜ☆
しかし その或る世界 は総量では できてないんだぜ☆」
「 なんで 総量 にできないんだぜ☆？」
「 簡単な解釈を与えれば……☆」
「 味が違うから 混ぜたものは 認められないとかだな☆」
「 １ は 超えてもいいの？ １００万とか １０兆とか」
「 １００万飲んでも １０兆飲んでも １本分な☆」
「 それも理解に苦しむ……☆」
「 このとき、１とは 何なのか、に 説明というか、言葉を与えるとするなら
スレッシュホールド（Threshold; 閾値）だぜ☆」
「 スレッシュホールドは ２ とか、 １０００兆 とかじゃダメなの？」
「 ↑ 閾値を１０００兆にするより、 コイン１枚の額面を １０００兆分の１ にしろだぜ☆
大丈夫、イチゴ味の世界のコイン１枚と スイカ味の世界のコイン１枚は 比較しないんで、桁が違ってても気にするなだぜ☆」
「 そんな特殊ルール、数学と何の関係が有るんだぜ……☆？」
「 上の図は シグモイド関数を使っていない例だぜ☆
じゃあ、シグモイド関数が何をしているものなのかは、もう説明できるぜ☆」
「 ↑ これが シグモイド関数を使ってできることだぜ☆」
「 ぐちゃぐちゃになっただけだぜ☆」
「 ↑ シグモイド関数が無いときは こうだろ☆」
「 ↑ 有るときは こうだぜ☆」
「 何が違うの？」
「 真ん中と 端っこでの傾きが違う☆」
「 ↑ 傾きの違い を調べたいときには、こんな線形のグラフは 役に立たん☆」
「 ↑ シグモイド関数に通して見た数は 真ん中の近くのときの傾きは敏感で、端っこの時は 鈍感だぜ☆」
「 さっぱり分かんないわね」
「 言ってしまえば 限りなく大きなこと、限りなく小さなこと について 鈍感 にしてるんだぜ☆
逆に ある範囲内でだけ 敏感 にしてるんだぜ☆」
「 なんべん聞いても さっぱり分からん☆」
「 多変数関数の合成関数の微分の連鎖律は どこにあんの？」
「 多変数と言っても 絵に描けるのは３次元までなんで、
ここでは ２変数としよう☆」
「 ↑ 今までは １変数 だったわけだぜ☆」
「 ↑ ２変数 だと 平面で描けるな☆ 絵がヘタクソで上手く見せれていないが……☆」
「 ↑ ２変数関数の偏微分だと こうなる☆」
「 偏微分じゃなくて、微分なのよ」
「 合成って何だぜ☆？」
「 合成は 関数の引数に入れるだけだぜ☆」
「 ２変数関数 と、 ２つの２変数関数 の違いは よくイメージしてくれだぜ☆」
「 頭が おかしくなる！」
「 ２つの２変数関数の合成関数 も イメージ できるだろ☆」
「 おかしくなった頭の中にある おかしさが 頭になる！」
「 ２つの２変数関数の合成関数の微分 が どこを微分してるのかは よくわからないよな☆」
「 あらゆる方向に微分すればいいじゃないか☆」
「 あらゆる方向って、どうやって計算するんだぜ☆（＾～＾）！」
「 多変数関数の合成関数の微分 には 連鎖律 があるそうよ」
「 連鎖律 なんか どこにあるんだぜ☆？」
「 お父んの考え方では 連鎖できないのではないか☆？ なんで 合流 してるんだぜ☆？」
「 合成 だろ☆」
「 ２つのものが１つになっている☆ 合流 だぜ☆」
「 連鎖律 さっぱり分からんな……☆」
「 他の人の連鎖律を見てみると、タンデムになってない？ あんたのは 合流してんのよ」
「 日本語を読んだとおりにやってるのに……☆」
「 分からんところは 後回しだぜ☆ シグモイド関数を説明しよう☆」
「 シグモイド関数は もういいのに……☆」
「 ↑ ｅはネイピア数で 2.718281828… みたいな３より小さい数で、マイナスの指数は
ガンガン割って小さくしていく ぐらいの意味なんで、ｘが大きくなると、分数は小さくなるんで、数としては 大きくなっていて、
永遠に１にはならないが、限りなく１に近づくぜ☆（＾～＾）」
「 何を言ってるか分からん☆」
2020-02-15 (Sat) 11:25 -
「 他の人の 多変数関数の合成関数の微分 を見ると なんか わたしのやり方と違うな……☆」
「 成分ごとに 微分してるのよ！」
「 ２つの２変数関数の合成関数 は合ってると思うんだが、微分の仕方が違う……☆」
「 ↑ こうなのでは☆？」
「 偏微分 を覚えたか☆」
「 しかし ∂ｗ がｙ軸を動いているのは 変な気がする……☆」
「 ↑ じゃあ、こうなのでは☆？」
「 じゃあ ｘの他の軸を固定したら 合成関数から見れば 遡って ∂ｕ も動いてはいけないぜ☆（＾～＾） 固定だぜ☆（＾～＾）」
「 どのｘ軸だけ動けんの？ ∂ｚ だけ動けんの？ それ以外の軸は 過去にさかのぼって固定されんの？」
「 ｘ軸を１つ 固定したら そうなるだろ☆！」
「 お父んの図は 独立変数 と 従属変数 がはっきりしてないらしいぜ☆」
「 なんてこった☆（＾～＾）！」
「 ↑ 独立変数と、従属変数は こいつらだぜ☆」
「 この図では ｘ も ｕ も ｚ も ｘ軸みたいに見えるが、 ｘ軸と ｕ軸と ｚ軸は まったく別物だぜ☆ 同じものだと思うなだぜ☆」
「 成長したな☆」
「 ｘの動きが よく見えるようになってきたぜ☆」
「 ｘを動かせば ｔ が一意に定まりそうだぜ☆（＾～＾）」
「 それを 微分でやるのよ」
「 ↑ ∂（デル）は ｘと ｚと ｔ に付くが、定数ｕ、ｖ、ｙ、ｗは 式に出てこないんじゃないか☆？」
「 ↑ 絵図が見えてきたぜ☆」
y = f(x)
「 ↑ 答え合わせをする必要があるので、他人が残したメモをパクるぜ☆
関数ｆ は ｘの１変数しかないが、まあ いいだろう……☆」
y = (3x^2 +4x +3)^4
「 ↑ 関数ｆ の定義は上の通りとする☆
これを いったん、２ステップに分けるみたいだぜ☆」
y = u^4
u = 3x^2 +4x +3
「 なんで分けたの？」
「 合成関数 の話しをしたいんだから、関数は合成して作るんだぜ☆
合成の話しをするために、今、もともと１つだったものを、わざと ２つに分けたんだぜ☆」
「 フーン」
「 次に 微分しようぜ☆」
dy/du = 4*u^3
du/dx = 2*3x^1 +1*4 + 0*3(x^-1)
= 6x + 4
「 お父んが 微分をするときの 手つきが怪しいぜ☆」
「 ここで、 dy/du と du/dx を掛け合わせると、 y になるらしいぜ☆」
「 ほんとか☆？」
「 やってみようぜ☆？」
「 微分したものと、微分したものの掛け算って どうやんの？」
「 微分したことを忘れて 目の前にある２つの式を掛け算しろだぜ☆」
y = dy/du * du/dx
= (4*u^3) * (6x + 4)
「 ↑ つまり こういうことだと思うが……☆」
y = (4*u^3 * 6x) + (4*u^3 * 4)
「 ↑ 初手は 分配法則ぐらいしか やることないと思う☆」
y = (4u^3 * 6x) + (16u^3)
「 ↑ うーむ、さっぱり☆」
「 u に 3x^2 +4x +3 を代入して u を消すんじゃないの？」
y = ((4 (3x^2 +4x +3)) ^3 * 6x) + ((16 (3x^2 +4x +3)) ^3)
「 ↑ じゃあ u を消してみるかだぜ☆」
y = ((12x^2 +16x +12)^3 * 6x) + (48x^2 +64x +48)^3
「 ↑ 分けもわからず 分配法則☆」
「 詰まったぜ☆」
2020-02-16 (sun) 05:30-
「 やりなおせ☆！」
y = dy/du * du/dx
= (4*u^3) * (6x + 4)
「 ここからか……☆」
「 分配するのと、uに代入するの、どっちが先がいいんだぜ☆？」
「 さっきと違う手順でやりなさい」
u = 3x^2 +4x +3
dy/du = 4*u^3
du/dx = 6x + 4
y = dy/du * du/dx
= (4*u^3) * (6x + 4)
= (4*(3x^2 +4x +3)^3) * (6x + 4)
= (4*(3x^(2+3) +4x^3 +3^3)) * (6x + 4)
= (4*(3x^(5) +4x^3 +9)) * (6x + 4)
= (12^5 +16x^3 +36) * (6x + 4)
= ((12^5 +16x^3 +36) * 6x) + ((12^5 +16x^3 +36) * 4)
= (12^5 * 6x +16x^3 * 6x +36 * 6x) + (12^5 * 4 +16x^3 * 4 +36 * 4)
= ((12*6x)^5 +(16x * 6x)^3 +216x) + (48^5 +64x^3 +144)
= ((72x)^5 +(96x)^3 +216x) + (48^5 +64x^3 +144)
= (72x^5 + 96x^3 + 216x) + (48^5 + 64x^3 +144)
= 72x^5 + 96x^3 + 216x + 48^5 + 64x^3 +144
= 72x^5 + 48^5 + 96x^3 + 64x^3 + 216x +144
「 ふぅ、どうにもならんぜ☆」
「 やりなおせ☆！」
「 他の人のを見ると、u に代入してないが……☆」
u = 3x^2 +4x +3
dy/du = 4*u^3
du/dx = 6x + 4
y = dy/du * du/dx
= (4*u^3) * (6x + 4)
= (4u^3) * (6x + 4)
= 4u^3 (6x + 4)
= u^3 (24x + 16)
「 ↑ ここを分配するのがいいのか、しない方がいいのか 分からんな……☆」
「 桁数は 小さい方がいいのでは☆？」
y = 4u^3 (6x + 4)
「 ↑ じゃあ ここで いったん、止めておこうぜ☆」
「 u を消しなさいよ！」
u = 3x^2 +4x +3
y = 4u^3 (6x + 4)
= 4(3x^2 +4x +3)^3 (6x + 4)
「 ↑ x の関数 y がでけた……☆」
「 ちょっと待ってほしい☆」
y = (3x^2 +4x +3)^4
y = 4(3x^2 +4x +3)^3 (6x + 4)
「 この２つは 同じなのだろうか☆？」
「 同じなわけ ないだろ☆」
y = (3x^2 +4x +3)^4
y = 4(3x^2 +4x +3)^3 (6x + 4)
~~~~~~~~
「 上のｙは 微分する前で、
下のｙは、 上のｙを微分したものに すこし端数が付いている☆」
「 少しどころではないわよ？」
「 ｘの２乗 の次元に比べれば、 ｘ倍、 １倍の世界は 無視していいほど小さいということだぜ☆」
「 いいかげんだな☆」
「 もうちょい 説明を加えると……☆」
f(x) = y = (3x^2 +4x +3)^4
f'(x) = y' = 4(3x^2 +4x +3)^3 (6x + 4)
「 上の ｙ は 元の形、
下の ｙ' は y の 導関数 と呼ぶ☆」
「 本当か☆！」
「 じゃあ ライプニッツの微分式の記法は 導関数 なの？」
「 そうなるな☆」
「 導関数 は 英語で 何て言うの？」
「 Derivative（デリベーティブ）だぜ☆」
「 微分 は 英語で 何て言うの？」
「 Differential（ディファレンシャル）だぜ☆」
「 導関数 って いいかげん じゃない？」
「 恐らく、近似 なのでは……☆？」
「 大きな次元では合っていて、小さな次元では 合ってないのでは☆？」
「 全然 合ってないじゃないのよ！」
「 ↑ で、これは 合ってるのかだぜ☆？」
「 合ってる、合ってないではなく、定義式じゃないか それ☆？」
「 手計算で 合ってるか 検算する趣旨なのに、定義式じゃ 検算も何も ないじゃないのよ！」
「 ↑ で、 多変数関数の合成関数の微分 の例をパクってくると こういう感じだぜ☆」
「 +記号って どういう働きをするの？」
「 足すんじゃないか☆？」
「 足していいのか☆？」
「 ｕ と ｖ は 総量として１つのもので、どこかで ２つに分けたんだろ☆ 等分割に限らないだけで☆」
「 ｘも ｙも 同じ ｕ、 ｖ を使うのか☆？」
「 式を見ると 使ってるな☆」
「 ｘ が相手にする ｕ と、 ｙ が相手にする ｕ は、同じ ｕ なの？」
「 ｕ１ でも ｕ２ でもなく、 ｕ と書いてるから 同じなんじゃないか☆？」
「 あれっ、よく見ると 式が違うぜ☆？」
「 ↑ ｄ（ディー）ではなく ∂（デル）だったぜ☆」
「 大違いなんじゃないのか☆？」
「 すると 前に描いた ２つの二変数関数の合成関数の微分 には足し算が無かったから、間違いがあるのでは☆？」
「 なんということだぜ☆」
「 ↑ 二変数関数を よく見直そうぜ☆？」
「 二変数関数 ｘ，ｙ の出力は ｕ ではないのよ。 （ｕ，ｖ） なのよ」
「 なるほど……☆」
「 二値を返す図を描けばいいわけかだぜ☆」
＜次の記事へ＞
光速のアカウント凍結されちゃったんで……。ゲームプログラムを独習中なんだぜ☆電王戦IIに出た棋士もコンピューターもみんな好きだぜ☆▲(パソコン将棋)WCSC29一次予選36位、SDT5予選42位▲(パソコン囲碁)AI竜星戦予選16位
Crieitは個人で開発中です。
興味がある方は是非記事の投稿をお願いします！ どんな軽い内容でも嬉しいです。
なぜCrieitを作ろうと思ったか
また、「こんな記事が読みたいけど見つからない！」という方は是非記事投稿リクエストボードへ！
こじんまりと作業ログやメモ、進捗を書き残しておきたい方はボード機能をご利用ください！