  |
はてなキーワード: 数値計算とは
そろそろ就職しなければ飢え死にしてしまうので将来のことを考える今日この頃です。
できればはたらきたくないのですが、木こりか溶接工ならなってもいいかなと最近思います。理由は、物理学専攻の人がドクターコースを中退して漁師になったという記事を雑誌で見て、なんか満足してるようだったからです。
勉強は並にできます。英語とか喋れます。Pythonで30行程度のプログラミングができます。
手先は器用な方です。ピアノが弾けます。絵が描けます。子供の頃から大切に育てられたので、その他一通りインドアです。
しかし体が弱いのです。視力がべらぼうに悪いです。背の順で並べば前から2番目くらいの体格です。そのうえ鬱病の診断を受けたことがあり、よわよわです。
イメージですが、木こりも溶接工も究極の封建制で頭脳よりは肉体を礼賛し、効率よりは伝統を重視し、健康よりは煙草を愛するという感じではないでしょうか。
これが私を求めるとは思えず、また私も耐えられるとは思えないのです。
ちなみに私は大学では水産学科卒ですが弱物理学のようなよくわからない数値計算をしており、船に乗ったことはありません。
木こりと話したことは一度もありませんが、多分会えば私のことを宇宙人というあだ名で呼ぶでしょう。
少々叱られるのはもちろん分かっています。たぶん耐えられます。ただ、ヘルメットなしで直に親方に頭を叩かれたら死ぬかもしれません。
枝が降ってきて足に突き刺さってしまったら死ぬかもしれません。指と鋼管がくっ付いて死ぬかもしれません。アーク放電を見て失明するかもしれません。
そう考えると、働いて死ぬよりは働かないで死んだ方がいいなと思うのです。
結構よくまとまっているとは思うんですけど、博士学生だからか少し偏りがあるので、もし参考にする学生が居たときのために、少し補足させてください（ちなみに私は本職です）。
挙げられている分野は、いわゆる古典的なCGの分野の一部で、そこに当てはまらないものも沢山あります。例えば、3Dプリンタに関する技術とか（fabrication）、建築関係、VR/AR、HCI、HPC/ハードウェア、computational photography、アート、数値計算、言語処理（CUDAの元はSIGGRAPHの論文ですよ）などです。実際のところ、かなり色々なトピックがあり、この分野の研究者でも全てを挙げられる人は居ないと思います。トピックが違うと同じCGの研究者でも話が通じない事もあります。他分野の専門家と組んで研究している人も多いので、かなり懐が広い分野だと思います。自分の興味のあるもの+CG、という研究をしている人が多数居ます。
なお、西田先生は日本では有名なのかもしれませんが、国際的に著名な研究者は各分野で違います。SIGGRAPH/SIGGRAPH AsiaなどのTechnical Paper Committteeの名前をチェックすれば、最近勢いがある若手や著名な人がだいたい分かると思います。自分の興味のある分野の研究者が海外に居れば、留学しましょう。
これは訂正された点を含めると、だいたい合ってます。訂正にあるように、基本的には、大きな学会のProceedingの論文 = ジャーナル論文なので、その場合ジャーナル論文としてカウントする人が多いです。ジャンル別の会議に理論的な研究が発表されるかどうかというと、そうでもないでしょう。どちらかといえば、研究としてのインパクトが小さいが発表したいとか、SIGGRAPH/SIGGRAPH Asiaに落ちたので、再投稿というケースが多いです。国内の学会・雑誌はアレなので、英語で文章が書けないと死にます。
CGではIFを気にする人はあまり居ません。研究者としてのアウトプットは、国際的にはSIGGRAPH/SIGGRAPH Asia/TOGを含めた、主要な学会での論文の本数が重要です。Pacific GraphicsおよびEurographicsは、それぞれの地域ではそれなりに評価されますが、国際的には評価されない場合があります。あと、勘違いされているケースが多いので強調しますが、SIGGRAPH/SIGGRAPH AsiaでカウントされるのはTechnical Papersだけです。その他のプログラムは、参加したいなら出してもいいけど、研究業績にはカウントされません。その他のプログラムばかりで発表していて、Technical Papersで論文が出て無いのに、SIGGRAPHで活躍していると強調している研究室（国内外にあります）は注意しましょう。分野全体の業績評価の実態と違います。
学位取得難易度は、研究室および大学によって大きく違います。上記の著名な国際会議に通すことを期待している研究室だと、アイデアが重要な分（データやモデルを少し変えて、少し性能が良くなったぐらいでは論文は通りません）、他の分野より要求される能力は高めです。ただ、懐が広い分野なので、自分の得意なことを生かして研究ができれば、研究に没頭できて楽しく過ごせると思います。実際、活躍している人はそういう人です。標準的なアウトプットとしては、1年あたり、ジャーナルになる学会に1本ぐらいでしょう。博士課程が3年なら3本ですね。リジェクトされるので、その倍ぐらいはプロジェクトをこなす必要があります。
実装力は超重要です。アイデアを形にして実験出来ない人は苦労します。言及元に書いてあるものの3倍は実装します。
研究の歴史が長いトピックは既存の研究に対して新規性を出すのが難しいので、その分論文を書くのは難しいという、ごく当たり前な状況です。書かれているように、レンダリングや流体は難しいと認識はされていますが、それは歴史が比較的長く、劇的な性能向上が難しいからです。逆に最近出てきたトピックの中だと、新しい応用を見つけてそれを古典的な方法で解く感じの研究が多いです（3Dプリンタ向けのデザインの最適化など）。そのようなトピックであれば、面白い応用さえ思いつけば、既存研究との比較をあまりしなくても通る論文が書けるでしょう。いずれにしても、如何にして新しいアイデア（新しい理論・手法であったり、新しい応用であったり）を思いつくかが重要です。
各分野の所感については、言及元は一学生の感想で、それが分野全体としての共通認識かというと、そうではないように思います。一口にCGと言っても研究分野が多岐にわたるので、それぞれの分野の専門家に話を聞くのがベストです。
研究室で育ててきたエンジンがあるかどうかは（そしてそれを弟子に使わせるかどうかは）研究者によります。進学する際には、その辺をチェックしましょう。ただ、現在活躍している人には、自分で書きたがる人が多いです。「レンダリスト」という言葉は聞いたことがありません。
だいたい正しいと思います。応用的な研究と言うと、表面的な印象を受ける人がいるかもしれませんが、ただ何かを達成すればいいというよりは、実際の問題を解けて理論的にも面白いという研究を目指す人が多い分野です。査読ではその両面が評価されるので、査読者によってどちらに重きを置くかも違い、皆を納得させる成果を出すのはなかなか大変です。
CGは、研究を頑張って学会等に論文を沢山出せれば就職先も引く手あまただし、研究成果は専門外の人（例えば家族とか）にも分かりやすいし、自分の興味のある事をコアにして研究できる懐の広さがあり、とても楽しい研究分野です。どの分野で研究しようか迷っている人はぜひ！
去年の夏ごろから意識をし始めて、夏は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はよくわからないですがきっといい言語です。がんばってください
