おんや 本が届かないぞ うむむむ

Amazonで買った中古本が到着予定日の本日に届かんのであった。そういう事は今までなかったで、あの中古本屋。
日本郵便が何かトラブルあったのかに?  いやー、山梨県から西東京までだからなあ。高速で直ぐって感じだしぃ・・・・・
ワタクシが買う中古本は価格が10円でも送料が350円とかの釣りみたいなものでして（笑）

素直に価格200円、送料100円といった感じで書けばいいのにさ。価格1円とかで釣ろうとするのだよ、・・・・ つーか、釣られているワタクシがおるおる。

まーたまにはこういうこともあるさ にんげんだもの 知らんけど。

1 + 1/2 + 1/3 + 1/4 + 1/5 + 延々と続くのですねえ やだねえ

右側に行くほど分母が大きくなって値は0に近づく。よってにこの和は収束するはずだ!!  と考えたのだが、収束しない。そこらは検索すると証明が出てくるから、ま～収束しないんですねえ、そうなんですねえ・・・
それはいいのだが収束しない = 発散する、場合に y = x^2 のようなグラフを考えると一気に膨大な数になるイメージがある。発散とは急激に増加する事だ!!  という先入観もあるで。
急激であろうがなかろうが増えていくのを止めないと発散するのである。ワタクシの預貯金も利息が0に近いのであるけれども微量に増えていく・・・1000年後には相当な額になるぞ。
生きてるかよバカタレ!!

てなわけで計算してみた。wxMaximaによる計算とグラフ。10万まで。

グラフをもっと右側まで描くと・・・ 100兆ぐらいまで描くとどうだろな（笑） 10万まで計算するのにDELL OPTIPLEX 7010SFF Win 11(非推奨PC) 22H2では30分ぐらいかかったぞ。
100兆まで計算すると日が暮れる・・・どころか・・・地球もなくなっとるわ（笑）

wxMaximaは数式処理ソフトであり数値計算も可能だがインタープリタに属するツールであり計算は遅い。ここらは高速なC言語で計算してだな・・・100兆までやるか?   やらんわ。

で、グラフの傾向としては右に行くほどなだらかになるであろう。だが水平にはならないであろう。水平になるということは増加分がないということなので値として収束することになるが、屁理屈屋が収束しないと証明しているからな。
とはいうものの、収束しない・発散するという場合にもどのような傾向でもって増え続けるのかという興味は大事だで。屁理屈屋は発散することの証明は出来てもグラフをイメージするまではやっとらんだろうし（笑） まともな数学屋は初学のうちにやっとるわい。知らんけど。

実はこういうことを自分でやってみると分かることがいくつかある。やってみないとわからない。n を大きくすると著しく時間がかかる。これはやってみないとわからない。
高速化のためにC言語でプログラムを書いても100兆をどう扱うのか。int ではダメで、long intでもダメで、long long intなら扱えるか・・・ってな事も考える。
整数型で扱える最大値ってものがあるからなあ。
そこらも自分でやってみれば気づく。

こういう自分で考えてみて、やってみて・・・気づくという事が大事なんだ、学ぶという事はそういうことだ。教科書をなぞって入試問題が解けるようになればいいなんてのは金儲けの塾・予備校の講師の戯言だ、どーーや。知らんけど。

ちなみに屁理屈屋の証明では対数が出てくる。上のグラフを見て対数のグラフだと気づく奴は高校数学を覚えているわな。そして対数の微分は、つまり log(x)の微分は 1/x だったと思い出す。するとグラフの傾きは右に行くほど0に近づく。では、無限に右に行けば 1/x は0になるはずであり、そこではグラフは水平になるので増加はなくなる。よってに収束する!!  とワタクシは考えたのであるが、収束しないのだ。
ここに無限大とか無限小とかの難しさがある。無限小の増加分があるので収束しない・・・というのは そうかな ほんまかいな と思う。1/nでnを無限大にすれば値は 0 だ。
だが、収束しないのだ。証明はいくつかの方法があるようだ。

ところで 1/2 + 1/4 + 1/8 + 1/16 + 1/32 +….. というように分母が2のべき乗の場合には収束するのである。値は 1 に収束する。ずーーーと 右の項では 1/2^n でnを無限大にすると 0になるからねえ・・・と考える。

てなわけでして、∑(1/n)は収束しないが、∑(1/2^n)は収束する。まーなんというか、屁理屈屋はいろいろ考えるものだでや（笑）

屁理屈屋の無限大の極限が数学屋とか哲学屋なのであるとワタクシは捉えているのであるよ。

どーよ。(´・ω・`)

いやなんの むずかしあるよ C/C++言語とか そーなんだ

手元にあるCコンバイラ。Win11ではCL, MinGW, TDM-GCC, UbuntuではGNUの。正式名は死なんのである。
これらがまた面白い結果を出しやがる。（笑）
hello worldを出力する単純なプログラムでExeのサイズがべらぼうに違うのであった。
MinGW 約50kB
TDM gcc   約2500kB
Ubuntu gcc 約50kB     (Win VScode Terminal で bash 使える)

なんさ、これは?  TDM gccがデカすぎるじゃああん。VScode Terminalで。DELL OPTIPLEX 7010SFF Win 11(非推奨PC) 22H2 を使ってますの。

さらにワケワカランのが出た。∑(1/n)を計算。1 + 1/2 + 1/3 + 1/4 + …. 飽きるまで。
100億まで計算するのに、MinGW – 140 sec, TDM-GCC – 45sec, bash – 42sec って感じでしたね。
MinGWだけが遅すぎる、他の2つに比べて。ビルド時はコンパイル・オプション指定なし。

素数を求めるプログラムでは3つとも似たような時間だった。

うむむむ。ワケワカラン。コンパイラの違い、バージョンの違いでいろいろとあるものだな・・・・・と知った次第である。
今まで、プログラムは本の例題を出版社サイトからDLしてVScode使ってクリック・クリック楽しいな。extensionいろいろ入れたし。 Run Codeでビルド実行するし。それクリック・クリック。動いた、ヤタっ!!  よっしゃ 終わり・・・・・ で、身につくものはクリック能力だけ。
(´・ω・`) (´・ω・`) (´・ω・`)

ワタクシは経験なクリック教徒なのであるぞの（笑）

てなわけで実際にプログラムをいじると知らない事が次々と出て来やがりました次第である。ここらだな。地道に初歩的な所から基礎を築かねば(ウソ)

Pythonいじっていてこんなこと気づかんからな。たぶん。やっぱ、漢はC/C++だぜ!! (てきとー)

  職業プログラマじゃないし、テキトーにやるさ、うむうむ。