投稿者「matsuo」のアーカイブ

News


ここは松尾宇泰のＨＰです．

数値解析学，特に微分方程式の構造保存数値解法を専門としています．
研究内容については上のメニューから「研究」をご覧ください．業績は「研究業績」にあります．

数値解析は，現代科学を支える「縁の下の力持ち」で，あらゆる分野に応用を持ち，かつ，様々な数学，および計算機の深い理解を必要とする興味深い学問分野です．学生さんの新規参入を歓迎します．

また，応用分野における数値計算でお困りの方は，ぜひご相談ください．

現在，このページをスマートフォンで表示すると[menu]ボタンが動作しません．「数値解析2019」の講義HPは左のリンクから飛んでください．

 

 

 

 松尾が研究代表者となり，数理３研メンバーが中心となって，京都大学数理解析研究所共同研究集会「諸科学分野を結ぶ基礎学問としての数値解析学」を2019/11/6～11/8に開催しました．会は盛況のうちに終わりましたが，数値解析学と諸科学の融合を予感させる講演が並んでいますので，ぜひプログラムをご覧ください．後日，数理解析研究所講究録が出版予定です．
2018/2/28 ワークショップWorkshop on recent progresses in modern numerical analysisを2018/3/12に開催します．ぜひ皆様ご参加ください．
2017/3/25 元指導学生の宮武勇登氏（現・名古屋大学）が日本数学会2016年度応用数学研究奨励賞を受賞されました．おめでとうございます．
2016/3/25 指導学生の中村健吾君（B4）が工学部長賞を受賞しました．おめでとうございます．
2016/3/24 指導学生の佐藤峻君（M2）が研究科長賞を受賞しました．おめでとうございます．
2016/3/2 H. Kojima（３研元学生）および D. Furihataと共著の論文 “Some Discrete Inequalities for Central-Difference Type Operators”がMath. Comp.に受理されました．
2015/7/9 S. Sato （３研学生），H. Suzuki（３研准教授），および D. Furihataと共著の論文 “A Lyapunov-Type Theorem for Dissipative Numerical Integrators with Adaptive Time-Stepping”がSIAM J. Numer. Anal.に受理されました．
2015/6/22 2014年9月開催の日本応用数理学会年会講演に関して，宮武勇登さん（元指導学生；現名大助教），および佐藤峻君（現M2）が日本応用数理学会若手優秀講演賞を授賞しました．おめでとうございます．
2015/3/24 指導学生の宮武勇登君（Ｄ３）が研究科長賞を受賞しました．おめでとうございます．
2015/3/24 指導学生の小島広樹君（Ｍ２）が研究科長賞を受賞しました．おめでとうございます．
2015/2/26 S. Sato （３研学生）と共著の論文 “An analysis on the asymptotic behavior of multistep linearly implicit schemes for the Duffing equation”がJSIAM Lettersに受理されました．

続きを読む →

ファイル名の付け方

ファイル名なんて好きなように付ければいい，と思うかもしれないが，そうでもないこともある．特に，研究上ファイルをやりとりするときは，ファイル名に関して一定の注意が必要だ．これは状況にもよるので，よくある「良くない例」を挙げつつ，ちょっとこの点を説明してみたい．

●学会などにファイル（PDF）を提出するとき：
予稿をPDFで提出せよ，ということがよくある．そういうとき，paper.pdfとか，（学会名）.pdf（たとえばJSIAM.pdfなど）とかでファイルを準備する人をよく見かける．だが，落ち着いて少し考えてみて欲しい．主催者は，そういって送りつけられた何十もの（下手すると何百もの！）paper.pdfと格闘する羽目になるわけである．そういうgenericな名前は避けるべきだ．

よってMatsuo.pdfなどにすべきであるわけだが，主催者には（私のような）粗忽者もいて，ファイルをデスクトップに散らかして，あとで「なんだっけ？これ？」と思うこともあるので，どうせなら，もう少し親切にJSIAM_Matsuo.pdfなどとするとよい．親切な人間は愛されるものである．JSIAM14_Matsuo.pdf（年数入り）とするとさらに親切である．

