  |
はてなキーワード: 数値計算とは
去年の夏ごろから意識をし始めて、夏は1デーのインターンに行ったりしていた（選考があったところは全落したので）
1留かつ単位も残ってるのもあってこんな状態じゃ就職厳しいだろうなと半分パニックになってたら
結局ESも自己PRもまともに書けず、学校の方も留年は免れたけど4年にも3授業分単位が残ってるような状態になってた
3月に入ってからは、あらかじめ就活サイトの方で目星付けてた会社の説明会に行ってたりしたんだけど
満員だったり、行ってみたい説明会がバッティングしたり体調崩したりして結局週3ぐらいでしか動いてない
三週目あたりからはテストセンター行ったり無理やりひねり出して添削も受けてないようなES出したりしてた
それでも筆記で受けた所はパスしてたし、本当に読んでいるのか怪しいようなESも通ったりする
（まだ大きい企業は受けてないからかもしれないけど てか多分そう）
そしてこの1,2週間は面接をいくつか受けてきた
とにかく緊張で何も言葉が出てこなかった 慣れれば大丈夫 なんて言うけど多分自分は何回やっても無理そう
そもそも友達もいないしバイト以外では声も出さないような人間だから即興でなんか言えといわれても頭がフリーズしてなんにもでてこない
自分でも不十分なのがわかるESの粗を突かれるわけでもちろんしどろもどろの返答しかできない
付け焼刃でテストセンターのついでに志望分野に関連する資格を取ったけど（インターンで知ってはいたけど）なんの意味もない
このまま秋、冬までずるずると就活する自分が割とリアルに浮かんだ
しかも自分が死亡している業界が割とブラックなのもあって大企業にしがみつこうと思ったら6月までには決まってないと厳しいとも言われたのもあってパニックが炸裂している
ここまで文章を読んでもらった人にはわかって頂けると思うけど文章能力もなければキャパシティ、コミュニケーション能力もない
大学も指定校推薦で入った（めちゃくちゃ後悔してる 自分みたいに社交能力がない奴が入ると自力で解決できなくなるし受験の禊をしてない分打たれ弱いなって自分でも思う やめた方がいい）
さんざん就活の為に動く時間はあった けどバイトだったり授業だったり既に不利な立場にあるってところで真剣に向き合うのが怖かった 言い訳しかできない
一昨日、まともな会話にすらなってなかった面接の後に会社最寄り駅の桜を無になってみてたら涙が止まらなかった
桜を見て泣いている就活生っぽい人がいたら花粉症がさく裂しているだけなので宗教の勧誘とかは辞めてください
今日はweb系のところで未経験可、入社前から研修付の所を見たりして
ESに作成物のリンクがあったので大学の授業で作ったC++の簡単な数値計算のプログラミングを無理やりほぼやったことないjavascriptで書き直したりしてた 楽しい 大学情報系にすればよかった
どうなるのか メンタルがすり減り引きこもりorニートになるのか
わかり次第追記します
一応旧課程の数学Bには「数値計算とコンピュータ」と「統計とコンピューター」というのがあったんだけどね(この課程の事は良く知らないしざっくり見る限りではプログラミング教育としては微妙そうだ)
だからやっぱり数学の上に載せるのが王道なのかなとは思うけど、今でさえ数学はパッツンパッツンで行列を削る(代わりに複素数平面が入った)とは何ごとかっていう人居るしなあ。いっそ無機科学(今日本ではアルミの精錬はしてないわけだし)、有機科学を削るか生物あたりをスリム化するか⋯⋯とも思うんだけどそれはそれで批判が出そうだしな。
働き方改革推進を掲げているとある会社のある部署が、日平均労働時間の昨年比1時間削減と、平均退社時間の40分前倒しを達成した。
しかし、昨年からいた社員の激務状態はほとんど改善されていない。皆朝は8時には出社していて、22時くらいまでは居残っている。
ではどうやって数値を改善したかというと、実は「時短勤務社員」を何人か入れていたことが分かった。
9時出社、15時退社、残業ゼロの人を何人か採用して、ほっといても数値が改善できるようにしたのだ。
時短勤務社員の労働時間を会社全体の数値計算に組み入れることで、平均労働時間と平均退社時間の大幅改善を実現。
時短勤務社員に与えられる仕事は、書類印刷などの雑用が中心。時短なのでそれしか与えられない。居ないよりは良いが、という程度。
この会話ログはフィクションであり、実在の人物・地名・団体とは一切関係ありません。
坂木
わろた
坂木
自分が理解できないものを意味がないと思いこみたがるタイプの人だということがよく分かったので原文を読まずに済んだ。ありがたいまとめだ。
安原
NTPsec が，ownership を理解していない開発者たちの声が大きくなるようなコミュニティによって開発されているということが分かって大変有意義でした（こなみかん
宮森
今までCで開発してきたプロジェクトを移すなら極端な話ownershipを理解しなくても良いわけで、悪くないのではと思う。
宮森
……が、理解できないものに対して、理解を試みず～すべきだ～と設計しろ、っちゅう人が作るソフトとはちょっと関わりたくないと思う。
安原
いや，私は C で開発してきたプロジェクトであるならばなおさら ownership を理解していないといけないと思います． ownership に理解を示さないコミュニティが関わってきた一定規模以上の C によるプロジェクト……私の第一感は「こわ…近寄らんとこ…」です．
宮森
いや、Cで開発してきた人たちって、ownershipを自前でコントロールできると思っている（思い込んでいる）人たちですんで……こわちかは同意。
安原
いや，私は C で開発してきた人たちの多くは，そもそも ownership の概念を獲得していないのではないかと危惧しています．元々，私はもっと楽観的で，多くの C プログラマは ownership の概念を獲得していると思っていました．
宮森
安原
OpenSSL の騒動の時，関数の途中で return したことによるリソース漏れを揶揄したことがあります． OpenSSL のようなインターネットの基盤を支えるオープンソースプロジェクトにおいてさえ， ownership の概念を獲得していれば脊髄反射で気づくであろうバグが随所に見られたことには本当に絶望しました．
安原
藤堂
安原
むしろ C++ によって ownership という概念が明確になり，その重要性が認知されるようになったのではないでしょうか？ これについては，私は歴史的なことが分からないので真偽のほどは何とも言えませんが．
宮森
シニアな開発者にしかC++/Rustが受けないと思うの、まさにその点だと思っていて、人類を信頼したがために足どころか頭を吹き飛ばす経験を積んでいないからだろうなー、とか。
宮森
OSとかシステム系のプログラマの人々、基本的にリソースは人間が適切に管理するし管理できると考えている人が多い印象（[検閲削除]社時経験）。言語側で安全を確保したい、的な話をしても相容れなかった記憶が。
坂木
[検閲削除] のコードには、間違って自分の足どころか頭を撃ち抜いてしまった偉大な先人たちの知恵が詰まっていて、開発していてとても勉強になります。なお [検閲削除] は頭がなくなっていることに気づかずゾンビとして生きている模様。
今井
今井
リソースどうこう以前に、そもそもちゃんと構造化されてるコードが書けるかも怪しい(個人の感想です。見識にバイアスがかかっている可能性があります)
安原
うーん，数値計算系のチームやコミュニティも ownership の概念の獲得，重要性の理解，その管理を自動化することへの理解，これらを期待するのは難しいだろうなあ……．そもそも高度なリソース管理が必要になる場面少ないし……．
坂木
コードの品質が強く求められるプロジェクトとそうでもないプロジェクトがあるからなあ。クライアントサイドソフトウェアは割と品質が求められる気がする。
安原
OS 実装とかシステムプログラミングって，クライアントに直接接しないだけで，その上にクライアントサイドソフトウェアが載るわけで，コードの品質が強く求められると思うのですがそれは……．まあ， API とかで切り離されているので，そこだけしっかりしていれば，という話はあるか．
宮森
坂木
今井
あとは、デモが作れればいい、的なのも同じかなぁ。
宮森
宮森
安原
今井
まー、 offline で動くバッチ、的なのはそこまでメモリ管理とか / パフォーマンスとかにもシビアにならなくていいし(最悪オーダーがほどほどならよい、的な)、そいう文化にいると、雰囲気にのまれる人が多い、というのはまぁわかる。
坂木
今井
宮森
いろいろ言っていますがワタクシ、そういう管理が必要なプログラムは全く書けなくなりましたので今書くと死にます（プログラムと顧客の大事なデータが）
安原
しかし，システムプログラミング界隈に「人間はリソースを適切に管理できる」という悪しき信仰がはびこっているの，何か構造的な原因があったりするのかなあ？
宮森
システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
宮森
宮森
坂木
Linux カーネル、一体どうやったらあの規模のコードをクオリティコントロール出来るのか本当に不思議
安原
坂木
Linux カーネル、属人性高そうではあるけどそれでも実際に十分スケールしているからなあ…… ヤバい系レビュアーがごろごろしているのかな
宮森
安原
私も [検閲削除] のコミュニティを見てましたから，各々必要なドメインにおける圧倒的なタレント性を持った人たちが1ヶ所に集結して奇跡のアンサンブルを奏でうる場合がありうるのは理解しているんですが，本当にただの奇跡でしかないと思っています．
宮森
つーても機械エンジニアリングで町工場の職人芸を必要であれば使うように、属人性を求めるのも一個の正しい戦略だと思うんですよね。
宮森
なおその対極がみずh（省略されました
安原
Linux カーネルにおけるスケール云々は， Linux カーネルのコミュニティ自体におけるスケーラビリティではなくて，（システム）プログラミングコミュニティ全体（他のプロジェクト）へスケールするかどうかを言ったつもりでした．
坂木
宮森
C系がシステム系で優先されるの、ツールを変えるとツール独特の罠があるので、罠が全て分かっているツールを使う、っつうのもあるな。
安原
＞ システム系、基本的に生のハードウェアが透けて見える言語を使う必要があって、そのために選択肢がCしかなくて、手段が限られているからこそ信仰が発生した、という認識
これが原因だとすると，やはり Rust だ……Rust しかない……．ツール周りとか，まだまだ未整備な部分たくさんあるけれど……そこをクリアすれば……．
坂木
坂木
イテレータっていうか Java でいう Scanner を作ろうとしたんだっけ。サードパーティライブラリも探してみたけどその頃は I/O 周りの API が unstable でビルドが軒並み壊れていたりしたな……
藤堂
1.0 以前のことは忘れましょう (本当に unstable)
安原
坂木
安原
「Rust 経験者」という条件でプログラマを募集して，それで入ってきた人材に C を書かせればよいのでは！(ﾋﾟｺｰﾝ!
藤堂
犯罪ですよそれは
安原
はい．
藤堂
安原
まさにそれをイメージしていました．
宮森
藤堂
うーん、それ以降の話は知らず
今井
Rust そして誰もいなくなった、にならないかが一番心配だったりする
安原
それな
宮森
もしかして、NTPsecの人がRustでミニサーバーを起こすのにすら苦労していたの、普段からバグありのコードを生産しているからなのでは、という気がしてきた……。
（この辺で一同寝落ち）
プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか？
ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミングの本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。
そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。
最近になって、プログラミングの義務教育必修化の話題とか、コピペプログラマーの話題とかを目にするたびに、かつて自分がプログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。
だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。
ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生のときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ（文章を入力する専用マシン）が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分も小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気屋からはワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分はパソコンという存在に興味を抱くようになったのでした。
とはいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニーも独自にパソコンを作っているぞとか、そういう情報がパソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品の一種であり、ラジカセとかテレビと同列の存在でした。
なんでこんな話がプログラミングにつながるかというと、ひょっとして自分がプログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコンを電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。
ラジカセなら、CDだのテープだのを入れて再生ポタンを押せば、そのハードウェアの機能を物理的に体感できます。それに対してパソコンは、プログラミングをちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログの商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為とハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。
もし自分のスタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。
ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。
プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICのインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書や雑誌のコードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的に自分で目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して（まだインターネット検索は使い物にならなかった）適当にコードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。
この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思います。ちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚。プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンとサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります。
自分はバカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。
そんなこんなで、自分はまともにプログラミングを経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事でパソコンを日々使うようになってから徐々に変わっていきました。
具体的には、パソコンが、自分の中で「カタログの商品」から「武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。
武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上の課題を打開しました。それなりに計算機科学の教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。
結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間が必要だったことになります。自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子どもも少なくないんだろうなあ。それは不憫だなあ。
かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときにたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います。
オチがないので、このへんで。
円の面積は
半径×半径×円周率
で求めることができる。
半径2cmの円の面積を計算してみよう。
円周率は無理数なので、無限に桁があるから、数値計算をするときには筆算だけするというわけにはいかない。
よっていくつかの工夫を用いる。
a.)円周率π=3.1415926535…を用いて計算する。実際はできないが、できるとする。今回はエクセルのPI関数を用いて計算したもので代用した。これを真の値とよぶことにする。
b.)円周率を3.14として計算する。筆算などを行う。これを小学校計算とよぶことにする。
c.)円周率を有効数字3桁の概数3.14として計算する。bの計算結果を有効数字3桁の概数で表せばよい。これを概数計算とよぶことにする。
結果は以下のようになる。半径が2cmのとき、半径×半径は2×2=4である。
a.)4×3.1415926535…=12.56637061…
このときbとaの差は
12.56-12.56637061…=-0.00637061…
cとaの差は
となる。
概数計算の結果12.6よりも、小学校計算の結果12.56の方が真の値12.56637061…に近い。
今度は半径19cmの円の面積を計算してみよう。
a.)361×3.1415926535…=1134.114948…
今度は差をとらなくても、小学校計算の結果が概数計算の答えより真の値に近いことがわかるだろう。
エクセルで他の数についても調べてみよう。
| 自然数n | a.)πn | b.)3.14n | c.)有効数字3桁の概数 | d.)bとaの差 | e.)cとaの差 | f.)eとdの絶対値の差 |
| 1 | 3.141592654 | 3.14 | 3.14 | -0.001592654 | -0.001592654 | 0 |
| 2 | 6.283185307 | 6.28 | 6.28 | -0.003185307 | -0.003185307 | 0 |
| 3 | 9.424777961 | 9.42 | 9.42 | -0.004777961 | -0.004777961 | 0 |
| 4 | 12.56637061 | 12.56 | 12.6 | -0.006370614 | 0.033629386 | 0.027258771 |
| 5 | 15.70796327 | 15.7 | 15.7 | -0.007963268 | -0.007963268 | 1.77636E-15 |
| 6 | 18.84955592 | 18.84 | 18.8 | -0.009555922 | -0.049555922 | 0.04 |
| 7 | 21.99114858 | 21.98 | 22 | -0.011148575 | 0.008851425 | -0.00229715 |
| 8 | 25.13274123 | 25.12 | 25.1 | -0.012741229 | -0.032741229 | 0.02 |
| 9 | 28.27433388 | 28.26 | 28.3 | -0.014333882 | 0.025666118 | 0.011332235 |
| 10 | 31.41592654 | 31.4 | 31.4 | -0.015926536 | -0.015926536 | 3.55271E-15 |
| 11 | 34.55751919 | 34.54 | 34.5 | -0.017519189 | -0.057519189 | 0.04 |
| 12 | 37.69911184 | 37.68 | 37.7 | -0.019111843 | 0.000888157 | -0.018223686 |
| 13 | 40.8407045 | 40.82 | 40.8 | -0.020704497 | -0.040704497 | 0.02 |
| 14 | 43.98229715 | 43.96 | 44 | -0.02229715 | 0.01770285 | -0.004594301 |
| 15 | 47.1238898 | 47.1 | 47.1 | -0.023889804 | -0.023889804 | 0 |
| 16 | 50.26548246 | 50.24 | 50.2 | -0.025482457 | -0.065482457 | 0.04 |
| 17 | 53.40707511 | 53.38 | 53.4 | -0.027075111 | -0.007075111 | -0.02 |
| 18 | 56.54866776 | 56.52 | 56.5 | -0.028667765 | -0.048667765 | 0.02 |
| 19 | 59.69026042 | 59.66 | 59.7 | -0.030260418 | 0.009739582 | -0.020520836 |
| 20 | 62.83185307 | 62.8 | 62.8 | -0.031853072 | -0.031853072 | 7.10543E-15 |
| 21 | 65.97344573 | 65.94 | 65.9 | -0.033445725 | -0.073445725 | 0.04 |
| 22 | 69.11503838 | 69.08 | 69.1 | -0.035038379 | -0.015038379 | -0.02 |
| 23 | 72.25663103 | 72.22 | 72.2 | -0.036631033 | -0.056631033 | 0.02 |
| 24 | 75.39822369 | 75.36 | 75.4 | -0.038223686 | 0.001776314 | -0.036447372 |
| 25 | 78.53981634 | 78.5 | 78.5 | -0.03981634 | -0.03981634 | 0 |
| 26 | 81.68140899 | 81.64 | 81.6 | -0.041408993 | -0.081408993 | 0.04 |
| 27 | 84.82300165 | 84.78 | 84.8 | -0.043001647 | -0.023001647 | -0.02 |
| 28 | 87.9645943 | 87.92 | 87.9 | -0.044594301 | -0.064594301 | 0.02 |
| 29 | 91.10618695 | 91.06 | 91.1 | -0.046186954 | -0.006186954 | -0.04 |
| 30 | 94.24777961 | 94.2 | 94.2 | -0.047779608 | -0.047779608 | 0 |
| 115 | 361.2831552 | 361.1 | 361 | -0.183155163 | -0.283155163 | 0.1 |
| 116 | 364.4247478 | 364.24 | 364 | -0.184747816 | -0.424747816 | 0.24 |
| 117 | 367.5663405 | 367.38 | 367 | -0.18634047 | -0.56634047 | 0.38 |
| 118 | 370.7079331 | 370.52 | 371 | -0.187933124 | 0.292066876 | 0.104133753 |
| 119 | 373.8495258 | 373.66 | 374 | -0.189525777 | 0.150474223 | -0.039051554 |
| 120 | 376.9911184 | 376.8 | 377 | -0.191118431 | 0.008881569 | -0.182236862 |
| 121 | 380.1327111 | 379.94 | 380 | -0.192711084 | -0.132711084 | -0.06 |
| 122 | 383.2743037 | 383.08 | 383 | -0.194303738 | -0.274303738 | 0.08 |
| 123 | 386.4158964 | 386.22 | 386 | -0.195896392 | -0.415896392 | 0.22 |
| 124 | 389.557489 | 389.36 | 389 | -0.197489045 | -0.557489045 | 0.36 |
以上の表は
http://tetsu23.my.land.to/table.htm
を利用してコピペした。
=A2*PI()
=A2*3.14
=C2-B2
確かにn=121においては、概数計算の結果380の方が小学校計算の結果379.94よりも真の値380.1327111…に近い。
ところが次のn=122の場合では小学校計算の結果の方が概数計算の結果よりも真の値383.2743037…に近い。
表の右端の列でbとaの差、cとaの差の絶対値の大きさを比較をしている。すなわち、bとc２つの計算結果の真の値との距離の差をとっている。
よって、右端の列の値が正のときのnにおいて、小学校計算の方が概数計算より真の値に近い、精確な答えを出せることになる。
小学校計算の方が概数計算より精確な答えを出せるnとそうでないnは、どちらの方が多いだろうか？
概数と定数値を同一に扱って真の値との距離を比較しているからだ。
概数とは、ある点からの触れ幅を定義しているものであり、あるxの値がa≦x＜bにあるということを言っているに過ぎない。
すなわち、n=121において121πが有効数字3桁の概数で380というのは
であるということを言っているにすぎない。
したがって、筆算の末に半径11cmの円を「379.94です!」と笑顔で言った子どもがいるのなら、
ちゃんと範囲内におさまる値を計算できた事をほめてやらねばならない。
ならば同時に380も380.1327111も正解とせよというのは一理ある。
ただし、これは面積の値をある精確さで以って求めよという問題に答えた場合であって、121×3.14の筆算の結果を380とした子どもには計算が間違えっているとして×を与えなければならない。
まとめると、
「半径11cmの円の面積を380㎠とした方が380.1327111…㎠により近い値であるから、答えを379.94㎠とするのは誤りである」という議論はなりたたない。
有効数字3桁の概数で計算した379.94という結果は、上から4桁目、5桁目が信頼のおけない数字であるという状態のものであるだけで、値の精確さ、すなわち真の値との距離の近さ競うものではない(上の表をみよ）。
信頼のおけない部分を丸めた数値である380の方が、よりおおまかに信頼がおける数値だというだけである。
なおn=300あたりから計算結果が4桁になり、1の位がまるめられるので、概数と真の値の差はより大きく感じられるようになってしまう。
エクセルをおもちならやってみてほしい。
間違ってるところがあったらプリーズテルミー。
（乱流発生の法則を発見：１３０年以上の未解決問題にブレークスルー）
はてぶに書きたかったけれど、スペースが足りないから増田に書きたいこと書く。
乱流-層流相転移がDPのユニバーサリティクラスに属することを（実験で）示したのは、すごい。
プレスリリースには数理モデルの話も書いてあった（論文ではsupplementary informationにあった）けど、
DPをベースにした数理モデルを作ったらそりゃDPの臨界指数が出るのは自然な気がする。
理論屋としての興味は、ナビエストークス方程式の数値計算でも乱流-層流相転移が観測されるとして、
流体力学とDPが関連づく可能性があるという点かな。
ナビエストークスを何かしらの操作で繰り込むとDPになるのか？
はてぶに「すごい」「いろいろ波及しそう」とか書いてる人、早合点しなさんな。
あなた方が想像している応用面よりもっとFundamentalなところで意味があるんですよ。
理由くらい書けよ糞が
他のWindowsプログラムがやっていて、多くの方が「できて当然」だと思っていることは、7割くらいであれば.NET(フレームワーク名)を叩けばできます。
.NET対応言語はC#、VB.NET、J#、F#、JScript.NET、C++/CLIなどがあり、実際の開発においてはこれらの中から自分に合った言語を選ぶことになります。
個人的な感想ですが、この中で最もゆとり仕様なのはC#です。StackOverflowなどのノウハウが一番蓄積されているのもC#だと思います。
「頻繁なアップデートを追跡しないといけない」「Visual Studioが必要」という問題はありますが、がんばってください
なお、.NETはメモリを食うので、数値計算みたいなことをしたいのであればC++が現状一番まともだと思います。がんばってください
昔のMacのプログラムのGUIはCarbonというライブラリで作っていました。今はCocoaというライブラリで作っています。
残念なことに、どちらも言語はObjective-Cです。がんばってください
ブラウザアプリは、ユーザのWebブラウザ(Chrome、Firefox、Opera、Safariなど)上で動作するシステムと、遠隔のサーバ上で動作するシステムが連携して成立します。
従って、ブラウザアプリを作る言語は、サーバ用言語とクライアント用言語の2種類を考えなければなりません。めんどくさいですね。
ひとたびそのめんどくささを突破してしまえば、Webブラウザさえあればどこでも動くようになります。素晴らしいですね。
クライアント用の言語は、まぁ、JavaScriptしかないと思います。がんばってください
JavaScriptも(正直なところ)あまり褒められた言語ではないので、近頃ではもうちょっとまともな言語を作って、それをJavaScriptに変換する方法が取られたりします。CoffeeScript、TypeScript、Haxeとかですかね。がんばってください
JScriptとかいう、名前が紛らわしい上にゴミブラウザ上でしか動かないゴミ未満言語もありますけど、そんなもんで作っても私の環境では動かせませんので悪く思わないでください。
そもそも選択肢が全くありませんので仕方がないです。がんばってください
Xamarinがあるじゃないかって？まぁそういうのもあるかもしれませんね。がんばってください
私の勉強不足で、Java以外の選択肢は知らないです。Java以外にあるんですかね？
Perlは使い捨てスクリプトを作るのに適しています。CPANクライアントは昔から安定して動きません。だいぶオワコン化してます。がんばってください 私は鞍替えしました
PythonはPerlより見た目がすっきりしたPerlです。easy_install・pipはすごく安定していてびっくりします(Windows除く)。3系とかいう邪念は捨てて2系教の悟りを開きましょう。がんばってください
RubyはPerl(の処理系のソースコード)より(処理系のソースコードが)綺麗なPerlです。私の手元のUbuntuで「ruby」と入力すると「Command not found.」と返ってくることからも解るとおり、多くの*NIXではOS標準でインストールされておりません。昔のgemは何故あんなにすごい時間をかけてrdocを作っていたのでしょうか。日本人が作ったのでムラ意識の強い日本人の仲間が大勢います。他の国は知りません。がんばってください
これ以上言語を増やすのはやめましょう。バベルの塔で大勢の人間が不幸になったのに、それを人間が自ら引き起こしてどうするんですか。
言語処理系を作るのであれば、BNFという言語で文法を定義して、yacc・bisonというツールに食わせればひな形ができます。ぶら下がりelseとの格闘が待ってますが、がんばってください
1からOSを作った方もいますが、デバイスドライバの流用などを考えると、だいたいはLinuxやBSDのソースコードを改変するお仕事だと思います。
昔はCGIと言っていました。所詮は80番ポートでlistenするだけのプログラムであり、BSDソケットをlistenできるライブラリを有する言語であれば何でもいいのですが、いくつかの宗教があります。
PHPはバンドネオンと同じくらい習得が困難な言語なのに、宣伝の仕方を間違えたために「自分はできる」と勘違いしたプログラマが暴徒と化し、イスラム教と同じくらい不当に低く評価されている言語です。きちんと勉強して使う分には、悪くない選択肢だと思います。がんばってください
Javaは、Eclipse・Netbeansといった超重量級IDEを起動して、Java EEやSpringといった超重量級ライブラリに依存したwarを、Jboss・WebSphereなどの超重量級アプリケーションサーバ上で動作させるため、メモリが貧弱な環境ではIDEとサーバを同時に起動すらできません。サーバのメモリが潤沢であれば悪くない選択肢だと思います。がんばってください
C#は、選択肢が全くないことを除けば、状況はJavaとあまり変わりません。Microsoftがお好きな方、何かの間違いでWindowsサーバを使わざるを得ない方であれば、悪くない選択肢だと思います。がんばってください
Goはよくわからないですがきっといい言語です。がんばってください
なんか「金融でHaskell使われてる」って聞いた！金融！数字の計算！数値計算だ！！！お金の計算だから厳密だ！！！
くらいの中学生的なノリを感じるんだよ。
いくつかまとめて反論したい
まず最初に言っておきたいけれども、僕自身はHaskellが大好きな関数型言語大好き人間である、ということを先に述べておきたい、それを踏まえた上で以下をお読みいただきたい
最初の「オブジェクト指向 v.s. 関数型プログラミング」や「ふたつのアプローチの比較」はまあ問題ないかなぁという感じ、問題があれば他の誰かに任せます
問題は「関数型プログラミングの利点」と「関数型プログラミングの得意分野はなにか」
まず「関数型プログラミングの利点」だけれども、ファンクタが云々、モナドが云々、これは「関数型言語の話」ではなく「Haskellの話」である
そこを引いてあくまでHaskellの話だと割りきって見たとしても、「たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて」？ モナドはそんな限定的用途のものではないし、パーサの理解とは無関係だ(単にライブラリの設計の問題)。それにApplicativeスタイルのほうがパーサが書きやすいという人もいるだろう、パーサの理解にモナドの知識はあまり関係がないと言っても差し支えないのではないか
「書きやすい」に関してはこれはもう「主観の問題だよね」以上の言い様がない、僕自身はC++とHaskellの両方を書く人間で、確かにC++Hakellの方が「短く書ける」と「感じる」ことは多い、がしかしそれはあくまで個人の主観であり、更にはなにか明確な基準を取ったとして、やはりこれは「関数型言語」ではなく「Haskell」の話である、わかりやすく言えば「関数型言語であるLispを僕は読み書きできない」、特定言語の、主観に大きく左右される特徴を関数型言語一般の話であるかのように敷衍して話すのは感心できない
「静的型付け」云々もこれはもう完全にHaskellやOCamlの話である、LispやErlangとは何だったのか
多くの数値計算アルゴリズムは逐次的に定義されている、関数型言語で扱いやすいものではない、簡単にいえば「それFortranの前でも言えるの？」である
遅延評価はこれまたHaskellの特徴であり関数型言語一般の特徴ではないし、別に他の非関数型言語でエミュレートできないものでもない、更に言えばこれが何か数値計算に対して有利な何かをもたらすかといえばそういうわけでもない
「分数や虚数が扱えます」、に至ってはむしろ近頃の言語で扱えない言語何かあるんですか、である、大抵の言語にはその手のライブラリはある、関数型言語に限った話ではない
お前それShellやPerl、RubyやPythonの前でも言えるの？
この手の話は「ライブラリ」の話になり、言語パラダイムにより議論されるべき問題ではない、もちろん自動並列化などの問題で数学モデルに基づいていることが多いHaskellなどは有利かもしれない、が、やはりそれは特定言語や特定のライブラリの話になり、関数型言語一般の話ではない、並行処理の扱いにくい関数型言語の設計など容易だろう
言語の話でも言語パラダイムの話でもライブラリの話でもない、個人の技量の話だろう、関数型言語でも下手にしか書けない人は上手には書けない
GUIライブラリの設計にもよるけど、GUIってOOPの強い分野だと認識していたのだけれど、さてはて
最後に要点をまとめると
金融で使われてるのはデリバティブの合成が記述しやすいからだろうが。
数値計算が得意とか言うならゲーム機でも動く高速・高効率なGIレンダラとか流体シミュレータとかの実用的な実装が可能になってから言えカス。
近年、関数型プログラミングの重要性はいろんなところで叫ばれています。
Javaの最新バージョンに関数型プログラミングに関する新機能が加わりました。
Rubyも昨今、関数型プログラミングへのサポートが手厚くなってきています。
プログラミングの教科書の大手、オライリー社から、Javascriptで関数型プログラミングを行うための解説書が発行されました。
関数型プログラミングへの注目度は高まってきています。
おそらく、みなさんは既にオブジェクト指向が何か、を知っています。
でも関数型プログラミングとは何か、胸を張って語れる人は、周りに見当たらないかと思います。
実際、オブジェクト指向によってプログラミングする方法は、わかりやすい解説があちこちにある一方で、
関数型プログラミングとは何か、何が良いのか、ということについての、よいまとめは見つけることはできませんでした。
この記事を読む方の中で、「関数型プログラミングを取り入れるか・取り入れないか」で切実に悩んでいる人は、おそらくいないでしょう。
この記事はあまり細かいところに立ち入りません。関数型プログラミングを使う側の立場に立って、利点や向き・不向き、それが導くスタイルを書きました。
みなさんは鳥のように飛んで、高い空から、関数型プログラミングとは何か、何が良いのか、を見渡してください。
オブジェクト指向的アプローチは、名前をつけてプログラムを整理する。
関数型プログラミング的アプローチは、汎用部品でなんとかする。
Googleが近年リリースした言語、Goには、”継承”を直接サポートする仕組みが無いことが話題になりました。
また、Mac OSXの基幹ライブラリCore Foundationは、ライブラリ自体はC言語で書かれているにもかかわらず、その設計方針は明確にオブジェクト指向です。
その本質とは"名前をつけて対象を識別し、それを扱うこと"、にあります。
最もプリミティブなオブジェクト指向の対象は、ファイルハンドラです。あるファイルを開いて、読み込んで、あるいは書き込んで、ファイルを閉じる。
これらの処理をまとめたら、わかりやすいですよね？
対象に関する処理を、対象の周りにまとめる。これがオブジェクト指向の基礎的な理念です。
識別することとイコールで比較できることは、とても良く似ています。
イコールによる比較は、オブジェクト指向では鬼門であることが知られています。
PointクラスのインスタンスとColoredPointクラスのイコール演算をどう決めればいいかに、正解はありません(詳しくは"effective java"をご参照ください)。
また名前をつけて識別する対象は、フワフワしていてはいけません。
たとえば、"軍人の階級"をオブジェクトにしたとしましょう。"大佐"クラスのある兵士は名前のフィールドや、性別のフィールドを持っているでしょう。
ところで彼が昇格したときに何が起こるでしょうか。
新たに"少将"クラスのインスタンスが作られます。"大佐"クラスを破棄する前に、名前、性別、その他沢山のデータを引き継がなくてはいけません。フィールドを増やしたい場合はその都度コードに修正を加える必要があります(*)。
なるべくイコール比較を避けたい。対象は不安定なものではいけない。では何に名前をつけて、識別するか。そこにオブジェクト指向技術者の熟練度が現れるのです。
一方、関数型プログラミングでは、特定の何かに名前をつけるより、極力、汎用部品でなんとかしようとします。
関数自体をリストなどのデータ構造に詰めることもよく行われます。
実は、関数型プログラミングというのは本質を表していません。
関数をはじめとして、リスト・ツリーのようなコンテナ、手続きを抽象化したもの、回路を抽象化したもの。
あらゆる対象を値として、合成し、ときに分解し、新しい値を作ります。
変数に適用する処理を作りあげることが、とても簡単だからです。
四則演算が定義されたデータを詰めたデータ構造もまた、四則演算可能だったり。
誤解を恐れずに言うと、オブジェクト指向がトップダウンなのに対し、関数型プログラミングはボトムアップです。
関数型プログラミングをサポートする言語には、沢山の汎用部品が定義されています。
このような構造をインターフェイスとして、様々なライブラリが組まれているので、
たとえばモナドを知っていれば、30分程度でパーサー(解析機)を理解することができて、
パーサーを理解できれば、JSONパーサー・ XMLパーサー・markdownパーサー・C++パーサー ... などを理解するのはとても容易です。
理解しやすいこと。これが関数型プログラミングの大きな利点です。
追記:
また、汎用部品と型のお陰で、ライブラリのドキュメントが圧倒的にひきやすい、というメリットも有ります。
Haskellな人がPythonにトライした結果 - Togetterまとめ
関数型プログラミングは「厳密な事前設計を必要とするため、簡単なことをやるのにも時間が掛かる」。
＞＞ map (*2) [1,2,3] [2,4,6]
邪魔な”儀式”や、"おまじない"のコードが徹底的に撤廃されているためです。
関数型プログラミングのコードは、潔癖かつ濃密です。
たとえばC言語でint hoge(int x,int y)が定義されているとき、hoge(3)はなんの意味も持ちませんが(コンパイルでコケますが)、関数型プログラミングでは意味があり、実際に有用です。
上の例では、「掛け算をする」(*)関数は、二引数関数ですが、それに引数を渡して作られた「2を掛ける」関数(*2)は、一引数関数になります。
関数型プログラミングでは、「簡単なことは簡単にでき、複雑なことは複雑にできる。ただし、間違ったことは殆どできないか、全くできない」。
また、静的型付けの力によって、コード補完は非常に強力になっています。インテリセンスの比ではないです。
たとえば、関数中のある表記の型を任意に表示できます(GHC/TypedHoles - HaskellWiki)。
やがてやってくる未来には、プログラムをテキストエディタで書くことは時代遅れになっているでしょう。
統合環境のサポートで、バグやミスの少ない、スムーズなプログラミングができます。
そしてその環境で動くプログラミング言語は、関数型プログラミングをサポートした言語なのです。
以下の様な兆候を感じたら、あなたはそのプログラムを関数型プログラミングで書くべきです。
一般に、オブジェクト同士の相互作用が複雑になるほど、オブジェクト指向では手に負えなくなっていきます。
そういうときは、オブジェクトを直接扱わず、替わりにその"相互作用"を扱うことで、複雑さを軽減するアプローチが有効です。
それこそが関数型プログラミング的アプローチです。
特にオブジェクト指向が有効なのは、プログラミング初心者がそのコードをいじるかもしれないときです。
関数型プログラミングは、強固さと柔軟さの代償として、高い学習コストを伴います。
オブジェクト間の相互作用が複雑でなく、着目している(名前をつけている)概念が安定しているとき。
そして、プログラムをいじる人たちの間で共通理解が図れているならば、オブジェクト指向が有利です。
遅延評価という機能によって、レガシーな言語で扱えなかった、巨大な数を扱うことができます。
関数型プログラミングで書かれたプログラムは、正確さが要求される、金融関連の業界で使われています。
手続きとしてパーサーを記述できるので、テキスト処理プログラムはより理解しやすく、メンテナンスしやすいものになります。
関数型プログラミングを知らない人は、「正規表現でおk」と言いますが、
彼の書いた複雑な正規表現は、半年後には(書いた本人でさえ)理解できなくなっていることでしょう。
手続き一般を扱うことができるので、途中で割り込みのある手続きの表現も容易です。
関数型プログラミングをサポートしていない言語ではコルーチン(ファイバー)などをつかってなんとかするしかありません。
さもなくば、非並行処理では普通に関数として記述できるところを、並行処理のために、Builder,Strategy,Command,Interpreterパターンを駆使して書き直すことになります。
Javascript使いの方は、Deferredなどの構造を使うでしょう(http://qiita.com/KDKTN/items/4c6986049d204f0645d8)。
C++使いの方はBoostで頑張りましょう。破滅的に解りにくいコンパイルエラーメッセージと格闘してください。
もう少し簡単な例をあげます。
あなたは、あるレシピにしたがって、自動的に料理を行うマシンの制御プログラムを書いているとしましょう。
1. まず玉ねぎを炒める。
2. 飴色になったら、肉を加えて炒める。
3. 野菜を加える。
4. 水を加えて煮る。
5. スパイスを加える。
…できませんよね？何故ならば、各ステップの"間に"、マシンのロボアームの位置や動きを調整する処理が必要だからです。
これをオブジェクト指向でやろうとすると、各ステップの副作用として、それらの処理を行うことになります。
そうすると、マシンが二機に増えた時などの変更量は、絶望的なものになります。
あるいは関数として表現するのを諦め、手順全体をDSLで記述できるようにします。
このアプローチは関数型プログラミング的です。しかし関数型プログラミングをサポートした言語の助けなしでは、そのDSLを記述するために沢山のユーティリティーコードを書かなくてはならないでしょう。
オブジェクト指向的アプローチでこの問題をエレガントに解こうとすると、クラス化の粒度を上げる事になります。
野菜クラス、フライパンクラス、ボイルクラス、フライクラス、焼き加減クラス、アームクラス、野菜の大きさクラス、切り方クラス、焼き方クラス、"焦げたよ"クラス、etc...
こうすると早晩レシピはプログラムのコード上から消え去ることになります。上記のたった5行は、依存性注入のオブジェクトグラフを構築するコードに取って代わることになります。そこには沢山の挙動の制御がオプションとして付記されているのです。
カレーなど、ある種のレシピに限定することで、見た目の理解しやすさを得ることができますが、一方それは表現力を損なうことを意味します。
C言語などではマクロを使うこともできますが、それは結局、関数型プログラミング的アプローチの意味するところと同じになります。すなわち、補助のために沢山のコードを書くことになるでしょう。
iOSのAppstoreアプリは、"無料"と書かれたボタンを押すと、それが"インストール"ボタンに変わり、それをもう一度押すと、ダウンロードの進捗を表すインジケータに変わり、それを押すとダウンロードをキャンセルできます。
このように、位置は同じなのに、ステートに依って見た目と機能が変わるボタンは複雑です。
これをオブジェクト指向で実現しようとすると、
という下らない問題にぶつかります。
一方関数型では、"機能"、"見た目"、"状態"、を独立に扱って、それらを合成してボタンを作るので、迷うことはありません。
「同じ位置にあるUIオブジェクトは、コード上で(インスタンスとして)独立して、他から干渉を受けない」
この条件が満たされているうちは、オブジェクト指向でGUIを実現することに無理はありません。
しかし、携帯端末のような小さい画面で、多くの機能を達成するためには、UI要素はコンテキスト依存的に複雑になりがちです。
近年、PCのディスプレイの大きさは、頭打ちになってきました。
画素数は増えているのですが、MacにおけるRetinaのように、複数ピクセルでひとつのドットを表すようになってきています。
これは、ひとつの画面に置かれるボタンなどのUI要素の数は、これから先の未来で増えることはない、ということを意味します。
したがって、未来のGUIのプログラミングは、注意深く機能をピックアップして制限するというデザイナーの努力を脇におけば、
関数型プログラミングの力を頼るしか無いでしょう。
つまり…
Haskell さいこうなのおおおおおおおおおおおおおおおおおお!! おしっこ漏れちゃうのおおおおおおおおおおおおおおおおおおおお(゜∀。)ﾜﾋｬﾋｬﾋｬﾋｬﾋｬﾋｬ
1. google:すごいHaskellたのしく学ぼう を注文する。
2. Download Haskell を自分のPCに導入する。
3. コンソールにghciと入力して、対話型コンソールを立ち上げる。
4. 次の関数をコンソールに打ち込んで、結果を見る。即値で書かれているところとかをいろいろ変更してみて、感動する。
take 4 $ map (*2) [1..]
追記:
いかがでしたか？
ちまたには、関数型プログラミングの利点は変数が無いことだ、とか、より安全だから、とか、より速いから、などという妄言が満ち溢れています。
オブジェクト指向と関数型プログラミングは、水と油ではありません。プログラマは自分のプログラムに最適なアプローチを選ぶことができます。
一般にはあまり知られていないことですが、Haskellにもオブジェクト指向へのサポートがあるんです(Lensライブラリ、これを使用したサードパーティ製ライブラリも最近増えてきています)。
この記事を読んだオブジェクト指向プログラマのあなたが、少しでも関数型プログラミングに(そしてHaskellに)興味を持ってくださって、ホームセンターの大人用オシメのコーナーが大賑わいになれば幸いです。。
＞こういってるのが全てだと思うんですけどね。
＞4000万使ってボラリティを下げて運用するくらいなら、100万でボラリティのある程度あるシステムで運用した方が良いのでは？と。
＞この場合、運用自体のリスクがどちらが大きいか、と言うことに大きな違いは無いと思いますので。
＞ただ、同じ資産無いで、同じリスクがあるものに分散した所でリスクは同じです。
＞http://assetsplan.net/bun-shi/6borathi.html
＞例えばこれとか見て分かる通り、全く同じ確率の物に分散したところで、リスクだけ下がって平均収益は保つ、なんてことは出来ない。
＞分散投資のメリットは、様々な特徴を持つ株や他の商品に分散することで、
＞もう一つ、例えば1000万の株1つにかけるより100万の株10個に分けたほうが、1日単位で考えた時、1日で10回試行している様なものだから
＞それをある意味でボラリティの低下、ということも言えるかもしれないが、いわゆるリスク、振れ幅自体が小さくなっているわけではない。
こういっているのがすべてです。
＞後のことに関しては色々仮定があるのでもういいです。
＞そもそも同一金額をかけるのか分散に必要な金額がいくらなのか、
＞対象がどの程度あってそれぞれがどの程度のリスクなのか、
＞に大きく寄るので。その辺りで根本的に前提の違いがあったみたいなので、
上にある通り、これらの前提に違いはないにも関わらず、君は間違ったことを言っています。
ちなみに、同一金額かどうかについてのみ、そちらから言及がありませんが、私の方から分散投資にするかどうかで、投資の総額をかえるべきでないと、しばらく前に言っています。
そちらでも単位に％を使うあたり、金額ではなくて金額の比率を扱っているため、投資総額が一定という前提があることが推測されます。
それ以外の前提についても、こちら側でも明確にしています。
ですから、それらの前提に違いはありません。にもかかわらず、リスクは同じだと言い張っていたのです。
＞等しい分散を持つ分布を畳み込んだ場合に分散が独立でない場合に比べ
これも間違いです。もっともボラティリティが低くなるのは、独立とはもっともかけ離れた、相関-1のケースです。
独立であるという仮定は、ボラティリティをどのくらい下げるかという点に関して、純粋に確率統計の議論としては、おおむね中立的な仮定なんです。
＞適当に分散するのは、単に手を広げて管理の手間が増えるだけだろう、
＞と言ったことです。
あなたが実際に何度も言ったことは、上にある通りそれとはかけ離れた主張ですが・・・。
まず、分散したらどれだけリスクが下がるのか？について議論するなら、ようやく単なる理論を超えて、実際の数値が登場することになります。
それはそれとして、適当に分散するのがよくないのは当たり前です。
＞ETFでも良いですが、ETFが同じ平均収益があってリスクが低いものであれば
＞なぜ皆がそれをやらないのでしょう？そこに尽きると思います。)
そもそも個別株をやっている人自体が少ないので・・・仮に個別株よりずっと得です！といっても、皆が皆やるわけではないでしょう。
定期預金よりリスクの高いものには手を出さない人もいれば、投機的なまでにリスクがあった方が面白いという人もいますから。
＞変数どうのこうのですが、この様に式建てて分かりやすく、後の数値計算をしやすくするために
＞行っていることはご存知ですよね？
いずれも間違いです。変数を使って、数学的な議論だけでわかることもたくさんあります。
今回あなたが何回もやっている間違いは、ちょうどそれにあたります。
過去のデータを使っている限り完璧ではないみたいなことを言い出したので、そういう話ではないことを強調しました。
＞あなたは、数値はどうでもよい、さらにドリフト項など過去の分布から求めるものではない、
＞と繰り返してきましたが、それは変えませんか？(カエルも何も無いんですけど。)
というのもおかしな話で、もちろんもっと込み入ったことを考えるときには、数値だしますし、それは重要です。
しかし、まず過去のデータに依存せずに、論理的または数学的にはっきりわかることを確認するのには、大きな意味があります。
それにしても、単語だけググって知ったかぶりしているのかと思うレベルのミスばかりしている人が
＞要するにすべてあんたの"思い込み"だけじゃないか。
＞それに対して、あなたは数学的な根拠もあるかのようにドリフト項だの出してきたが、
＞それでも信じるのは自由だが、いい加減な事を言うのはヤメてください。
＞内容も何も分かってないのに平均収益だのドリフト項だの言ってることはよくわかったからもういいや。
＞この様に、何も分かっていない人間が、さも分かったふうなふりをして
とか言えるって、すごいですね。どんな人なのか少し興味があります。
