
はてなキーワード:記法とは
意外と役に立つかも
以下、GEMINIに書かせてみた。記法もGEMINIにお任せ。
老後資金(iDeCoと退職金)の受け取り方について悩んでいた50代の私。
「専門家に聞くのも億劫だし…」と思い、試しにAIアシスタントの**GEMINI**に相談してみたところ、驚くほど具体的かつ論理的な「最適解」を提案してくれました。
もし私と同じように**「長年勤めた会社で定年を迎えつつ、iDeCoもやっている(期間が被っている)」**という方がいれば、このGEMINIとのやり取りが非常に参考になるはずです。
### 私の悩み(前提スペック)
iDeCoと会社の勤続期間が完全に被っていることは分かっていましたが、「一括でまとめて貰うべきか?」「年金形式でチビチビ貰うべきか?」あるいは「その組み合わせが良いのか?」など、無数にある選択肢の中で**どれが自分にとっての最適解なのか全く判断がつかず、不安**がありました。
### GEMINIが出した「最適解」
GEMINIは、私の状況を分析し、以下のプランを提示してきました。
これが、税金・社会保険料・資金効率のすべてにおいてベストであるとのこと。
#### GEMINIによるシミュレーション結果
### GEMINIが指摘した「意外な落とし穴」
私が「iDeCoを年金形式(分割)で受け取れば税金安くなる?」と聞いたところ、GEMINIは即座に**「それはNG」**と警告してきました。
> 「年金形式で受け取ると雑所得扱いになります。62歳以降の無職期間に所得が発生すると、**国民健康保険料と介護保険料が跳ね上がります**。税金が少し安くなっても、保険料で損をする可能性が高いです。」
この視点は完全に抜けていました。さすがGEMINI。
期間の重複計算や、社会保険料への影響など、複雑な変数を考慮した上で「これが最適解です」と断言してくれたのは非常に心強かったです。
もちろん最終確認は必要ですが、漠然とした不安を抱えている方は、一度GEMINIに**「私の退職金とiDeCo、どう受け取るのが一番お得?」**と聞いてみることを強くおすすめします。
知らんがな。
さっきのエントリに追加した内容だけど
千葉だって歴史的には上総国、下総国とかあってそこには文化的蓄積があったはずなんだけどな。住んでると全く感じられないんだよね。結局昔は島だったから水運で栄えた地域で、そのときに重要拠点だった地域は内陸とか北の方っぽいんだよね。
でも現代に東京のベッドタウンとして人口的に中心になってるのは京葉道路とか総武線沿いで、その辺は昔は単に海だったんじゃないかな。知らんけど。
じゃあ千葉にもなんかしらあるだろ。鎌倉殿に出てくる千葉氏ゆかりのなんかあるだろ。
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251208185756# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaTfWVwAKCRBwMdsubs4+SAqpAQDNMTOaxlC8aGJ3aALApeCsr3wH3GcPAs+SkVaA0SdOUAEA3tuBKgNuI3zPZlN3GuBJhc6suyRwUuve8YaAkmD6NgI==wXph-----ENDPGP SIGNATURE-----
勝手ながら
// ==UserScript==// @nameはてな匿名ダイアリー特定ワード投稿非表示// @namespacehttp://tampermonkey.net/// @version 0.2// @description 本文に「dorawii」または「megalodon」が含まれる投稿を非表示にする// @matchhttps://anond.hatelabo.jp/*// @grant none// ==/UserScript==(function() { 'use strict';const POST_SELECTOR = '.body .section'; //非表示にしたいキーワードの配列constKEYWORDS = ['dorawii','megalodon','抽象数学','動画にしてみた','れめくん','自己放尿'];const posts = document.querySelectorAll(POST_SELECTOR); posts.forEach(post => {const textContent = post.textContent || post.innerText; // いずれかのキーワードが含まれているかチェック if (KEYWORDS.some(keyword => textContent.includes(keyword))) { post.style.display = 'none'; } });})();
anond:20251114170150 と連動させることを意図しています。
掛け算の概念(倍数を扱う)
小数的な考え方の萌芽
円周率(近似値として3.16)
20進法の完成された記数法
公理を置いて、そこから論理的に定理を導く証明中心の純粋数学の発展
当時、「すべての量は整数比で表せる」(万物は数である)と信じられていた。
しかし √2 が有理数ではない(整数の比で表せない)ことが分かり、この哲学が崩壊。
『直角二等辺三角形の対角線の長さ』が整数比で表せないことを証明したとされる。
証明したのは学派の弟子 ヒッパソスとされ、伝承ではこの発見により処罰されたとも言われるほどの衝撃。
アルキメデスによる面積・体積の“求積法”の発達。
負数を“数として扱った”最古の事例『九章算術』
十進位取り記数法
負数の萌芽的扱い
独自に代数学(al-jabr)を発明。文章による代数。ここで初めて“代数学”が独立した数学分野となる。
商、余り、桁処理などの方法が整理(現代の学校で習う割り算の形がほぼできあがる)
xに相当する未知数記号を使用した代数(文字ではなく語句の略号)
sinx,cosx,tanx などの三角関数の無限級数展開を発見。
これは数学史上きわめて重要な成果で、近代的な無限級数の起源はインドである と言われる。
● 1500年〜
負数の受容が進む。
● 1545年頃(カルダノ)
虚数の登場。
三次方程式の解を求める過程で √−1 に相当する量が突然登場。
しかしカルダノ自身は「意味不明の数」とし、虚数が数学的対象であるとは認めていなかった。
● 1557年頃(レコード)
等号記号「=」を発明。等価を等式として“視覚的に書く”文化が誕生。
● 1572年頃(ボンベッリ)
カルダノの式の中に出る「意味不明の数」を整理し、虚数を使って正しい実数解が出ることを示した。
● 1585年頃(ステヴィン)
● 1591年頃(ヴィエト)
● 1614年頃(ネイピア)
● 1637年頃(デカルト)
今日では当たり前の「座標平面」「方程式で曲線を表す」が、ここで生まれた。
物理現象をy=f(x)で表すという現代の方法は、すべてデカルトから始まった。
大数の法則(試行回数を増やすと平均が安定する法則)を初めて証明
● 1748年頃(オイラー)
√−1 を i と書く記法を導入。
オイラーの公式「e^{ix} =cos x + isin x」を提示し、虚数を解析学に自然に組み込んだ。
微積分の計算技法の体系化(積分論・無限級数・微分方程式の基礎を構築)
多くの記号体系(e,π,sin,cos,fなど)を整理・普及
グラフ理論(もの[頂点]と、それらを結ぶ関係[辺]を使って、複雑な構造やつながりを数学的に研究する分野)の誕生
ーーーーーーーー
一旦ここまで。
続きは詳しい人にまかせた。
台湾を完全に中国北京政府の支配下に置くようなことのためにどういう手段を使うか。(中略)それが戦艦を使って、そして武力の行使も伴うものであれば、これはどう考えても存立危機事態になり得るケースであると私は考えます。
という文章を読めば、誰だって「中国北京政府が台湾に武力行使したら」という話だって解釈するよね。
もちろん「普通に読めばそう解釈されるけど、それは日本政府の従来の見解とは異なるので、つまり高市は言葉足らずの失言をしたんだな」っていうところまで考えてるわけだけど。
価格は調べたり当時から改定されていて記憶だったりいい加減です
280blocker (¥900 / 年) → AdGuard (¥4000円? / 年) → NextDNS (¥2,500 / 年) → ControlD ($40 / 年) → blocky
280blocker は企業に買われてからなんとなく使うのをやめてしまった
NextDNS は日本系のフィルタが弱く更新頻度も低い印象だったのでやめた
ControlD はよかったけどちょっと高かったのでやめた
今はVPS に blockyデプロイして家族で共有している。blocky はAdAway記法のフィルタは使えないけどおおむね満足している。AdGuardHome を使用していた時期もあったが、重くて常用できなかった
1Password ($59? / 年) →iCloud+ (¥150 / 月) → Vaultwarden
iCloud+ は家族との共有ができないため不便が多くなり代替を検討
今はVPS に Vaultwardenデプロイして家族で共有している。今のところ満足している
ChatGPT ($20 / 月) → Gemini、Claude
ChatGPT は出始めは未来を感じ課金してガンガン使っていたが、GPT-4 の出来がいまいちに感じて他に乗り換えた
日常のあれこれは Gemini を使い、コード関係は Claude のほうがいい感じの答えが返ってくるので使い分けている
GooglePhoto (¥3500 / 年) → おもいでばこ → SynologyNAS
GooglePhoto無料時代に膨大な写真を放り込んでしまったため、有料化が発表されてから脱出するまでに時間がかかった
継続課金は嫌だったのでバッファローのおもいでばこを買ったが、アップロードした写真の日付がなぜか認識されないことが多く使い物にならなかった
SynologyNAS についている SynologyPhotos はそんなことはなく今はこれを使用
Immich とかに乗り換えてもいいかと思うこともあるが、サポート (モバイルアプリなど) の面も考えるとOSS に全部まかせるのも怖いなと思ってそのまま
Apple Music →Spotify →YouTubeMusic (YouTube Premium)
Apple Music がアーティストへの分配金が多いと聞いたためそれを使っていたが、Apple に端末代も出してサブスクでも課金してと金払いすぎではと冷静になり乗り換えを検討
Spotify に乗り換えたが、数年使っても新しい体験がまったく感じられないので失望して解約
今はYouTube Premium に付帯しているYouTubeMusic を使っている。UX は過去使ってきたサービスの中でも最悪だと感じるが、音楽サブスクに金払うよりかは一回でもライブに行ったほうがいいかと割り切っている
Fastmail → NameCheap Private Email →mioセーフティメール
Fastmail は使いやすかったのだが、価格がちょっと負担になってしまい解約
NameCheap は買ってたドメインの管理してたついでに安かったので契約していたが、ドメインのトランスファーに伴い解約
mio セーフティメールは機能はスマートフォンへのプッシュとかは無く必要最低限って感じだけど、よく考えたらプッシュ来てもうざいだけだし値段なりのサービスかなと満足している
住信SBIネット銀行プラチナデビット (¥11,000 / 年) → 解約のみ
メインバンクだったこともあり、数年前からモバイル端末保険目当てでついでに加入していた
d NEOBANK になってしまいスマートプラグラムの改悪も発表され、見切りをつけてメインバンクを切り替え、それに伴い解約した
モバイル端末保険は結局一度も使わなかったのだが、これに関して代替が見つかっていないためどうしようかと考えているところ
(年間一万円程度なら、昨今のスマートフォン価格を考えると十年に一回程度の利用でも元が取れそうなため)
Zaim →家族で銀行口座残高を共有したいニーズがあり (支出を家族デビットカードにまとめているため)、手軽かつ安くあげられるサービスが他に見つからない。Zaim自体はもう創業者の方が関わっていないらしく、プロダクトとして今後新しい驚きはなさそうなのでできれば課金したくない気持ちがあるのだが
U-NEXT →映像サブスクは大人の暇つぶしだったり子供のテレビ需要だったりで無いと困る場面が多い。y.umobile契約がありポイントで最新作もみられるので他は契約せずこれにしている
後半価格書くの面倒になった
昔よりは支出減らせてるかな
友達と遊戯王の話をしていた時のことを取り留めもなく書いておく
あくまでも素人の勝手な考察ということでオフィシャルな意見でも文献資料に基づくものでもない
俺の結論としては、遊戯王はデジタルカードとしての側面が最初からあったために一般的なTCGとは隔絶していたんだろうってこと
まず遊戯王ってルールが複雑だと言われるけど、そのおおもとの原因は他TCGが採用していることの多い総合ルールを持たないことにある
総合ルールはいってしまえば全てのルールの下敷きに当たるものであり、ここに書いてある定義や用語、記法に従ってカードは作られる
時に総合ルールでは判断が難しい状況というのはフロアルールなどで解決するし、非常に難解なテキスト同士の処理はジャッジや公式が裁定を出す
この裁定が間違っているかどうかも総合ルールに照らして考える必要があって、総合ルールが裁定に合わせて改訂されることだってある
そういうのが一般TCGのやり方ではあると思うけど、遊戯王は総合ルールという公のルールを持たず、代わりに裁定でカードの挙動を示している
だからときに過去の裁定と符合しなかったりする場面が出てきたりする
この取り組みが良いかどうかは別として、どうしてこういうことができるのかって話
総合ルールを前提にした運用ってのはそもそもプレイヤーにルールの全貌が開示された状態と言っていい
例えば呪文を唱える手順については、場合によっては大変細かく総合ルールに記載されているが、こうするのは呪文の唱え方一つとっても統一した運用をすることで公平な競技ができるようにする意味がある
オレオレルールを通して勝手な処理をさせないようにするってことだ
こういうのはアナログなゲームであるTCGだからこそで、ボードゲームをルーツにしているから全員にルールが開示されていないとダメって思想が根底にあるんだろう
じゃあ遊戯王をみると、裁定という結果は開示されているがその理由や仕組みは明らかになっていない
これは罰則の基準はあってもその基準を誰がどうやって作っているか、どういう法律に基づいた罰なのか明らかにされていないのと大体似ている
総合ルールを持たないことが悪いとは言わないが、それは競技指向がそれほど強くないカードゲームや運営にやる気がない場合に多いとは思う
じゃあ競技性の塊のようなゲームで、コナミのいち柱である遊戯王が、総合ルールを持たない理由ってなんだろう
これって恐らく、遊戯王が元々デジタルカードゲームと並行していたからなんだと思う
当初の遊戯王OCGはゲームボーイから始まり、その付録あるいはメディアミックスの一つがOCGだった
コナミ自体はデジタルゲームの会社だから、紙のTCGという文化となじみがあまりない
つまり現在の遊戯王OCGの源流ってデジタルゲームの派生なんじゃないかな?
例えばマジック・ザ・ギャザリングはアリーナ以前にも多くのデジタルゲームがあったけど、当初は存在していなかったしMOとアリーナくらいしか実績がない
ポケカもデュエマも一応はデジタルカードゲームはあるんだけど、遊戯王に比べるとシリーズといてあまり確立していないし歴史もぶつ切りだ
遊戯王のように長い期間デジタルと紙が並行して作られていたTCGはあまりないように感じる
そこで思うのは、遊戯王はデジタルが核なので総合ルールというゲーム自体をオープンにするというやり方が合わなかったんじゃないかな?
例えばモンハンなどのデジタルゲームで様々なパラメータが開示されていたりダメージ判定などがされているが、それらの計算や基準となるものの正体まで開示されているわけではない
これはユーザーにとって必要な情報と開発運用にとって秘匿すべき情報が分けられているから
でもTCGは書いてあることが全てでありその情報をユーザーが自力で説いて計算することが求められる
なので総合ルールなど詳細で厳密なルールが必要なんだけど、デジタルゲームでそれをするのはゲームそのものの仕様を公開するのと同等だよね
それってデジタルとアナログが混在していた遊戯王では色々問題があったんじゃないんかな
元々が紙のゲームで総合ルールでしっかり定義づけられているか、あるいはシャドバのようにデジタルと紙が分離されているなら別だけど、遊戯王はデジタルと紙がずっと平行しつつアニメもやっていた
なので恐らくだけどデジタルと紙の細かな仕様が完全には一緒ではなく、総合ルールという形に置き換えることが困難だったのかもしれない
デジタルの挙動をアナログゲームに置き換えるには相当時間と労力もかかるから、結果だけをあわせるため、裁定が豊富になったんじゃないかな
functionを使おうがアロー記法を使おうが大した違いはないし、typeでもinterfaceでもほぼ交換可能だ(もちろん厳密には意味が違うが必要な場合だけ考えればいい)。
人間が書いていた時代ではどちらを使うか迷わないといったメリットがあったかもしれないが、AIにはそんな迷いは存在しない。
むしろAIが書いたコードが統一されていないコードを修正するコストの方が大きい。
であるならば最初から「どっちでもいい」コーディング規約にし、AIのしたいようにさせればいい。
もう少ししたら自動ブクマするコードができそうなんだけど、そのうえでコード公開に便利なように事前にpre記法に囲まれた部分はその外部の文字を適切にエスケープするコードをchatgptに指示して作ってもらった。
ぶっちゃけなんでこれで動くのかはわからないので動くからゴーサインを出したというだけなのが情けない所。flushってなんだ?
使うときはchatgptにこのコード丸ごと書いて「ブックマークレット用に一行にして」と丸投げするのを要推奨。
https://anond.hatelabo.jp/20240820150546#
javascript:(function () {
function escapeHtml(text) {
returntext.replace(/&/g, '&')
.replace(/</g, '<')
.replace(/>/g, '>')
.replace(/"/g, '"')
.replace(/'/g, ''');
}
vartextarea = document.querySelector('textarea#text-body');
if (!textarea) return;
varlines =textarea.value.split(/\r?\n/);
varout = "";
var inPre =false;
var preLines = [];
function flushPre() {
// pre範囲の中身を 1 本の文字列にまとめ、\n→<br>(末尾行は <br> なし)
varraw = preLines.join("\n"); // ここに物理改行は入るが…
var escaped = escapeHtml(raw); // 先にエスケープ
varhtml = escaped.replace(/\n/g, "<br>"); //物理改行を <br> に置換(末尾に \n が無ければ末尾 <br> は付かない)
out +=html; //out には改行を入れない
preLines = [];
}
for (var i = 0; i <lines.length; i++) {
varline =lines[i];
// >> / << だけの行は常にそのまま出力(pre 内に来るケースは想定外だが、念のため pre を閉じてから出力)
if (/^\s*(>>|<<)\s*$/.test(line)) {
if (inPre) {
flushPre();
inPre =false;
out += "</pre>";
if (i <lines.length - 1)out += "\n"; // </pre>\n(次に続きがあるときだけ)
}
out +=line;
if (i <lines.length - 1)out += "\n";
continue;
}
// >| 行 → <pre>(直後に改行を入れない)
if (/^\s*\>\|\s*$/.test(line)) {
if (inPre) { //ネストは想定しないが、防御的に閉じる
flushPre();
inPre =false;
out += "</pre>";
if (i <lines.length - 1)out += "\n";
}
out += "<pre>";
inPre =true;
preLines = [];
continue;
}
// |< 行 → </pre>(直前に改行を入れない)
if (/^\s*\|\<\s*$/.test(line)) {
if (inPre) {
flushPre();
inPre =false;
}
out += "</pre>";
if (i <lines.length - 1)out += "\n"; //連続ブロック時は </pre>\n<pre> になる
continue;
}
if (inPre) {
// pre 内はバッファに貯める(ここでは改行を出力しない)
preLines.push(line);
} else {
// pre 外は escapeHtml + 行末にだけ改行
out += escapeHtml(line);
if (i <lines.length - 1)out += "\n";
}
}
// 未閉じの pre が残っていたら閉じる
if (inPre) {
flushPre();
out += "</pre>";
}
textarea.value =out;
})();
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250819202540# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaKRfOwAKCRBwMdsubs4+SI5UAQDcNiyv5qUuMej1VLkGz4F5WyHeU1AIm7nUVHlx/gicnAEAgP07dK14IuTuW3ZO7PRR71ENq9lJjYtawIYyMOc2cQk==okE4-----ENDPGP SIGNATURE-----
Q.
無限ループはfor(;;)でもwhile(true)でもいいですよね?でも職場ではわかりづらいから統一しろと言われました。white(true)が無限ループだとわからないアホの意見ですよね?
A.
ご質問の通り、「for(;;)」も「while(true)」も、どちらも一般的なプログラミング言語(C,C++,Java,Pythonなど)で無限ループを表現する手法として正しく使えます。どちらを使っても問題ありません。職場で「統一しろ」と言われた理由は可読性・保守性のためで、多くのプロジェクトではメンバー全員がすぐに意味を理解できるよう、記法を揃えています。たとえばC言語では「for(;;)」のほうが世界中のC言語プログラマが無限ループと認識しやすいという意見もあります。一方、「while(true)」はより多くの言語で利用できて、安定した書き方でもあるため、最近はwhile派が多い傾向です。「while(true)」や「for(;;)」が無限ループだと分からない人は、少なくともプログラミングの基礎が分かっていない状態とは言えます。しかし、チームで使うコードは全員が一目で分かる記法を選ぶのが定石なので、職場のルールとして統一するのは「無意味」ではなく、むしろ合理的な理由です。煽る必要もありません。要点まとめ「for(;;)」「while(true)」どちらも無限ループとして正しい。職場で統一を求めるのは可読性や保守性のため、合理的。どちらも分からない人は基本を学ぶべきですが、現場ではルールを優先すべきです。
わかった気にさせる本が悪いとは言わないが、自分はもっと厳密に分かりたいと思っていて、それで数学書を読むんだけど、こっちはこっちで「難しい議論をしている割に言葉足らず過ぎて分かりようがない」本になっているものが多すぎて、どないしろっちゅーねんって思いになる。
中学では十分証明問題になるような命題が、なんの説明もなくこれこれが成り立つ、だから~という調子でフォローなく証明が続けられるのを見てきた。
それが許されるのなら中学生は「~相似であることを証明せよ」という問題に対して「相似が成り立つからだ」とだけ書けば正解答案として成立してしまうことになる。
思うに証明にはいかにも証明らしい言い回しや言葉以外使ってはいけないかのような暗黙の了解もあるように感じる。
その割には術語を定義したときのその概念の説明には割と自由度を持たせている傾向が見られる。
その概念が関わる具体例を使って概念の目的を丁寧に説明していることも多い。
また証明といっても対角論法の証明は初めて見る人間へのそのとっつにくさがさすがに自覚されるのかなぜ証明が成り立つのか表なりを書いてイメージの力の存分に援用するもうちょっとカジュアルな内容になっていることがある例外もある。
しかしほとんどの場合そういった態度が証明(モード)では見られない。さらっと済まされてしまう。
計算問題では途中式の前後でも自由につまづきやすいポイントを解説した文章が挟まれたりするが、証明問題の解説は模範解答でもって代えていた記憶がある。
つまり模範解答の文章が難しく感じる人にとってはもうその解答を暗記するしかない。論語の丸暗記みたいなもの。
そのままテストとかで通用するようにそういうような解答になっているのだろうか。
数学書も論文として書いて格好悪くないものを、なんていう数学の本質ではないことに配慮して「真似るべきもの」としてそういうスタイルで証明を記述しているのではないかと思える。
であるなら、証明全体が一番目の文、二番目の文…というふうに出来ていたとして「(一番目の文)と書けるのはこれこれがこのような理由で成り立っているからです。しっくりこない人のためにこの理由をさらに掘り下げると~のようになっています。よって(数式)を証明の最初に書くことになります。次に~なのでこの式が二番目に来ることになります~」という解説ではダメなのだろうか?
またこの解説はそのまま証明の一つの形にもなってないのだろうか?
そもそも証明とは万人にその事実が成り立つことを理解できるような形で書かれたものを言う。
一部の人にとって意味も分からず丸暗記するしかないようなものはもはや証明の本来の目的を満たしていない。
オーソドックスな証明を構成する文の全てが含まれてさえいるなら、それの言わんとすることをさらにわかりやすく説明した肉付けの部分が加わった上記のような形の解説も証明の一つの形としていいのではないか。
それをしていいという感覚がないことが世の中の数学書の証明が言葉足らずになっている一因になっているのではないか。
もしそれが蛇足で証明全体の厳密性を損ねるというのなら、コメントアウトのような記法を使えばいいと思う。
//これの言わんとするところは~
とか、必要に応じて
式//<は~
みたいな書き方をするとか。二番目の例はサクラエディタで一文が続いているときに折り返しで便宜上改行されていることを示す記法を参考にした。
証明が長くなりすぎてその始まりと終わりが分からなくなるという懸念については既に証明の行頭のさらに横の余白に記号をつけて開始や終了を示すようにした数学書は存在するのでそれを他の数学書も参考にすればいい。
そもそも自然言語で書いている時点で完全な厳密性は諦めているわけなので、厳密だなんだと言うのはよりわかりよく書くことに対する言い訳にはならないと思う。
かといって従来の証明の構成要素を押さえた書き方なのであれば、それは一般書籍にあるような「わかったつもりにさせる文章」というのとも一線を画す。
数学の証明を完全に厳密に書こうとするとブルバキの数学原論やラッセルのプリンピキアマセマティカみたいになってしまい、後者は数学者には読む価値の無い本とされているし、前者にしても30年以上かけて刊行し続けて今だ数学の興味ある話題には到達できていないということになっているということから、数学書は省略するということが好まれるらしい。
でも既に数学基礎論レベルの厳密さを求めてはいない一般的な数学書の証明レベルの厳密さにわかるやすさという要素を足し合わせたところで、原論並みに極端に嵩が増すということにはならないと思う。
自分で考えないとその概念とかが身につかないから省略しているという反論に対しては、逐一圧倒的な量の具体例を持ち出すことで十分に補えるのではないかと思える(それでもメリハリをつければ原論ほどのボリュームにはならない)。
数学書は本当にチンプンカンプンな状態の本も多いので、考える力を身に着けさせるとか以前に、もっと理解できるような教えを工夫することに焦点を当てるべき。
考える力だろうがなんだろうが、そもそも書いてあることがわかんないってような構成の本ではしょうがないと思う。
コストがかかる割に日本語というローカライズされた市場で本が少しでも分厚くなるようなことはコストが回収できなくなるから避けたいという考えもあるのだろうが、それこそよほどの天才じゃなければはっきり言語化しないだけで私のような考えをしたことがある人はむしろ大半を占めていると思うし、比較的私の考えと同じ考えを持っていそうな裳華房の手を動かして学ぶシリーズがその出版社内のランキング上位を占めていた。
言葉足らずな数学書がまだまだ多い状況ではむしろどこぞのwebデザインの本のように何万部と売れるチャンスがごろごろ転がっているんじゃないかな。
わかりやすい解説が証明の一つの形として通用するようになれば、中高での試験答案においても純粋数学の論文でもそういう文章を証明として書いていいことになるのだから、参考書や数学書の証明部分も丸暗記するしかないようなわかりにくいものではなくなると思う。
https://id.fnshr.info/2017/12/10/polite-proof/
というジョーク記事があるけど、挨拶から書くとかは全く数学的な主張の分かりやすさにはつながらないから意味がないとしても(とはいえ親しみやすさもわかりやすさにつながることを完全否定もできないんだけど)根っこの部分ではもしかすると書き手は私と同じ問題意識を持っていたのではないかと感じさせる。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250804185908# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaJCEcQAKCRBwMdsubs4+SCv6APwPYZCxOIzijneKHMK5c+nrqS0YImv/gOsxm5/ERhIiXAD9EtAaFU6CTO3DUJ81tuHO6vv/pHwbom0ytd9gthgsPwU==6OiQ-----ENDPGP SIGNATURE-----
https://chatgpt.com/share/687e18a6-9c94-8003-9238-502a348ed325
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250721194029# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaH4ZIgAKCRBwMdsubs4+SLQDAP9V/P+J758HoL6lgDk5pC9Cd+bmfXgcPR40v91UKZe8ggEA45EjGvDPFV1wTFG4ydHIx7ctxkIAxZpLgAdQ/2Ii+wo==BXnc-----ENDPGP SIGNATURE-----
こんなん?(作るとは言ってない)