アカウント名:
パスワード:
物理屋です。毎日Fortranを使ってます。他にはsh, C, Rubyがまあまあ書けます。さいきんのFortranはいろいろなことができるので使っていて楽しいです。gfortranとg95というfreeで使いやすいコンパイラもありますし。物理か化学をやるんなら、知っていて損はない言語なんじゃないでしょうか。
Fortranについて思いついたことを箇条書きにしてみます。* implicit none は使えよ* module は common の代わりに使うな* いいかげん大域変数（的なもの）を使うのはやめろ* 自由形式 (free form) で書け* 構造体 (type) を使え* 配列の範囲が自由 a(1:N), a(0:N-1), a(-N+1:N), a(3,0:N-1,0:N-1) とか* 配列の演算が楽* module, interface を使えばsubroutoneの引数の不整合によるバグが避けられる* オブジェクト指向プログラミングしろ。Frotran2003ではもっと機能が強化される* 複素数がはじめから使える* 数学関数が豊富。C99と同じ数はあると思う* 拡張子を .F にしておけばCプリプロセッサが使える* make(1)にはFCとかFCFLAGSとかFortran用の機能もあるんだよ* autotoolsにも* LAPACKとかFFTWとかライブラリが豊富* ポインタも使えるけど、そんなに必要ない。リスト構造を作るときぐらいかな* 基本、参照渡しだから* 動的にallocateした配列は基本的にはsubroutineの最後で解放される* 関数が配列を返せる [srad.jp]* read/write/他 でテキスト処理も実はまあまあできる* OpenMPで並列化できる* command_argument_countとget_command_argumentとでコマンドライン引数も扱えるようになった* FORTRANとFortranは使い分けてくれ* スパコンで使える。Cも使えるけど* いろいろな言語に挑戦してみてはどうか
同じく物理や化学で計算を生業にしている者です(某日本最大の計算機を作るプロジェクトでもお世話になっています)。20年近くやってきたゴリゴリの「高速計算屋」です。
* implicit none は使えよ→同意。ケアレスミスをふせげる。
* module は common の代わりに使うな* いいかげん大域変数（的なもの）を使うのはやめろ* module, interface を使えばsubroutoneの引数の不整合によるバグが避けられる→物理や化学の計算だと、一番重要な配列。たとえば、その系の原子の持つ情報は 大域変数で持つ方がプログラミングしやすいと思う。 同時にそれはパラメータスタディするときに可変となり、allocateするものだから、* 動的にallocateした配列は基本的にはsubroutineの最後で解放される→これは変だということになる。
* 自由形式 (free form) で書け* 配列の範囲が自由 a(1:N), a(0:N-1), a(-N+1:N), a(3,0:N-1,0:N-1) とか* 配列の演算が楽* 複素数がはじめから使える* 数学関数が豊富。C99と同じ数はあると思う→同意。FortranはFORTRAN77から見ると、かなり進歩した言語なのです。
* 構造体 (type) を使え→現状の並列計算環境においては、自動並列化に失敗することがあるので、typeは 今ひとつ信用できません。
* オブジェクト指向プログラミングしろ。Frotran2003ではもっと機能が強化される→まあ、そうですね。ただ、我々がFortranを使う理由は「大きな計算機で最適化されていて 速い」からであって、柔軟なプリ・ポスト処理にはrubyなどで対応したらいいと思っています。
* 拡張子を .F にしておけばCプリプロセッサが使える* make(1)にはFCとかFCFLAGSとかFortran用の機能もあるんだよ* autotoolsにも* LAPACKとかFFTWとかライブラリが豊富→これはそのとおり。結局、Cを使う理由はシステムコールを多用したりするプログラムであって、 ゴリゴリの数値計算はFortranで書いて、Cプロプロセッサで環境、計算条件に応じて コンパイルしなおせるようにしておけば十分だと。
* ポインタも使えるけど、そんなに必要ない。リスト構造を作るときぐらいかな* 基本、参照渡しだから→はい、そのとおり。あと、我々はとにかく不器用でも速いプログラムを書きたいので、 自動ベクトル化の阻害因子になるポインタの必要性はあまりないです。
* OpenMPで並列化できる→同意。というか、速い数値計算プログラムを楽に書く環境としてFortranは進歩してきたのだから当然。
* command_argument_countとget_command_argumentとでコマンドライン引数も扱えるようになった→まあ、数値計算プログラムは硬派なので、引数はパラメータを列記したファイルで十分なのですがね。
* スパコンで使える。Cも使えるけど→結局、ハイエンドの数値計算サーバのコンパイラのチューニングを、何言語で行うか、 ということに尽きるかと。現状では、Fortranがデフォルトです。
* いろいろな言語に挑戦してみてはどうか→物理や化学、あるいは流体などの数値計算以外の専門家になるんだったら、いろんな体験が必要でしょう。 あとは、プリ・ポストのためにいろんな言語は使えるほうがいいでしょう。 私は何よりFortranとrubyです。外国の人はFotranとpythonですので、国際的に活躍したければ他のものも。
という感じで、アルバイトでネット関係あるいはハードウェアにアプリケーションを書いたりする場合はともかく、数値計算屋として生きていくためにはFortranは大変便利なツールなのですね。
大気関係が専門ですが、就職してずっと、今なおFORTRANが使われています。過去の資源が、というのもありますが、今なお業界標準だから、というのが大きい。
ただ、以前と違ってFORTRANでCGIを書く人は減りました。
> 大気関係が専門
ということは、気象の数値予報も Fortran でやってるんでしょうなぁ。
＃Fortran が役に立たないという人には天気予報じゃなくてバチが当たります。
>＃Fortran が役に立たないという人には天気予報じゃなくてバチが当たります。
天気予報なだけに当たるのは下駄かとオモタ
以前に別なとこで聞いたけど、２０年前に理系の現役の大学生の頃は複雑な多項式計算の類をやるのに「プログラミング電卓」をみんな持ってて、それで計算していたよーな気がするのですが、現在プログラム電卓は廃れているようで・・・
じゃあ、いまの学生は何で計算してるの？って聞くと「EXCELのマクロ」もしくは「計算してない」（！）ってのが返ってきたんですよね・・・情報工学系の人がまあ「いまさらFORTRAN?」ってのはわかるんだけれどじゃあ普通の理学／工学系の子が学部の計算するのにこれから『何を使って複雑な計算をコンピュータに計算をさせるのか』ってのはなんか実は科学技術教育の未来と深くかかわってる問題のように思うんですよねー・・・
大規模な計算ならともかく、計算量的にそこまで多くない計算ならperl,ruby,python,javascriptなどのスクリプト言語や、もうexcelでもなんでもいいんじゃないですか。それすらしない人がいるってのは、問題だと思いますが。
# maxima便利だよー！積分も一瞬だよー！
> * 複素数がはじめから使える
学生の頃は建築耐震構造分野の研究室にいたので、このためだけにFORTRAN77が必須でした。
#include <stdio.h>#include <stdlib.h>#include <math.h>int main(){}
ではじめるような、「お約束」が少ないので教えやすいとも。 # 伝聞主体なのでAC
実際、いくつかの実験では最適化がかかりやすくて、未だにCよりも速いとか。
良くも悪くも数値計算に特化してきた言語ですから、そういう用途では当たり前にCより速いです。
プログラミング入門用途としては、自分のPCに気軽に導入できるコンパイラがないのが悩みの種だったなあ。今だったらLinuxでIntel Compilerの非商用ライセンスとかありますが。
Fortranを使う理由として、言語仕様が単純なのでコンパイラの最適化がかなり効くということをFortranのヘビーユーザから聞いたことがあります。ポインタやオブジェクト指向などを使っても性能低下は無視できるレベルでしょうか？
まあ長年の研究の成果というのもあると思うけど。
ちなみに最速JVMの一つであるIBM JITは、東京基礎研でHPFコンパイラを作ってたスタッフがそのノウハウを駆使して作ったそうな。だからJava屋としてはFORTRAN（とLISP）には足を向けて寝られませんね。http://www.trl.ibm.com/news/ibm_users/trltech_08.htm [ibm.com]
そもそもF90/95のポインタはCのようなアドレスを意味する整数ではなくて,C++の参照のような抽象的なもんで, しかもポインタが指す(可能性のある)変数はtarget属性を明示しないといけないので, 適切に使用してやればコンパイラも最適化してくれます.
オブジェクト指向といってもF90/95の範囲では継承やポリモーフィズムといった概念はなく,単にまとまった要素はmodule化して, interfaceだけ共通化していけば差し替え可能でうれしいな, ってレベルです. C++のテンプレートに近い.F2003でどうなってるのかはしらん.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
さいきんのFortranは使っていて楽しい (スコア:5, 参考になる)
物理屋です。毎日Fortranを使ってます。
他にはsh, C, Rubyがまあまあ書けます。
さいきんのFortranはいろいろなことができるので使っていて楽しいです。
gfortranとg95というfreeで使いやすいコンパイラもありますし。
物理か化学をやるんなら、知っていて損はない言語なんじゃないでしょうか。
Fortranについて思いついたことを箇条書きにしてみます。
* implicit none は使えよ
* module は common の代わりに使うな
* いいかげん大域変数（的なもの）を使うのはやめろ
* 自由形式 (free form) で書け
* 構造体 (type) を使え
* 配列の範囲が自由 a(1:N), a(0:N-1), a(-N+1:N), a(3,0:N-1,0:N-1) とか
* 配列の演算が楽
* module, interface を使えばsubroutoneの引数の不整合によるバグが避けられる
* オブジェクト指向プログラミングしろ。Frotran2003ではもっと機能が強化される
* 複素数がはじめから使える
* 数学関数が豊富。C99と同じ数はあると思う
* 拡張子を .F にしておけばCプリプロセッサが使える
* make(1)にはFCとかFCFLAGSとかFortran用の機能もあるんだよ
* autotoolsにも
* LAPACKとかFFTWとかライブラリが豊富
* ポインタも使えるけど、そんなに必要ない。リスト構造を作るときぐらいかな
* 基本、参照渡しだから
* 動的にallocateした配列は基本的にはsubroutineの最後で解放される
* 関数が配列を返せる [srad.jp]
* read/write/他 でテキスト処理も実はまあまあできる
* OpenMPで並列化できる
* command_argument_countとget_command_argumentとでコマンドライン引数も扱えるようになった
* FORTRANとFortranは使い分けてくれ
* スパコンで使える。Cも使えるけど
* いろいろな言語に挑戦してみてはどうか
love && peace && free_software
t-nissie
Re:さいきんのFortranは使っていて楽しい (スコア:5, 参考になる)
同じく物理や化学で計算を生業にしている者です(某日本最大の計算機を作る
プロジェクトでもお世話になっています)。
20年近くやってきたゴリゴリの「高速計算屋」です。
* implicit none は使えよ
→同意。ケアレスミスをふせげる。
* module は common の代わりに使うな
* いいかげん大域変数（的なもの）を使うのはやめろ
* module, interface を使えばsubroutoneの引数の不整合によるバグが避けられる
→物理や化学の計算だと、一番重要な配列。たとえば、その系の原子の持つ情報は
大域変数で持つ方がプログラミングしやすいと思う。
同時にそれはパラメータスタディするときに可変となり、allocateするものだから、
* 動的にallocateした配列は基本的にはsubroutineの最後で解放される
→これは変だということになる。
* 自由形式 (free form) で書け
* 配列の範囲が自由 a(1:N), a(0:N-1), a(-N+1:N), a(3,0:N-1,0:N-1) とか
* 配列の演算が楽* 複素数がはじめから使える* 数学関数が豊富。C99と同じ数はあると思う
→同意。FortranはFORTRAN77から見ると、かなり進歩した言語なのです。
* 構造体 (type) を使え
→現状の並列計算環境においては、自動並列化に失敗することがあるので、typeは
今ひとつ信用できません。
* オブジェクト指向プログラミングしろ。Frotran2003ではもっと機能が強化される
→まあ、そうですね。ただ、我々がFortranを使う理由は「大きな計算機で最適化されていて
速い」からであって、柔軟なプリ・ポスト処理にはrubyなどで対応したらいいと思っています。
* 拡張子を .F にしておけばCプリプロセッサが使える
* make(1)にはFCとかFCFLAGSとかFortran用の機能もあるんだよ* autotoolsにも
* LAPACKとかFFTWとかライブラリが豊富
→これはそのとおり。結局、Cを使う理由はシステムコールを多用したりするプログラムであって、
ゴリゴリの数値計算はFortranで書いて、Cプロプロセッサで環境、計算条件に応じて
コンパイルしなおせるようにしておけば十分だと。
* ポインタも使えるけど、そんなに必要ない。リスト構造を作るときぐらいかな* 基本、参照渡しだから
→はい、そのとおり。あと、我々はとにかく不器用でも速いプログラムを書きたいので、
自動ベクトル化の阻害因子になるポインタの必要性はあまりないです。
* OpenMPで並列化できる
→同意。というか、速い数値計算プログラムを楽に書く環境としてFortranは進歩してきたのだから当然。
* command_argument_countとget_command_argumentとでコマンドライン引数も扱えるようになった
→まあ、数値計算プログラムは硬派なので、引数はパラメータを列記したファイルで十分なのですがね。
* スパコンで使える。Cも使えるけど
→結局、ハイエンドの数値計算サーバのコンパイラのチューニングを、何言語で行うか、
ということに尽きるかと。現状では、Fortranがデフォルトです。
* いろいろな言語に挑戦してみてはどうか
→物理や化学、あるいは流体などの数値計算以外の専門家になるんだったら、いろんな体験が必要でしょう。
あとは、プリ・ポストのためにいろんな言語は使えるほうがいいでしょう。
私は何よりFortranとrubyです。外国の人はFotranとpythonですので、国際的に活躍したければ他のものも。
という感じで、アルバイトでネット関係あるいはハードウェアにアプリケーションを書いたり
する場合はともかく、数値計算屋として生きていくためにはFortranは大変便利なツールなのですね。
Re:さいきんのFortranは使っていて楽しい (スコア:1, 参考になる)
> * 動的にallocateした配列は基本的にはsubroutineの最後で解放される
> →これは変だということになる。
もちろんご存知とは思いますが、ここでポインタの出番ですね！
> * オブジェクト指向プログラミングしろ。Frotran2003ではもっと機能が強化される
> →まあ、そうですね。ただ、我々がFortranを使う理由は「大きな計算機で最適化されていて
> 速い」からであって、柔軟なプリ・ポスト処理にはrubyなどで対応したらいいと思っています。
最近、動的に多数の分子を生成するコードを書いて初めて Fortran で OOP する必要性を感じました。PC で10分～1時間程度の計算ですみましたが、もしこれを ruby 等の LL で書いてたら、この10～100倍以上の計算時間がかかるはず。多次元配列を使った多量の数値演算と、動的にオブジェクトを生成するような柔軟なモデル化の両方が必要な領域にはモダン Fortran は最適解ですね。
> * command_argument_countとget_command_argumentとでコマンドライン引数も扱えるようになった
> →まあ、数値計算プログラムは硬派なので、引数はパラメータを列記したファイルで十分なのですがね。
namelist を便利に使ってます。少々癖はありますが、自分でパラメタファイルのパーサを書くのに比べればどれほど楽なことか...
というわけで、物理、化学等々の数値計算にはモダン Fortran は最適です。学生さんは迷わず勉強して損はないと思いますよ。
# 他にも色々書きたいことがあるけど酔ってるのでとりあえず AC
Re:さいきんのFortranは使っていて楽しい (スコア:2, 興味深い)
大気関係が専門ですが、就職してずっと、今なおFORTRANが使われています。
過去の資源が、というのもありますが、今なお業界標準だから、というのが大きい。
ただ、以前と違ってFORTRANでCGIを書く人は減りました。
Re:さいきんのFortranは使っていて楽しい (スコア:1)
> 大気関係が専門
ということは、気象の数値予報も Fortran でやってるんでしょうなぁ。
＃Fortran が役に立たないという人には天気予報じゃなくてバチが当たります。
あした天気になーれ (スコア:0)
>＃Fortran が役に立たないという人には天気予報じゃなくてバチが当たります。
天気予報なだけに当たるのは下駄かとオモタ
ここにぶらさげてみるか (スコア:1, 興味深い)
以前に別なとこで聞いたけど、２０年前に理系の現役の大学生の頃は
複雑な多項式計算の類をやるのに「プログラミング電卓」を
みんな持ってて、それで計算していたよーな気がするのですが、
現在プログラム電卓は廃れているようで・・・
じゃあ、いまの学生は何で計算してるの？って聞くと
「EXCELのマクロ」もしくは「計算してない」（！）ってのが
返ってきたんですよね・・・
情報工学系の人がまあ「いまさらFORTRAN?」ってのはわかるんだけれど
じゃあ普通の理学／工学系の子が学部の計算するのに
これから『何を使って複雑な計算をコンピュータに計算をさせるのか』ってのは
なんか実は科学技術教育の未来と深くかかわってる問題のように思うんですよねー・・・
Re:ここにぶらさげてみるか (スコア:1)
大規模な計算ならともかく、計算量的にそこまで多くない計算ならperl,ruby,python,javascriptなどのスクリプト言語や、
もうexcelでもなんでもいいんじゃないですか。
それすらしない人がいるってのは、問題だと思いますが。
# maxima便利だよー！積分も一瞬だよー！
1を聞いて0を知れ!
Re:ここにぶらさげてみるか (スコア:1)
Re:さいきんのFortranは使っていて楽しい (スコア:1)
> * 複素数がはじめから使える
学生の頃は建築耐震構造分野の研究室にいたので、このためだけにFORTRAN77が必須でした。
Re: (スコア:0)
ではじめるような、「お約束」が少ないので教えやすいとも。 # 伝聞主体なのでAC
Re: (スコア:0)
良くも悪くも数値計算に特化してきた言語ですから、そういう用途では当たり前にCより速いです。
プログラミング入門用途としては、自分のPCに気軽に導入できるコンパイラがないのが悩みの種だったなあ。今だったらLinuxでIntel Compilerの非商用ライセンスとかありますが。
Re: (スコア:0)
Fortranを使う理由として、言語仕様が単純なのでコンパイラの最適化がかなり効くということをFortranのヘビーユーザから聞いたことがあります。ポインタやオブジェクト指向などを使っても性能低下は無視できるレベルでしょうか？
Re:さいきんのFortranは使っていて楽しい (スコア:2)
まあ長年の研究の成果というのもあると思うけど。
ちなみに最速JVMの一つであるIBM JITは、東京基礎研でHPFコンパイラを作ってたスタッフが
そのノウハウを駆使して作ったそうな。だからJava屋としてはFORTRAN（とLISP）には足を
向けて寝られませんね。
http://www.trl.ibm.com/news/ibm_users/trltech_08.htm [ibm.com]
Re: (スコア:0)
そもそもF90/95のポインタはCのようなアドレスを意味する整数ではなくて,
C++の参照のような抽象的なもんで, しかもポインタが指す(可能性のある)変数はtarget属性を
明示しないといけないので, 適切に使用してやればコンパイラも最適化してくれます.
オブジェクト指向といってもF90/95の範囲では継承やポリモーフィズムといった概念はなく,
単にまとまった要素はmodule化して, interfaceだけ共通化していけば差し替え可能
でうれしいな, ってレベルです. C++のテンプレートに近い.
F2003でどうなってるのかはしらん.
Re:さいきんのFortranは使っていて楽しい (スコア:1)
継承もポリモーフィズムもちゃんとありますよ。オペレータオーバーロードもあるけど、さすがにこれはプログラムの可読性を下げてるだけのような気がしますが。
いつの間にか凄くなっていたんだ (スコア:0)
Re: (スコア:0)
Intelのコンパイラに任せると自動ベクトル化をすぐ諦めるので結局C++でintrinsicsを使わないといけないジレンマ。
# WHEREとか何の為にあると思ってるの > Intel様