アカウント名:
パスワード:
今は無きbitの別冊か何かでこの行列演算拡張を知ったとき, 丁度仕事でHPCをやっていたこともあって, いかにFORTRANらしいというかHPC向けの機能だと思いました.
この機能って, 確かに書く方から見てもエレガントに書けるという利点が有るのですが, コンパイラ側から見ても余計なプログラム上の意味解析を行わずにダイレクトに並列化・ベクトル化に持っていけるので楽なんですよね. 逆に言えば, 行列演算記述が難しいプログラムはそれだけチューニングが難しいってことで.
使ってます． 標準コーディングルール [mri-jma.go.jp] が Fortran 90 を前提にしているので．
フリーフォーマット，型宣言，モジュールが良いです．
コンパイラは，Intel の free のやつを使っています． このコンパイラが使えたから，Fortran 90 に移行したといっても 過言ではありません．
ごくろうさまです．
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
2get成功！ (スコア:2, 興味深い)
これって、つまりそれだけFortran90/95のコミュニティーが育ってきたということなんでしょうか？
私、Fortran90のコンパイラが出始めたころに新機能がどんなものか見るためだけに使ったことがあるのですが、あまりに拡張されすぎてついていけないって気がしました。
普段Fortran90/95で書いている人って/.Jにどれくらいいます？
特にどんな機能を使ってますか？ 「これが使いたくて私は Fortran90/95に乗り換えた」ってのを教えてください。
あぁ、「ン」が消えてるんですよ。「ビーフン・カレー」ね。
Re:2get成功！ (スコア:5, 興味深い)
情報科学屋ではないので事実誤認があるかもしれませんが，
ここ 5 年くらいの流れを見ていると，分散メモリ型の大型計算機が
ベクトル型スーパーコンピュータを置き換えるように普及していったことに
ともない，Intel が Linux 版非商用無料の Fortran95 コンパイラ (ifc) を
配布することで，それを後押しした感があります．
外出先でのノートPC，研究室のWS，そして計算機センターの大型機まで
同じコンパイラを放り込んでおいて使えるということは，
デバッグなど実質的な作業過程において相当便利なことだと思います．
77でなく90を使うことのメリットは，まずはソースの書きやすさかと．
行番号とさようなら，構造体，do .. end do で済むループ，
多次元配列の演算が A = B + C で済んでしまうなど楽，
allocate で動的配列の生成，include などプリプロセスの充実，
など，Fortran77には戻れません．
で，数値計算のソースコードを書くのにFortranを使う理由ですが，
今は，上に述べた ifc の存在と，ベクトル化，並列化のときに
便利な言語であること，その計算機環境において最も高速なコンパイラと
ライブラリが Fortran 用としてチューニングされている，
ということに尽きますかね．
HIT さんのページを見たら，熱いものが伝わるかも．
http://www.hpc.co.jp/
書きやすさ (スコア:3, 興味深い)
> 多次元配列の演算が A = B + C で済んでしまうなど楽，
これ良いですよねー。ベクトルや行列の計算が非常にすっきり書けるし、その分エンバグも少ない。
ご存じない方のために簡単に説明しますと、
for (i = 1; i ＜ n; i++) { B[i] = A[i-1] + A[i] }
for (i = 1; i ＜ n; i++) { A[i] = B[i] }
という、自分の周囲の値から次のステップの値を決めるという頻出パターンが、
A(1:n-1) = A(0:n-1) + A(1:n)
と書けるという事です。一時保存用の配列(B[i])も不要です。
Fortran90は、数値計算に特化して進化したので、UIとか文字列操作など不得意な部分が重要でないなら、良い選択肢だと思います。
ちなみに、旧航空宇宙技術研究所が（会員制ながら）ソースを公開して開発しているCFDコードUPACS [ista.jaxa.jp]は、Fortran90で書かれているそうです。
訂正 (スコア:1)
× A(1:n-1) = A(0:n-1) + A(1:n)
○ A(1:n-1) = A(1:n-1) + A(0:n-2)
このように、配列の始めと終わりの部分は依然として間違えやすいわけですが、それはどの言語でも同じと言うことで。
Re:書きやすさ (スコア:1)
今は無きbitの別冊か何かでこの行列演算拡張を知ったとき, 丁度仕事でHPCをやっていたこともあって, いかにFORTRANらしいというかHPC向けの機能だと思いました.
この機能って, 確かに書く方から見てもエレガントに書けるという利点が有るのですが, コンパイラ側から見ても余計なプログラム上の意味解析を行わずにダイレクトに並列化・ベクトル化に持っていけるので楽なんですよね. 逆に言えば, 行列演算記述が難しいプログラムはそれだけチューニングが難しいってことで.
Re:書きやすさ (スコア:0)
こういうの良いですね。
これに比べて、最近のC++は、STLを使いすぎて常人には理解できない領域に達しつつあるのはいかがな物かと・・・。
演算子オーバーロードで行列の計算の記述が簡単とか言っていた時代は平和だったなぁ・・・。
77か9xか？ (スコア:1)
んだから77と9xの違いも正直わからないんですが...
今あえてFortran使っている人も勿論いるとは思いますが、ン十年前に作ったプログラムを延々使い続けているようなケースでは、新しいバージョンにあえて移植するよりは、古い環境のまま使いつづけるというケースの方が一般的のような気がします。
こーいう所では、77のまんま残してくれ～、という悲鳴が聞こえて来そうな気もします。
...と思ったけど、そーいうところの人はgccなんか使わんよなあ。
SolarisだかHPだかの純正コンパイラを有難がって使っているんじゃないかなあ。
今あえてFortran90/95使っている人のご意見も聴きたいなあ。
Re:77か9xか？ (スコア:2, 参考になる)
今FORTRANを使っている人というのはHPCをぶんまわしたりする人だけ（極論？）ですが，
そういう人たちは本番ではもちろんGCCなんて使わない，というか，並列化のサポートがない
GCCを使っても意味がないと思います．
でも自分でスクラッチからプログラムを書き起こす場合，最初から本番用のマシンで書く訳
ではないです．
普通は研究室レベルのワークステーションでプログラムがちゃんと動くかどうかを検証して
その後並列化のチューニングをするはずですが，最初の開発の段階でフリーのコンパイラが
使えるととてもありがたいし，そこでGCCの出番になるんじゃないかと．
FOTRAN90 [hokudai.ac.jp]での変更点は大きく，その結果拡張されたポインタや再帰関数は便利なので
今更FORTRAN77には戻れないし，教育用やパイロット開発にコストのかかるコンパイラは
使えない，そういう意味ではGCCがFORTRAN9xに対応してくれるのはようやくか，という気も
します．
まあポインタを使われると自動並列化が全く使えなくなるのでFORTRAN77に留まっていた方が
幸せな場合も多いと思いますけれど．
kaho
Re:77か9xか？ (スコア:1, 参考になる)
また、教育の現場で新たに Fotrtan を教える際に 77 を教えているところはないと思います。いきなり、77 の計算コードを渡されて習ったものと違いに困惑してる学生をよく見ます。
さらに、最近はコンピュータの値段も安くなって来て、dual cpu のコンピュータも簡単に手に入るので、並列化 + Fortran 9x に乗り換えが進んでいる気がします。
そんなわけで、次の世代までには 77 はなくなるのではないかと思います。
Re:77か9xか？ (スコア:2, 参考になる)
確かに文法も古くさいですが、「プログラミング」を教えるのではなくて、たった3回の講義で「データ解析」のツールを教えているという立場からだと、Fortran77 くらいの簡単さと不自由さは、教えるのにちょうどいいのです。できることが少ない = 覚えなくてはいけないことも少ない、ので。
個人的には g95 に移行していましたが、まだバグが多かったのと、最近までインストールに手間がかかったことから、うちでは導入が遅れていました。学生が自分でインストールできるものを勧めたい、という観点からです。来年はどうしよう。
Re:77か9xか？ (スコア:1)
今でも普通に教えられています。
Fortran77しか知らないような先生が教えていることもありますので、
仕方ないのかなあ、という気もします。
たとえば「ニュートン法」のコードを書くのは、CでもJavaでもFortran77
でも、大差ないといえばそうですしね。
Re:77か9xか？ (スコア:1)
Fortran77でした。
おまけに、情報教育機構のLinux端末を使って講義してましたが
他の環境で動作確認したプログラムが、端末により走ったり走らなかったり。
まあ、プログラミングの作法を学ぶという意味では何でも良いといってしまえば
それまでですけれど
Re:77か9xか？ (スコア:0)
>仕方ないのかなあ、という気もします。
そんな先生がCの初歩を教えてくれたおかげで、
次の段階のプログラミング実習のTAでエライ目にあった、
ってな事があります。
Re:77か9xか？ (スコア:0)
そういう人は Fortran77 のこともちゃんと知ってるわけではない
場合が多くありませんか？
単に特定の処理系でモガいた経験があるってだけで、どの部分が処
Re:77か9xか？ (スコア:0)
と、皆が思っているのでいつまで経っても無くならないかも。(笑)
書き換えてる間、その他の作業が滞ってしまうので研究に差し支えますから、皆嫌がるんですよね。
Fortranを使うのは主に情報系以外の工学部でしょう。
そういう研究室では、教授自身がFortran77しか使え
Re:77か9xか？ (スコア:1, 興味深い)
> 研究に差し支えますから、皆嫌がるんですよね。
私もまとめてC/C++に書き換えたいのですが、根性と実力が伴いません。
なんというか、Fortran77の真の恐ろしさは今まで稼動してきた歴史なんですよね。
たとえばNASAで計算に用いられてきたコードは
大きな改変なしに何十年と生き続けているわけですから。
私が関わっているコードは、さすがにそこまで実績のあるコードではありませんが、
正直、研究室の過去の実績にまで責任をもつのではなく、
自分の関係するコードだけ好きな言語で書くほうがなんぼか楽です。
> Fortranを使うのは主に情報系以外の工学部でしょう。
> そういう研究室では、教授自身がFortran77しか使えなったりするので77を使い続けていたりします。
> 講義もそういう教授が担当するので、もちろんFortran77です。
Yes.Yes.Yes.
> シミュレーションに対して意欲的な教授は、
> 既にCやその他の言語に移行してるんじゃないんでしょうかね。
プログラミングに対して意欲的と言い換えた方が適切かと思います。
シミュレーションを専門とする研究室でも年輩の先生になると
プログラムのテクニカルなレイヤーには口を挟まずに
上がってくる結果に対してだけコメントする教授が大半だと思いますので。
Re:2get成功！ (スコア:1, 参考になる)
使ってます． 標準コーディングルール [mri-jma.go.jp] が Fortran 90 を前提にしているので．
フリーフォーマット，型宣言，モジュールが良いです．
コンパイラは，Intel の free のやつを使っています． このコンパイラが使えたから，Fortran 90 に移行したといっても 過言ではありません．
Re:2get成功！ (スコア:0)
無料とfreeは違いますよね。
#と一応言っておくテスト。
Re:2get成功！ (スコア:1, すばらしい洞察)
freeですよ。
>無料とfreeは違いますよね。
いろいろな意味のある言葉ですし使い方も人それぞれ。
少なくとも無料であることをfreeと書いてはいけない、などという規則は一般常識としては存在しませんよ。
Re:2get成功！ (スコア:1)
少なくとも英語の free には無料という意味もあります。「free」じゃなくて「フリー」だったら微妙ですが、「フリーソフト」=「無料のソフト」と思っている日本人がたくさんいそうだから、日本語のフリーでも無料の意味に使えるかな?
Re:2get成功！ (スコア:0)
http://www.intel.com/software/products/compilers/flin/
Re:2get成功！ (スコア:0)
#と一応返しておくテスト。
Re:2get成功！ (スコア:0)
ごくろうさまです．
Re:2get成功！ (スコア:1)
構造体のような高度な型宣言だとか、allocate が使えることです。
今までデータ毎にいちいち配列を固定で宣言したプログラムを書いていましたが、g95 を使って、全部 allocate を使った汎用プログラムに移行できました。これでプログラムの再利用がどんなに楽になるか....
構造体のような型を定義できるのも非常に助かります。
データの欠測、不良値などのフラグを構造体に保持させておけば、いちいち別の配列を用意しなくてすみますので。演算子のオーバーロードも使って、構造体同士の演算を、意識せずにできるのも大助かり。
問題は、いままで存在する大量の g77/f2c 資産を移行するのにどのくらいの時間がかかるかです。研究分野によりますが、わたしどもではやっと Fortran90/95に移行できてきたところで、これから本格的に使われそうです。ここいらで気合いをいれて過去の資産を移行するかな。