なお，何らかの理由で改訂したものを再送するときは，JSIAM14_Matsuo_v2.pdfとか，JSIAM14_Matsuo_140715.pdfとか，区別するのがよい．
JSIAM14_Matsuo_final.pdfと付ける人もいるが，そのfinalのあとにさらに改訂が必要になると状況は実に混乱するので，私はあまり好まない．（論文投稿後の「投稿した最終バージョン」という意味で付ける場合はＯＫ．）

●共同研究者と執筆原稿をやりとりするとき：
何人かの人と共同研究をしていて，同じTeX原稿を何人かで加筆訂正していくときは，いまファイルの操作権を持っているのが誰かをはっきりさせないと混乱する．これはファイル名の問題ではないが，共同執筆時に最初に明らかにしておくべきことである．（なお，dropbox+CVSとか，githubとか，もっとインテリジェントに共同執筆するやり方もあるが，本を書くとか，よほど大がかりなソースになるのでない限り，そこまでする意義はあまりないように個人的には思う．）

操作権をはっきりさせたとして，次に，実際にファイルをやりとりするときであるが，「何のプロジェクトのファイルか」「誰がいじったファイルか」「いつのバージョンか」が分かるようにするとよい．例えば，AさんとBさんと松尾で，SIAM Numer. Anal. (SINUM)に投稿しようとしているときは，SINUM_ABM_TM140715.texなどである．”ABM”は著者グループ，末尾の”TM140715″は，T. Matsuoがその日付に書いたバージョン，ということである．同じ日にさらにファイルを再送するときは，その後ろに”v2″，”v3″をつけたりする．もちろん，こういった流儀は色々やり方があるので，著者同士で相談して納得できるものがあればそれでよい．

とにかくやってはいけないことは，同じファイル名で，違う内容のファイルが量産されることである．そうなると，もう収拾がつかない．（ファイル名でどうにかする，というのがいやな人は，あきらめてCVSなり何なりを使うことを推奨する．）

なお，私は，学生さんが送ってきたＰＤＦを添削して送り返すとき，同じルールで”TM(日付)”を付けています．これは，送られてきたファイルと区別するためです．

●卒論や修論発表のファイルを用意するとき：
みんなが卒論.pptxなどというファイル名でスライドを用意してきて，会場でいざ一台のＰＣにまとめようとして大混乱，という光景をよく見かける．すでに述べたように，そんなgenericなファイル名では混乱が生じるのは，予め想像してみればすぐに分かることである．誰のスライドか分かるような名前を付けておくこと．
（ファイル名に限らず，何かを準備するとき，「その準備に基づいて本番に突入したとき，どういうことになるか」を想像してみる，というのは，とてもとても大事な「生きる力」である．）

●その他：
以上，要するに判別力のあるファイル名を付けなさい，ということである．ただ，判別力だけを重視して，いたずらに長いファイル名，たとえばJSIAM_2014_Takayasu_Matsuo_abstract_2nd_version.pdfとかを付けるのはいかがなものかと個人的には思う．

ファイル名に全角文字（マルチバイト文字）を使って良いかどうかは，微妙なところである．使った方がわかりやすい場合もある．他方，文字コードでトラブルになることもある．（環境が変わると正しくファイル名が見えないとか，何らかのシステムにファイルを通すとき，マルチバイト文字が処理系を通らない，とか．）　以前書いた「改行問題」と一緒で，この点もいずれ常識が変わっていくのかもしれないが，この文章を書いている時点では，外に出すファイルにはマルチバイト文字は使わない方が安全であると思う．

ファイル名に「空白（スペース）」や「（２つ以上の）ピリオド」を含んで良いかも，デリケートな問題である．いまは大抵の処理系で大丈夫だとは思うけれど，歴史的には「ファイル名はスペースを含んではならない」「ピリオドは，拡張子の前のひとつだけ」という時代が長かったので，誤動作する場合がないとは言えない．入れなければならない明確な理由があるのでない限り，避けた方が無難であると思う．

