  |
はてなキーワード: 数値計算とは
いくつかまとめて反論したい
まず最初に言っておきたいけれども、僕自身は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が同じ平均収益があってリスクが低いものであれば
＞なぜ皆がそれをやらないのでしょう？そこに尽きると思います。)
そもそも個別株をやっている人自体が少ないので・・・仮に個別株よりずっと得です！といっても、皆が皆やるわけではないでしょう。
定期預金よりリスクの高いものには手を出さない人もいれば、投機的なまでにリスクがあった方が面白いという人もいますから。
＞変数どうのこうのですが、この様に式建てて分かりやすく、後の数値計算をしやすくするために
＞行っていることはご存知ですよね？
いずれも間違いです。変数を使って、数学的な議論だけでわかることもたくさんあります。
今回あなたが何回もやっている間違いは、ちょうどそれにあたります。
過去のデータを使っている限り完璧ではないみたいなことを言い出したので、そういう話ではないことを強調しました。
＞あなたは、数値はどうでもよい、さらにドリフト項など過去の分布から求めるものではない、
＞と繰り返してきましたが、それは変えませんか？(カエルも何も無いんですけど。)
というのもおかしな話で、もちろんもっと込み入ったことを考えるときには、数値だしますし、それは重要です。
しかし、まず過去のデータに依存せずに、論理的または数学的にはっきりわかることを確認するのには、大きな意味があります。
それにしても、単語だけググって知ったかぶりしているのかと思うレベルのミスばかりしている人が
＞要するにすべてあんたの"思い込み"だけじゃないか。
＞それに対して、あなたは数学的な根拠もあるかのようにドリフト項だの出してきたが、
＞それでも信じるのは自由だが、いい加減な事を言うのはヤメてください。
＞内容も何も分かってないのに平均収益だのドリフト項だの言ってることはよくわかったからもういいや。
＞この様に、何も分かっていない人間が、さも分かったふうなふりをして
とか言えるって、すごいですね。どんな人なのか少し興味があります。
こういってるのが全てだと思うんですけどね。
後のことに関しては色々仮定があるのでもういいです。
そもそも同一金額をかけるのか分散に必要な金額がいくらなのか、
対象がどの程度あってそれぞれがどの程度のリスクなのか、
に大きく寄るので。その辺りで根本的に前提の違いがあったみたいなので、
混乱させてすいません。
等しい分散を持つ分布を畳み込んだ場合に分散が独立でない場合に比べ
適当に分散するのは、単に手を広げて管理の手間が増えるだけだろう、
と言ったことです。
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に言ってアドセンスかなんか作ってるらしい）、あれもまぁ適当なパス空間で平均とるだけって感じがするし…。
画像処理とかでマルコフ確率場の統計物理学的な解析（イジングモデルとかポッツモデルとか出てくるアレ）でレプリカ法とか繰り込み群とか使ってるのも見たことあるけど（結構前の研究だからきっと今はもっと進んでいるはず）、企業で使うことってあるのかなあ。結局性能はあんま変わらないからもっとシンプルなモデルでいいよとかなってそう。だったら物理の奴なんかいらねーじゃんみたいな。
これは…どうなんだろうか？
普通に日本の伝統的新卒採用でそういう会社に行く人はいるけど、やってることは工学とかあるいは良くわからない専攻の人と同じな気がする。これはちょっと曖昧だけど。
これはガチだね。
特に情報系の分野は実装力で評価されることが多いし…。実装力は数値計算得意とかそういうのとは全く別のスキルだよね。プログラミングマニア的な要素が必要。
あとはまぁお決まりの暗号分野とかもあるけど、暗号じゃそんなにイス無いだろうし…。
最近はやっぱデータマイニング系に流れてるのかなあ。あれも数理的な素養というよりは職人芸的な色彩が強いけど。
という感じで実際問題厳しいなあと思います。
マジレスすると、純粋数学とか理論物理は意外とつぶしが利く。特に理論物理で数値計算ができる人はいろんな分野に対応が可能。
信号処理とか制御とか機械学習は物理からネタ引っ張ってきてたり、工学としては例外的に高度な（物理の道具としてはまあ普通の）数学を使ったりするので、理論物理の人は実はポテンシャルが高いよ。
あと勿論、理論物理の人は重工業方面でも引き合いが強いだろうしね。
ただ、採用現場では必ずしも好かれるとは限らないのでコネがないと厳しいかもね。とはいっても、純粋数学や理論物理を本気でやれるレベルの大学なら他学部の知人なんかで探せば見つかるだろうけど。
人によってそれぞれ。
・言語そのものにワクワクする人
・ハードを動かす事にワクワクする人
・ソフトを動かす事にワクワクする人
・プラットフォームに興味はないが、作りたいものがある人
・面倒な数値計算をミスなく短時間で終わらせる必要に迫られている人
・同じ作業を繰り返し行うことに疲れていて、誰も問題視していない事に憤りを感じ、改善する意欲のある人
上記のいずれかに該当する人は、勝手にもりもりと弄ります。
そのどれにも該当しない場合、一度胸に手を当てて、「何故今プログラムをやるのか」を問う必要があるでしょう。
一般的には、上から４つくらいが順当な理由ではないでしょうか。
「作りたいもの」はそれこそ多岐にわたりますね。
作った後に公開して後悔、そしてそれを改善していく、なんてフローが「練習してライブして」にあたりますかね。
練習で必要なのは、「やりたい事をこんぴゅーたにやらせる時、どの様なアプローチを取るか」きちんと設計することです。
そこができれば、後は設計を実装するのみとなりますが、ここで初めて言語の出番になります。
