  |
はてなキーワード: 数値計算とは
こういってるのが全てだと思うんですけどね。
後のことに関しては色々仮定があるのでもういいです。
そもそも同一金額をかけるのか分散に必要な金額がいくらなのか、
対象がどの程度あってそれぞれがどの程度のリスクなのか、
に大きく寄るので。その辺りで根本的に前提の違いがあったみたいなので、
混乱させてすいません。
等しい分散を持つ分布を畳み込んだ場合に分散が独立でない場合に比べ
適当に分散するのは、単に手を広げて管理の手間が増えるだけだろう、
と言ったことです。
ETFでも良いですが、ETFが同じ平均収益があってリスクが低いものであれば
なぜ皆がそれをやらないのでしょう？そこに尽きると思います。)
変数どうのこうのですが、この様に式建てて分かりやすく、後の数値計算をしやすくするために
行っていることはご存知ですよね？
あなたは、数値はどうでもよい、さらにドリフト項など過去の分布から求めるものではない、
と繰り返してきましたが、それは変えませんか？(カエルも何も無いんですけど。)
あなたが決めるものでなく、過去の分布から決まるものでなければ、
神のみぞ知る、ということでしょうかね？
で、それを何とか確率的に求めるために数値化して指標化する、の1つがドリフト項に当たると思うんですけどね。
違いますかね？
決済だのandroidアプリだのだったら適当なのでやります。
要するに数値計算がしたいので、PHPとかjavascriptとかだと困るわけです。
インターネッツつなぐやつ1台
持ち運びするノートパソコン1台
数値処理や数値計算するためのクラスター、もしくはワークステーション1台
ということで最低5台か。ファイルサーバーとインターネット用PC、あとオフラインPCはやっすいので問題ないからいいとして、ノートとワークステーションは定期的な買い替えが必要か…
新たなアーキテクチャーを創設するくらいならオープンソースの分散並列(OpenMP-MPI)のハイブリッド(CPU-GPU)数値処理ソフトウェア開発に力を入れたほうがいい。
少なくともオープンソースで動くOpenMP-MPI CPU-GPUの基本的な数値計算ソフト(特に行列計算)は世界最先端の研究内容。こういったソフトを毎回アーキテクチャーごとに作るのは金の無駄だし、x86-x64環境で動くようにすればいい。
現状の数値シミュレーションなんてKrylov methodなどの行列処理が主な作業なんだから、それを汎用アーキテクチャで使えるようにしたほうがいい。CPU-GPU＋OpenMP-MPIで動く行列処理のソフトがあればそれが汎用の処理として使えるんだからくそみたいにコンパイルがめんどくさいアーキテクチャを作るくらいなら、汎用で使えるオープンソースのソフトを作れよ。
そんなコードがTrilinosなんだけどね。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
なんか、誰の役に立つのか分からんけど、私が高校生の頃にこういう説明があったら良かったなぁ……とふと思ったので書いてみた。
さて、大学の工学部機械工学科に入学するとしよう。基本的に機械工学科に含まれる研究分野は多い。もちろんそれには理由があるのだが、それでもほぼすべての学生が学ぶ共通の内容があり、機械工学科を卒業した学生に企業が期待するのはそれらの基礎知識である。そういう意味で機械工学は非常に実学に近いと言っても良い。
機械工学科の教員は本当に口を酸っぱくして「四力を身につけろ」と何度も何度も授業の度に言ってくる。古いタイプの教員ほどその傾向は強い。いわく、「専門分野の基礎がわかっている人間が社会では強い」、「四力が身についていなければ学科長が許しても俺が卒業させない」、云々。で、その四力というのは以下の４つの「力学」のことを指す。
機械力学というのはいわゆるニュートンの力学でいう「剛体の力学」で、弾性・塑性変形しない対象がどのように運動するかを扱う。振動工学とか解析力学とかはだいたいこの延長線上で学ぶ。高校の力学に微分積分を足した感じだと思えばいい。
熱力学はマクロで見た気体や液体の持つエネルギーを対象にする。これも微分積分やエンタルピー・エントロピーの概念を除けば高校で学べる物理とそう大差はない。次の流体力学と合わせて熱流体力学というジャンルを構成していることもある。統計力学は熱力学の延長線上で学ぶことが多いが、量子力学とともに挫折する学生が非常に多い。
流体力学はその名の通り気体と液体を合わせた流体の運動について学ぶ。航空関係の仕事がやりたいなら必須。多くの近似法を学ぶが現実にはコンピュータ・シミュレーションが用いられるのであまり細かく勉強しても役に立つ場面は少ないかもしれない。下の材料力学とは連続体力学という共通の基礎理論を持つ遠い親戚。
最後の材料力学は、弾性をもつ（＝フックの法則に従う）固体の変形が対象。建築学科とか土木工学科だと構造力学という名前で開講されているが、内容はだいたい一緒。これも多くの近似が含まれる体系で、実際にはコンピュータを使った有限要素法でシミュレーションする場面が多い。とはいえ基本を大学学部時代に学んでおくことは非常に重要。
で、これら４つの科目がどう生きてくるかというと、たとえば２０世紀における機械工学の結晶であるところのエンジンの設計なんかにはこれら全部が関わってくる。機械にかかる荷重や振動を解析し（機械力学）、エネルギー効率の高いサイクルを実現し（熱力学）、吸気と排気がスムーズに行える仕組みを作り（流体力学）、これらの条件に耐えうる材料を選ぶ（材料力学）。もちろん就職したあとにこれらすべてに関わることはないし、実際に使える高度な知識を教員が授けるわけではないが、機械の設計に際しては必須の基礎知識ばかり。とはいえ後のように四力から直接発展した研究をしているところはまれで、院試のために勉強したのに後はもう使わなくなった、なんてこともままあるわけだが……。
なお高専からの編入生が入ってくるのは２～３回生なのだが、彼らはすでに四力を身につけていることが多く、運が良ければ通常の学部生からは羨望と尊敬のまなざしを勝ち得ることができる（しかし英語ができないので研究室に入ってから苦労することが多いようだ）。
高度な数学や電磁気学であったり、機械加工や金属材料や設計に関する専門的な知識もカリキュラムに含まれることが多い。みんな大好きロボットは制御工学の範疇で、これは四力とは別に学ぶことになる。ロボット＝メカトロのもう一つの必須分野である電気電子系の講義はほとんどないので独学で学ぶ羽目になるが、微分方程式が解ければ理解にはさして問題はない。プログラミングや数値計算などの授業は開講されていることもあるしされていないこともある。とはいえ機械工学科を出てガチガチのプログラマになることはほとんどないし、教えてくれてもFORTRANか、せいぜいＣが限界である。さすがにBasicを教えているところはない。……ないと信じたい。
実習や実験がドカドカと入ってくるのは理系の宿命なのだが、特徴的なのはＣＡＤの実習。おそらく就職したら即使う（可能性がある）ので、研究室に入る前に一度経験しておくといい。もちろん実際にＣＡＤで製図するのは専門や工業高校卒だったりするのだが、そいつらをチェックしてダメ出しするのは大卒なり院卒なりの仕事になる。
四力を身につけたらいよいよ研究室に配属されることになるのだが、基本的に四力を応用した分野ならなんでも含まれるので本当に各研究室でやっていることがバラバラ。隣の研究室が何をやっているのかは全くわからない（もちろんこれは機械工学科だけではないとは思うが……）。そのため学科のイメージを統一することが難しく、どうしてもわかりやすいロボットなんかをアピールすることが多くなってしまう。とはいえそういう「わかりやすい」ことをやっている研究室は少数派で、実際は地味なシミュレーションや材料のサンプルをいじくりまわしているところが多数派である。最近は医療工学系の研究をしているところが増えたらしいが、光計測だったり材料物性だったり航空工学だったり、あるいは全然関係ないシステム工学だとか原子力工学の教員が居座っていることもあるようだ。こういう教員を食わすために機械工学第二学科（夜間向けの第二部ではない）が設立されたり、環境とかエネルギーとかが名前につく専攻が設立されたりすることがままある（昔は学科内に新しく講座を作るにはいろいろと制限があったらしい）。そういうところは（上位大学なら）ロンダ先として利用されるのが常で、そうした研究室を選んでしまった学部生はマスターの外部生の多さに面食らうことになる。
とはいえいろいろ選べるならまだマシな方で、大学によっては計測か材料かしか選べなかったり、工業高校ばりの金属加工実験を延々とやらされたりすることもある（ようだ）。やりたいことがあるならそれをやっている大学に行け、とは機械工学科志望の高校生のためにある言葉かもしれない。
そう、就職は非常にいいのだ。「学内推薦が余る」という噂を聞いたことがある人がいるかもしれないが、まぎれもない事実である（とはいえ最近は上位校の推薦でもガンガン落としまくる企業が増えたようで就職担当も頭を抱えているようだが）。機電系なる言葉が広まったのはネットが登場して以降らしいが、機電系＝機械工学系と電気電子工学系、というぜんぜん関係ない２つの学科をまとめてこう呼ぶのは、それだけこの国の製造業でこの２学科出身者が必要とされているということだろう。我らが機械工学科の後輩たちのために、これからも経済産業省には「モノづくり立国」なるわかったようでよくわからないスローガンを推進していただきたい。
inspierd by http://anond.hatelabo.jp/20110929232831
追記：あえて上位と下位の大学の事情をごっちゃにして書いているので、受験生諸君はあまり鵜呑みにせず自分でリサーチするようにお勧めする
20年以上前、卒論の研究で、自分が設計した半導体デバイスの特性を計算するために、
境界条件がいろいろややこしいポワソン方程式（＝微分方程式の一種）をガシガシと解いて、
ベーシックでFOR - NEXT 構文使って数値計算してグラフ描いたなぁ。
ドットプリンタの出力が汚かったから、ロットリングペンと雲形定規で清書までして。
今はエクセルあるけど、そういう微分方程式を自分で解かないと、セルに入力する式が得られない。
何が言いたいかというと、暗記だけの数学しかやって来なかったら、
解けるかどうか分からない微分方程式を、「解こう」とチャレンジしなかっただろうなあ、ということ。
若いのにせっかくの学ぶ機会を潰してもったいないなあ、とオッサンは思う。
元増田。おー！PRとPRLの違いがよく分かった。これについては、素直に勉強になった。ありがとう。なるほど、なるほどねー。
＞んでお里が知れるっつったのは、自分はphysical reviewとPRLの違いも知らないのに、物理の人には情報系の事情を知って評価することを要求したことについて言ったんだよ。無理でしょ。
うん、この問題についてよく考えなおしてみると、この問題は、もしかしたら、単に情報系の中の内輪もめ問題なのかもしれない、と思い始めた。視点が増えた。ありがとう。
＞物理の人と情報の人が同じポストを争うことなんてないでしょ。
専門外だから、よく知らないが物理シミュレーションとか数値計算あたりだとかぶるかもしれん。学振も、工学の中ではかぶることがありそう。アカデミックの公募で、同じ専攻内に物理系の研究室と情報系の研究室が混じっていると、物理系の人が情報系の人の業績評価に加わることとかはありそう。そうすると、情報系の人からみると、日本語の論文誌をたくさん書いているだけで、有名査読付き国際学会に全然通せていない人が優遇されることがある…らしい。
しかし。よく考えると、情報系の中でも、公募での評価は論文誌＞国際学会が妥当、と考えている人もいるし、単に情報系の業績評価の内輪もめ問題なのかも知れない、とも思い始めた。今は違うが、一時期、大学の情報系研究者の特許が論文より高く評価されて、みんな特許を出した時期があった、とかいう話も聞くし。情報は、分野として物理より歴史が浅いから、業績評価の方法が定まっておらず混乱していて、その混乱が分野外の人のせいにみえている情報系の人がいるっていうだけなのかも知れない。あと、数十年すると、情報系の業績評価の方法も定まってくるのかも。不当に文句を言ったかも知れない。ごめんなさい。
（そのレスがどのように「いや」になるのかよく分かりません）
ちなみに、電子レンジのマイクロ波が水のどういう自由度と共鳴するのかちょっと分からなかったんで調べたところ、電気分極と相互作用するようです。
分子間振動(水素結合)や原子間振動は電子レンジよりかなり速い周波数なので関係無い。（まぁ常識的に考えてそんな電磁波をおいそれと発生させたら酷い目に会いそう）
この辺の振動数がなぜそうなっているのかを知るためには、量子力学を使う必要があって(分極以外)、水分子程度の複雑さになるとまぁまず手では解けないので適当な近似解法や数値計算の知識が必要になります。
ちなみに分極については、結構広い周波数帯に感応するようで、熱の発生源は共鳴そのものというよりも分子集団の運動に伴うエネルギーの散逸が主なようです。
なんか話が合いそうだなと思ったので返信。増田なのがちょっと勿体ない気もするけど。
ちなみに俺のバックグラウンドを書いておくと、学生時代の専攻は工学系なんだけど、それにしてはオーバースペックなぐらい数学をかじってた感じの方面。あんまり詳しく書くと特定されそうなんでこの程度で勘弁ね。
"Pattern Recognition and Machine Learning"のビショップも物理出身だけど、あの年代は確かにそういう色が強かったのかもしれない。
確かにその種の傾向は上の世代までかもしれないね。
ビショップが物理出身なのは知らなかったけど、それ聞いてなんか合点のいく気がした。何か妙に数学へのマニアックなこだわりの片鱗が見える割に、数学屋から見ると妙な記号法を使うんだよね、あの人。
全然高度じゃないです＞＜
いや、だからあくまで「工学として」ね。線型代数と、微積の「計算」以外を使うことって工学ではそうないでしょ（フーリエ変換とかだって工学の文脈では所詮「計算」だもんね。）。
制御理論とか機械学習では、関数解析の概念がちょっとだけ出てくるけど、あんなんでも数学屋にとってはオアシスだね。
もっとも、カーネル法関係ではいつも申し訳程度にMercerの定理が言及されているのを見ると「なんだかなあ」っていつも思うけど。
そうそう、あれに限らず統計学の理論の一部にはものすごく違和感あるんだよね。
増田だから書けるけど、情報幾何なんて「お前、双対接続って言いたいだけちゃうんかと」って感じだし、他にも色々、何でも抽象化して一般化すりゃいいってもんじゃないんだぞと言いたくなることが色々。
統計学の理論と機械学習・パターン認識の関係は、数理物理・理論物理と実験物理の関係に似てる気がするんだよね。しかも統計学の場合、普遍的に綺麗な構造なんてものがあると思えないだけに余計に始末が悪い。「ひも理論は実験で検証できないから科学ではない」って批判があるらしいけど、統計学にも同じ批判されても仕方ない理論が色々あるよね。データから何かを推定する理論なのに、データがどれだけあっても実用的には絶対まともな結果が出せないモデルとか。
CVのレイトレーシングで経路積分使って云々というのもあったけど（その人はGoogleに言ってアドセンスかなんか作ってるらしい）、あれもまぁ適当なパス空間で平均とるだけって感じがするし…。
CVはまあ何でもありの世界だよね。誰か無限次元リー群とか使ってみてくれないかなと思う。というか俺自身が一度やろうとして無意味なことに気づいてやめたんだけどさ。
イジングモデルとかその辺は不勉強なんであまりよく知らないんだけど、一般的にその手のモデルは、性能が変わらないだけならいいけど、計算量がどうとかデータ量がどうとかで事実上使えなかったりすることが多いんだよね。着想として物理からアイディアを持ってくるのはいいんだけど、物理から持ってきたアイディアなら必ず筋がいいはずみたいな思いこみ（そう思いたくなる気持ちはよくわかるけど）はどうかと思う。
普通に日本の伝統的新卒採用でそういう会社に行く人はいるけど、やってることは工学とかあるいは良くわからない専攻の人と同じな気がする。これはちょっと曖昧だけど。
うん、そうなってしまうのは仕方ないでしょうね。
ただ逆に、変わり種のバックグラウンド持ってる人は道具箱が豊富だから、新しいこと思いつく可能性もあるわけで、採用されるとしたらむしろそれを買われてじゃないかな。俺自身、工学部の人は普通は絶対知らない数学を色々知ってるので、それをどうにか武器にできないかいろいろ試行錯誤中だよ。というか特許とかの形で発表したのもすでにあるけどね。
特に情報系の分野は実装力で評価されることが多いし…。実装力は数値計算得意とかそういうのとは全く別のスキルだよね。プログラミングマニア的な要素が必要。
分野にもよるけどね。情報システムや計算機自体を専門にして、ハードとかインターフェイスに近い部分をやってたらどうしてもそうなるけど、信号とか画像とか音声とか言語とかの処理のコア部分を作るときにはコーディング能力よりも紙と鉛筆の能力の方が大事・・・、だと思いたい。
どうもパソコンマニア的気質は中高生のときに飽きてしまって、「PCパーツの種類とか流行の言語とか覚えたってどうせ10年したらすぐに廃れるんだから」という感じで、余りはてな民的に新しいネタ追いかけたくないんだよね。クロージャって何ですか、ああそうですね閉包ですね、集合の内部と境界の和集合ですねっていう感性の持ち主なので。正直、コーディングは単純作業と認識してます。
まぁネタで訊いたんですけどね…。
これも実際問題（特に企業での採用とかでは）情報系の独壇場って感じだね。
金融のがまだマシ。
"Pattern Recognition and Machine Learning"のビショップも物理出身だけど、あの年代は確かにそういう色が強かったのかもしれない。
金融はまだ金融専攻がほぼ無い状態だから物理や数学出身者が入り込む隙が多い気がする。
全然高度じゃないです＞＜
情報幾何とかは（無駄に）高度だけど、実用性はあんまないオナニー（しかも日本でしか流行ってない）感があるし。
CVのレイトレーシングで経路積分使って云々というのもあったけど（その人はGoogleに言ってアドセンスかなんか作ってるらしい）、あれもまぁ適当なパス空間で平均とるだけって感じがするし…。
画像処理とかでマルコフ確率場の統計物理学的な解析（イジングモデルとかポッツモデルとか出てくるアレ）でレプリカ法とか繰り込み群とか使ってるのも見たことあるけど（結構前の研究だからきっと今はもっと進んでいるはず）、企業で使うことってあるのかなあ。結局性能はあんま変わらないからもっとシンプルなモデルでいいよとかなってそう。だったら物理の奴なんかいらねーじゃんみたいな。
これは…どうなんだろうか？
普通に日本の伝統的新卒採用でそういう会社に行く人はいるけど、やってることは工学とかあるいは良くわからない専攻の人と同じな気がする。これはちょっと曖昧だけど。
これはガチだね。
特に情報系の分野は実装力で評価されることが多いし…。実装力は数値計算得意とかそういうのとは全く別のスキルだよね。プログラミングマニア的な要素が必要。
あとはまぁお決まりの暗号分野とかもあるけど、暗号じゃそんなにイス無いだろうし…。
最近はやっぱデータマイニング系に流れてるのかなあ。あれも数理的な素養というよりは職人芸的な色彩が強いけど。
という感じで実際問題厳しいなあと思います。
マジレスすると、純粋数学とか理論物理は意外とつぶしが利く。特に理論物理で数値計算ができる人はいろんな分野に対応が可能。
信号処理とか制御とか機械学習は物理からネタ引っ張ってきてたり、工学としては例外的に高度な（物理の道具としてはまあ普通の）数学を使ったりするので、理論物理の人は実はポテンシャルが高いよ。
あと勿論、理論物理の人は重工業方面でも引き合いが強いだろうしね。
ただ、採用現場では必ずしも好かれるとは限らないのでコネがないと厳しいかもね。とはいっても、純粋数学や理論物理を本気でやれるレベルの大学なら他学部の知人なんかで探せば見つかるだろうけど。
人によってそれぞれ。
・言語そのものにワクワクする人
・ハードを動かす事にワクワクする人
・ソフトを動かす事にワクワクする人
・プラットフォームに興味はないが、作りたいものがある人
・面倒な数値計算をミスなく短時間で終わらせる必要に迫られている人
・同じ作業を繰り返し行うことに疲れていて、誰も問題視していない事に憤りを感じ、改善する意欲のある人
上記のいずれかに該当する人は、勝手にもりもりと弄ります。
そのどれにも該当しない場合、一度胸に手を当てて、「何故今プログラムをやるのか」を問う必要があるでしょう。
一般的には、上から４つくらいが順当な理由ではないでしょうか。
「作りたいもの」はそれこそ多岐にわたりますね。
作った後に公開して後悔、そしてそれを改善していく、なんてフローが「練習してライブして」にあたりますかね。
練習で必要なのは、「やりたい事をこんぴゅーたにやらせる時、どの様なアプローチを取るか」きちんと設計することです。
そこができれば、後は設計を実装するのみとなりますが、ここで初めて言語の出番になります。
「テイラー展開」があれば、例えばの話、「f(x)=-1/5+(1+x2)log[5-x]Tan[x]/(5-x2)」
こんなムズカシイ関数でも、只の「f(x)=ピーx＾5+ピーx＾4+ピーx＾3+ピーx＾2+ピー」という
xのゴリ押し乗に変換でき、電卓で容易に「数値計算」できてしまうのです。
そうです、あなたが高校数学３年間で習った「logの足し算かけ算割り算の公式」
「指数関数の足し算かけ算割り算の公式」「sinやcosの入った微分積分」
「ルートの入った計算」などなど、世の中に存在する95％の関数が「Xのゴリ乗」という
単純式に還元できるのが超数学「テイラー展開」の威力なのです。
そうなんです、あなたの習った受験数学という名の荘厳な体系を暗記する日々は、
実は砂上の楼閣で、完全に青春を腐らせた「無駄な時間」だったんです。
すまん、たぶん誤爆した。俺がもの申したかったのは
プラスで物理や生物や化学やなどが必要になってくるけど，基本的に数学科並みに数学が必要。情報科学って一応応用数学だからね。
を書いた人であって、君じゃないんだ。確かに別人であるという区別はできてなかったんだけど。申し訳ない。
でもまあ、ついでだからお節介を言っておこうか。
学部のうちは、「この知識は、本当に将来使うのか？」ということに拘って知識を取捨選別してしまいました。
授業もそうやって選んでいたわけですし。当時は、なんとなく、「将来、時間があって必要なときに覚えればいい」みたいに思っていたのです。
実際に修士になってみて、激しく後悔しました。本当に専門以外のことを勉強する余裕がない。数学は、演習問題ぐらい解けるようにならないと、理解したことにはならないし、自分の専門にも応用できなくて勉強した甲斐がなくなってしまうのに、演習問題を解く時間がない。
学部のうちは、専門以外の勉強をちゃんとやっておくべきだったのだなぁ、と思っています。
いや、それはそんなもんだと思う。たいていの人は。何でもかんでもきちんと理解している人なんていないし、学部時代に詰め込み勉強していても結局本当に大事なところは見えていなくて、後からもう一度復習するハメになったりするもの。やっぱり、本当に自分が切実な必要性を感じて勉強したことしか身に付かない。
大事なことは、それを取り戻していこうという努力を少しずつ積み重ねることだと思う。このあと博士にいくのか就職するのか知らないけど、研究者なり技術者なりとしてやっていくなら、才能なんかよりも地道な努力を少しずつでも続けていくことが結局は一番大事なんだと思うよ。
あともう一つ横から。
そうですよね・・・職人芸ですよね。それは分かっています。ですから、数値計算のプログラムを自分で書く気はしません。
linpackなどで既存のルーチン探して、コピペするだけです。そっちの方が早いし確実ですし、バグがない。
だから、全然数学をやった気にならないのです。
実際、LINPACKだのLAPACKだのに不必要に喧嘩を売ることはお勧めできない。あの辺は専門家の知識の集積だと思うので、素人が戦いを挑むのは無謀だと思う。
重要なのは、自分が計算量を節約するためのアルゴリズムを設計する必要が出てきたときのために、数値解析屋さんの「感覚」を学んでおくことじゃないだろうか。
だから、こういう勉強は必ずしも同時並行じゃなくていいと思うんだ。「理解していないものは使ってはいけない」とか言い出すと、電子回路とλ計算がわかってない奴はコンピュータ使うなってことになりかねないし。知識の裾野を拡げつつ、専門性は専門性で深めていくということじゃないかな。
元増田です。
「QR法って何？」って思って検索してしまいました・・・QR分解のことですか、そうですか。よかった、かろうじてわかる。
そうですよね・・・職人芸ですよね。それは分かっています。ですから、数値計算のプログラムを自分で書く気はしません。
linpackなどで既存のルーチン探して、コピペするだけです。そっちの方が早いし確実ですし、バグがない。
だから、全然数学をやった気にならないのです。
中で何やっているのか、本当は知らないとだめだよね、と思います。
「数値計算」だと幅が広すぎますが・・・要するに、「何か計算しないといけないと思うと、ネットを探してルーチンをコピペするだけになってしまっているこの状態をなんとかしたい」ということです。
そこまでひどくはないんだろうけど。数値計算は職人的だけど、そういうアレなところも含めて
自分で身に付けておかないと自分で何も出来ないから。ただそれが目的ではないにもかかわらず、
実際に研究になると教科書的に押さえているというよりも、ピンポイントでどこをどう掴んだか、
掴めるかのほうが大事だから。だから、そこにあがっているようなおおまかな分野を列挙されると、
いや知らないことないし理解はしているとはおもうのだが、それが何か尺度になるんだろうかと思ってしまう。
実際そういうものを道具として使っている人の間でも、随分ばらつきと落差があるしねえ。
つまり特定の分野を出して、コレ知っているか！というのはばかばかしくないかと。