改行問題

改行するか，しないか，それが問題だ．

といってもいま書いている論文の話ではない．メールの話である．メールの本文は，改行すべきか，するべきでないか．これはかなり深遠な問題である．私が認識している現状は以下のとおりだ．

  • もともとは，メール本文は70文字（半角）程度で改行「すべき」であった．このことは，この種の業界標準を定めたRFCにもちゃんと書いてある．これを踏まえて，一昔前のメールクライアントは，規定の文字数で自動的に改行を入れてから送信するものが多いし，一定の年齢以上の人（すくなくとも私より上）は，メールの本文とは改行を入れるものだと思っている．
  • しかし，gmailなどの「横幅可変な」メール環境では，テキストに明示的に改行が入っていると変なところで表示が切れてしまい，かえって不便である．そこで，メールを書くときは，段落分けの改行以外の改行は入れる「べきでない」と思っている人もいまは多い．

そもそも昔はなぜ改行を入れていたのか．色々理由はあろうが，「昔はデータストリームが細く，『短い一行単位』でデータ通信を行っていたので，改行を入れずに超長い文章を送ると，どこかでこける恐れがあった」「昔は，そもそも端末が『80文字×??行』と固定サイズだったので，それを基準に物事を考えればよかった」というあたりが主な理由ではないだろうか．RFCはそれを根拠に定められたものであるし，少し前までは，改行をせずに長い文の入ったメールを送ると，上司（先生）から丁重な「指導」が入るのが常であった．

しかし，いま，ＰＣ上でも「メールクライアントの横幅」は人それぞれてんでばらばらだし，スマホの類いに至ってはせいぜい数十文字しかないのだから，どの環境でもそれなりに見えるには，「改行を入れず，クライアント側に表示を任せるのがよい」という考え方は，なるほど頷けるものである．この視点から，いまは私も，学生さんが送ってきたメールに対して特に「改行しなさい」とは言わないようにしている．実際，いま私が書いているこの文章だって，クライアントブラウザの表示に任せているのであって，（段落分け以外の）改行を明示的に入れたりしていない．

ただ．．．世の中，「だったら改行しない，でいいじゃない」と簡単に割り切れないのが難しいところだ．いまはまだ過渡期なのであって，「改行すべき派」と「改行すべきでない派」にはそれぞれ正当な理由がある．これは２つの意味においてである．

  • まず，メールクライアント自体が，実はまだ過渡期にある，ということ．例えば私が使っている某雷鳥メールクライアントは，「改行なし」のメールを受け取ったとき，
    • 平文であればクライアントのウィンドウ幅で折り返して快適に表示してくれるが，
    • 引用文のときはなぜか放置プレイで横スクロールバーを表示してしまう．

    よって，「改行なし」のメールを引用したメール．．．を受け取ったとき，私は毎回，一生懸命スクロールバーを使って原文を読んでいるのである．（かなりの苦痛！←なにかいいプラグインとかでどうにかなるなら誰か教えてください．）そういうクライアントを使う方が悪いのだと言われればそれまでだが，それを言ったらgmailなどのクライアントだって，「改行あり」のメールをintelligentに改行を削除して段落表示してくれるわけではないわけだから，どっちもどっちである．

  • つまり，どう書いたところで結局誰かにとっては不便なのである．だから，「メールは改行するものである」と教えられてきた年長組が「改行する派」から動かないのはやむを得ないし，反対に，生まれたときからgmailやスマホが標準であった若者組が「改行しない派」を合理的と考えるのも自然なことである．重要なのは，この２つが混在している，という事実を正しく認識することであろう．（「住みやすい社会」とは「『正しい』価値観で統一された社会」を言うのではなく，「色々な価値観があって，それでいてどうということもない社会」のことである！（この台詞は本質的に作家の橋本治による））

結局，改行に関するメールの「マナー」とは，いまの時代何なのであろうか．上述のとおり，すくなくとも現時点では確固たる答は出せないように私には思われる．強いて申せば，本来「マナー」とは固着した特定の流儀を指すのではなく，「相手が心地よい流儀であること」のはずだから，その原則に立ち返れば，改行する派の人には（その人の改行幅に合わせて）改行したメールを送り，しない派の人にはしないメールを送る，というのが最良なのであろう．

で，私自身の現在の流儀であるが，上に述べた適応的なやり方を実行している余裕もなく，結局私はいまだに「７０文字程度で改行する派」から動けていない．これには，年取って新しい流儀に移るのが面倒だから，とか，私より年長の方々（＝私がより敬意を示すべき方々）が同様だから，とか色々理由があるのだが，それを言っても詮無いことは上に申したとおりで，それで自分が正当化されるとは思っていない．

ここからが，この駄文で最も言いたかったことで，私のメールを受け取られる方の中には，「改行すべきでない派」の方ももちろんたくさんいて，こいつのメールはいつも変なところで改行があって読みにくいな，と思っておられるのでしょうが，まあそのとおりで返す言葉もないのですが，これは私なりに悩んで「選択」した結果なので，そこら辺の事情をご賢察の上，寛大にご笑覧いただければ幸いなのであります．（たまに，気まぐれに「改行しない派」の人のメールに，「改行しない派」で返すことはあります．）

googleカレンダーに予定を一括登録する方法

googleカレンダーに，毎週ある予定などを書き込むとき，ひとつのやり方は

  1. まず最初の週の予定を普通に登録する
  2. 次に，その登録した予定を「予定を編集」で開き，「その他の操作」から「予定を複製」を選択．新しい（複製する）日付を入力する

で，次々と予定を増やしていくことです．

しかし２～３個ならともかく，１０個を超える予定をこれで入力するのは骨が折れます．そのときは，次のようにしてCSV形式のファイルから一括登録すると便利です．EXCELを使います．

  1. 次のEXCELシートをダウンロードします：
    google_calender_schedule.xlsx（ダウンロード後，名前は適当に変更してよい）
  2. このEXCELシートを開いて，予定を書き込みます．見れば分かると思いますが，一行だけサンプルの予定を入れてありますのでそれを参考にしてください．EXCELなので，行をコピーして予定を増やすのは簡単です．
  3. すべての予定を書き終えたら，[名前を付けて保存]で「CSV形式（カンマ区切り）」を選択して保存します．
    【重要】CSVファイルは漢字コードUTF-8にする必要があります．お使いの環境で，Shift-JISなどで保存される場合は，エディタ等で一度CSVファイルを開き，エンコードをUTF-8に変更して保存し直してください．
  4. google calenderをウェブで開き，[マイカレンダー]の右側の「▼」印をクリックして[設定]を選択します．
  5. [カレンダーをインポート]を選択し，上で作成したCSVファイルを選択します．マイカレンダーに複数のカレンダーを設定している場合は，どのカレンダーにインポートするかも選択します．最後に[インポート]をクリックします．

これで，指定した予定が一気にカレンダーに書き込まれます．

上ではEXCELを使っていますが，CSVファイルの書き方を知っていれば，テキストエディタで直接CSVファイルを作ることもできます．が，EXCELを使う方がラクでしょう．

なお，上の最後のステップで，「以上の予定をカレンダーに書き込みますか？」などの確認は一切出ないので気を付けてください．一旦読み込んだ予定を取り消すこともできません．CSVファイルの中に一部不正な行があった場合，その行は飛ばされますが，どの行に不正があったかも教えてくれません．ひとつひとつ書き込まれた予定をチェックして，どの予定がスキップされたかを手動で探す必要があります．

また，上で述べたように漢字コードをUTF-8以外にしていると，読み込んだ予定が盛大に文字化けします．そのときは，「一括取り消し」という手順がないので，手動ですべて削除しなければいけません．そのため，一度に登録する予定は１０個程度にとどめておくのがお勧めです．100個以上の予定を書き込みたい場合は，手数がかかりますが，いくつかに分割して登録するのがよいでしょう．

このように，いささかインターフェイスに問題はありますが，しかしかなり便利な機能ですので，ぜひ使いこなしてみてください．