研究者を目指す大学院生なら知っておきたい、天文分野のポスドクの給料の相場
学振 PD が任期 4 年間になるだとか、国立大学教員の給料が年俸制に移行するだとかというニュースを目にして、前々から気になっていたポスドクの給料の相場がどんなものか調べてみました。
- 作者: ピーター・J・ファイベルマン,西尾義人
- 出版社/メーカー: 白揚社
- 発売日: 2015/05/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
高学歴ワーキングプア 「フリーター生産工場」としての大学院 (光文社新書)
- 作者: 水月昭道
- 出版社/メーカー: 光文社
- 発売日: 2007/10/16
- メディア: 新書
- 購入: 9人 クリック: 324回
- この商品を含むブログ (231件) を見る
日本天文学会には TENNET というメーリングリストがあり、その内容は公開されています。そこに流れる情報の数割は公募情報なので、過去ログを漁るとポスドクの給料の情報が分かります。こういう情報は若手研究者や大学院生にとってとても重要なのに、あまりまとめられていない気がするので誰かの役には立つでしょう。もしかしたら大学院進学を断念する理由にもなるかもしれない。
ざっと 1 年分くらいを眺めて、まとめたものが次の表です。特任助教と特任准教授も「ポスドク」に含めましたが、ここでの「ポスドク」の定義は「退職金や賞与のない職」です。なぜ含めたかというと、特任助教や特任准教授 (大学によって「特定」だったり「特命」だったりもします) は給与形態が助教や准教授と大きく異なる場合があるからです。
表の後ろに色々と大事なことが書かれているので、スクロールしてください。
| 肩書き | 任期 (延長含) | 月給 (万円、括弧内は海外勤務の場合) | 年間研究費 (万円) |
|---|---|---|---|
| 特任助教 | 5 | 助教相当 | |
| 特任助教 | 5 | 助教相当 | |
| 特任准教授 | 5 | 准教授相当 | |
| 特任研究員 | 3 | 30 | 50 |
| 非常勤研究員 | 2 | 30 | 小額 |
| 特任助教 | 4 | 30 | |
| 特任准教授 | 5 | 50 | |
| 研究員 | 4 | 30 | 50 |
| 研究員 | 3 | 規程による | |
| 特任助教 | 3 | 規程による | |
| 特任研究員 | 2 | 33 | |
| 特任研究員 | 3 | 30 | 50 |
| プロジェクト研究員（特任研究員） | 3 | 30 (52) | 50 |
| 研究員 | 5 | 40〜58 | |
| フェロー（特任助教） | 5 | 50 (77) | 100 |
| 特任助教 | 2 | 40〜58 | |
| 特任研究員 | 3 | 30 | 50 |
| 特任研究員 | 3 | 規程による | |
| 特任助教 | 4 | 35 | |
| サポート・アストロノマー | 3 | 36.2 | |
| 特任助教 | 5 | 助教相当 | |
| 特任准教授 | 5 | 准教授相当 | |
| 特任助教 | 5 | 規程 | |
| 特任助教 | 5 | 規程 | |
| 特任助教 | 5 | 助教相当 | |
| 特任准教授 | 5 | 准教授相当 | |
| 特任研究員 | 4 | 30 | |
| プロジェクト研究員 | 3 | 30 | |
| ポストドクトラルフェロー | 1 | 27 | |
| 研究員 | 2 | 30 | |
| 研究員 | 2 | 規程による | |
| 研究員 | 3 | 規程による | |
| 招聘職員 | 3 | 規程による | |
| 特任研究員 | 2 | 規程による | |
| プロジェクト研究員 | 1 | 規程による | |
| 研究員 | 3 | 30 | |
| 博士研究員 | 2 | 25〜40 | |
| 特定研究員 | 2 | 規程による | |
| 特任研究員 | 2 | 30〜36 | |
| 研究員 | 3 | 助教相当 | |
| 主任研究員 | 3 | 准教授相当 | |
| 特任助教 | 2 | 規程による | |
| 特任研究員 | 2 | 30 | |
| 研究員 | 5 | 30 | |
| 特任助教 | 4 | 規程による | |
| 特任研究員 | 2 | 33 | |
| 研究員 | 3 | 30 | |
| 特任准教授 | 6 | 規程による | 70 |
| 特任准教授 | 6 | 規程による | 70 |
| 特任助教 | 6 | 規程による | 70 |
| 特任助教 | 5 | 規程による | 70 |
| 特任准教授 | 6 | 規程による | 70 |
| 特任助教 | 6 | 規程による | 70 |
| 特任講師 | 5 | 規程による | 70 |
| 特任准教授 | 5 | 規程による | 70 |
| 特任助教 | 5 | 規程による | 70 |
| 特任講師 | 5 | 規程による | 70 |
| 特任助教 | 5 | 規程による | 70 |
| 特任准教授 | 6 | 規程による | 70 |
| 研究員 | 5 | 37.5 | 50 |
| 研究員 | 5 | 37.5 | 50 |
| 研究員 | 5 | 37.5 | 50 |
| 研究員 | 5 | 37.5 | 50 |
| 研究員 | 5 | 37.5 | 50 |
| ポスドク研究員 | 3 | 34 | |
| 特任研究員 | 4 | 37 | |
| 特任教員 | 4 | 31〜37 |
この表の読み方は人によって色々だと思うのですが、いくつか注意点があります。
- 天文学会に流れる公募情報ということで、天文台関係の公募が多数（月給 30 万 + 研究費 50 万とか)
- 「ポスドク」と言っても、パッと見で「これは研究職ではないな」というものは除外（技術支援員とか広報とか教務補佐員の名称で、職務内容に「研究」についてほとんど触れていないようなもの）
- 後ろのほうにある研究費を 70 万とか 50 万支給するやつは、全部名古屋大のリーディング大学院関係
- 理研の募集は、給料に加えて住宅手当ありのものがあった (金額不明)
- 時給で支払いの職の場合、社会保険とかつかないものあり
- 「助教相当」や「規程による」とあるものは、公募情報には月給があらわに書いていないもの
- 特任助教で「助教相当」とか「規程による」となっているものは、実際には助教 (年齢によるけど国立大だと恐らく年 600 万弱以上) より少し悪いと思われる
- もっと低い給料のものは、そもそも公募に出さないで関係者のみで情報が回る場合もあり
研究職ではないものは除外しましたが、広報だとかサーバ管理だとかそういう仕事だと、月給 20 万円代は結構あります。
TENNET に流れる公募だと、研究員という肩書きの場合は 30〜40 万円くらいが相場のようです。年収 360〜480 万円くらいですね。
こういうポスドクの他に、給料の良いポスドクというのがいくつかあります。僕が関係するようなものや近隣分野 (天文、物理、宇宙、素粒子、宇宙線、原子核など) だと、学術振興会特別研究員 PD (学振 PD)、同 SPD (学振 SPD)、同海外特別研究員 (海外学振)、理化学研究所基礎科学特別研究員 (基礎特研)、JAXA 任期付プロジェクト研究員、日本原子力研究開発機構博士研究員が挙げられます。一般的には、これらのポスドクのほうが給料が良いです。特殊なものとして、宇宙科学研究所 (ISAS) の International Top Young Fellowship (ITY) という制度もあり、これは海外からも優秀な人材を獲得する狙いがあるので、破格の給料です。
| 名称 | 任期 | 月給 | 年間研究費 | その他 |
|---|---|---|---|---|
| 学振 PD | 3 | 36.2 | 150 (最大、普通は 100 くらい) | 社会保険・雇用保険・通勤手当なし |
| 学振 SPD | 3 | 44.6 | 300 (最大、普通の金額は知らない) | 社会保険・雇用保険・通勤手当なし |
| 海外学振 | 2 | 43.8 | 社会保険・雇用保険・通勤手当なし、科研費申請資格なし | |
| 基礎特研 | 3 | 48.7 | 100 | 住宅手当あり (噂だと 5 万円くらい) |
| JAXA | 3 | 40.36 | 業績手当あり (支給状況は知らない) | |
| 原研 | 3 | 42 | 住居手当、業績手当あり (支給状況は知らない) | |
| ITY | 3 (最大 5) | 79.1 | 250 | 住居手当あり (支給状況は知らない) |
ITY を別として、給料と研究費の面では基礎特研がずば抜けてます。ちなみに僕は D3 のときに応募して落ちました。そもそも、その年に博士論文は出せませんでしたが。
学振 PD は一見すると平均的なポスドクより良いように見えますが、学振と雇用関係にないため社会保険がなく、国保と国民年金に自分で加入しなくてはいけません。妻子持ちだったりすると、これだけで月額 5 万円はいくんじゃないでしょうか (自分はいくら払っていたか忘れました)。通勤手当もないので、必然的にチャリ通もしくは徒歩通勤になります。ただし、学振 PD の最大の魅力は上司のプロジェクトに縛られず、自分の好きな場所で好きな研究をできることですので、これは他の普通のポスドクにはない自由さです。
海外学振はそこそこ良いように見えますが、海外への引越し費用も出ませんし、配偶者が一緒に渡航する場合は配偶者は現地で労働できない場合が多いです。共働きの夫婦の場合、世帯収入で考えると海外学振は微妙な選択かもしれません。ただ、これまた好きな国、好きな研究者のもとで研究できるので、これは最大の魅力です。海外学振を経験した人の文句で一番多いのは、二年間の任期は短過ぎるというものです。現地で生活に慣れるのに数ヶ月はかかりますし、色々な事務手続きが多くて時間を消耗します。それが済んだと思ったら、もう次の職探しです。
おまけで、国立大学の助教の給料っていくらなのよと気になる人もいるでしょうから、最後まで読んでくれた人のために書いておくと、32 歳の名大の助教の初年度の年収は 600 万円ちょうどくらいでした。実際には着任半年後の 4 月から海外学振に出ているため、名大からの給料が減額されているので少ないですが、日本に居続けたと仮定すると 600 万ちょうどくらいです。これは住宅手当、賞与、扶養手当、大学院指導手当を含み、税と保険が引かれる前の金額です。震災復興なんたらで減額されているので、本当だったらもう少しだけ多いのかな。
PyVISA + NI-VISA + 32 bit Python を Mac で使う
(追記 2014.6.9) 最近の NI-VISA は OS X でも部分的に 64 bit 対応になっているので、通常使用の範囲であれば 32 bit の Python を無理やり使う必要はありません。
Python から USB 接続の実験装置を動かすときに、PySerial はよく使うんですが、VISA という規格もあって、PyVISA というので制御できます。GPIB と USB は備えてるけど GPIB を Mac で動かすのは面倒だし、かつその USB は PySerial で動かないしなんて装置があった場合、PyVISA を使うという手があります。
あと、LAN 接続も可能な機種だと PyVXI11 を使ったりなんてのも可能です。ただ、環境によっては IP 貰えなかったりすることがあるので、PyVISA を使うという解を持っているのは良いことです。
Mac の場合、まずは VISA の library が必要になります。Mac 用の VISA library は恐らく National Instruments (NI) が出しているやつしかなくて、NI-VISA をいうのを使うことになります。Mac 版の最新版は 5.4 です。
.dmg を落としてきて、Mac に install しましょう。10.7 と 10.8 に対応しています。10.9 は試していません。で、ちょっと問題があって、NI-VISA の Mac 版は 32 bit にしか対応していないので (10.8 のみ?)、PyVISA を呼ぶ Python は 32 bit のものを使わないといけません。でも PyROOT とかは 64 bit で動かしたいし、PyVISA のためだけに他の Python 関連のものを全て 32 bit にするのも敗北感があるので、PyVISA だけ 32 bit で動かしたい、と。
2. PyVISA を入れる
$ sudo easy_install pyvisa
これで PyVISA が入ります。
3. PyVISA + NI-VISA を試す
普通に Mac で Python を起動すると、64 bit のものが起動するはずです。32 bit のものを明示的に起動させるには、次のようにします。
$ VERSIONER_PYTHON_PREFER_32_BIT=yes python
さて、Tektronix の AFG3251 という function generator で実験してみます。
from pyvisa.vpp43 import visa_library visa_library.load_library("/Library/Frameworks/Visa.framework/VISA") import visa afg3251 = visa.Instrument("USB0::0x0699::0x0344::C020398::INSTR") afg3251.write("*IDN?") print afg3251.read()
PyVISA が NI-VISA の library を自動で見つけてくれないため、明示的に visa_library.load_library で load する必要があります。これをやらずに import visa をすると、ちゃんと動いてくれません。
その後、VISA の接続に必要な USB の情報を与えてやると、その USB 機器に接続できます。AFG3251 の場合は、本体のメニューを操作すると "USB0::" という情報が出てきます。
後は RS232C の制御と同じような感覚でコマンドを送信するだけです。Delimiter などのややこしい設定は考える必要がありません。
4. subprocess.Process
さて、これだと 32 bit の Python でしか動かないので、64 bit で動いている PyROOT と一緒に使うのは面倒です。ということで、subprocess.Process を使って別の process で動かします。Function generator のように低速な機器であれば、これで全く問題ありません。オシロのように転送速度が効いてくる装置の場合、PyVXI11 などを検討したほうが良いでしょう。
まずは、afg3251.py という script を用意します。これは単純に、第一引数を AFG3251 に送信し、返事を返すことを期待するコマンドであれば stdout にその結果を出力する動作をします。
#!/usr/bin/env python import sys command = sys.argv[1] from pyvisa.vpp43 import visa_library visa_library.load_library("/Library/Frameworks/Visa.framework/VISA") import visa afg3251 = visa.Instrument("USB0::0x0699::0x0344::C020398::INSTR") afg3251.write(command) if command[-1] == "?": sys.stdout.write(afg3251.read())
このファイルは chmod で実行権限を与えておいて下さい。
$ chmod +x afg3251.py
次に、process.py を用意します。これは思いっきりここの真似ですね。32 bit の Python を別 process で起動するため、os.environ に VERSIONER_PYTHON_PREFER_32_BIT を設定しています。これを設定しておけば、subprocess.Popen で別の Python を開いても 32 bit で起動してくれます。
import subprocess import os class AFG3251(object): def __init__(self): pass def excecute(self, command): os.environ["VERSIONER_PYTHON_PREFER_32_BIT"] = "yes" args = ["./afg3251.py", command] logfilename = {"stdout" : "./stdout.log", "stderr" : "./stderr.log" } logfileobj = {} mode = "w" for stream, log in logfilename.iteritems(): try: logfileobj[stream] = file(log, mode) except IOError: print "Cannot open logfile: %s" % log sys.exit(1) subproc_args = { 'stdin' : None, 'stdout' : logfileobj['stdout'], 'stderr' : logfileobj['stderr'], 'close_fds' : True, } try: p = subprocess.Popen(args, **subproc_args) del os.environ["VERSIONER_PYTHON_PREFER_32_BIT"] except OSError: print "Failed to execute command: %s" % args[0] sys.exit(1) ret = p.wait() stdout = open(logfilename["stdout"]).read() stderr = open(logfilename["stderr"]).read() return (stdout, stderr, ret)
afg3251.py 内部で発生した stdout の出力を process.py でそのまま受け取ることはできないので、一度 stdout.log に吐いています。AFG3251 からの応答を見たければ、このファイルを覗けば出力が分ります。
後は、好きなように改造するだけです。
Mavericks でやったこと、気付いたこと
X11
X11 を立ち上げると window manager が twm になってしまっていたので、XQuartz 2.7.4 を入れ直した。これで twm になる問題は解消。ROOT の build で libX11 が見つからないと怒られるのも、XQuartz の入れ直しで解消した。
ROOT
5.34/11 から Mavericks 対応になったので、build し直して入れた。5.34/10 も、Mountain Lion で build したやつはちゃんと動作してたっぽいけど、気持ち悪いので 5.34/11 を使うことに。
MacPorts
MacPorts 2.2.1 の Mavericks 対応のものが出たので、これで入れ直し。/opt は一度削除して、たいした手間ではないので、必要な package は全部入れ直すことにした。
入れたものは以下の通り。あんまり入れてない。
- emacs-app @24.3_1+inline
- emacs @24.3_0+x11
- md5deep @4.3_0
- latexdiff @1.0.3_0
- cmake @2.8.12_0
- swig @2.0.10_0
- swig-python @2.0.10_0
- wget @1.14_5+ssl
- gnuplot @4.6.4_0+aquaterm+luaterm+pangocairo+wxwidgets+x11
- ispell @3.3.02_2
- cfitsio @3.340_0
- unison @2.40.102_1
- ImageMagick @6.8.7-3_0+x11
- lynx @2.8.7rel.2_1+ssl
- pTeX @20110314_10+hiragino+otf+utf8
修士論文や夏の学校の集録や学振申請書を書く皆さんへ (書き方、注意点、心得)
適宜更新します。
目次
- 0 はじめに
- 1 図に関すること
- 2 日本語全般
- 3 引用
- 4 概要 (abstract)
- 5 添削や指導の依頼の仕方
- 作者:木下 是雄
- 発売日: 1981/09/25
- メディア: 新書
- 作者:是雄, 木下
- 発売日: 1994/02/01
- メディア: 文庫
0 はじめに
0.1 この記事の目的
2012 年度末に修士論文の添削を初めて真面目に担当し、論文全体についての助言をする以前の段階で、注意すべき点、して欲しい点が多々あることが分かりました。修士論文に限らず、これは学振の申請書、夏の学校の集録原稿、物理学会の講演概要など、修士学生が他の場面で日本語を書く場面でも同じことが言えます。毎回、毎年、同じことを注意するのは面倒ですし、「修士論文 書き方」などで検索して辿りつく人もいるでしょうから、注意すべき点をまとめて記事にします。
0.2 対象読者
僕のまわりにいる学生と日本中の修士課程の学生。LaTeX を使って修士論文を書く高エネルギー宇宙物理関係の学生を想定していますが、他分野の人、Word を使う人などでも参考になることはたくさんあると思います。
0.3 元ネタ
僕の大学院指導教員である牧島一夫先生がまとめられた「M2 の皆さんへ」という修士論文の書き方の指南書と、「科学英文のチェックマニュアル」に大きな影響を受けて同じようなものを書くことにしました。ただし、この記事は日本語文書限定です。
上記 2 つの文書は理系大学院生必読です。修論などを書き始める前に目を通すことをお勧めします。
ついでに LaTeX の修論テンプレートも GitHub で公開しているので、参考にしてください。
修士論文 LaTeX テンプレート｜名古屋大学宇宙地球環境研究所の理学系修士学生用
1 図表に関すること
1.1 caption について (LaTeX 限定)
LaTeX で図目次を生成させる場合は、目次に長い説明を入れないこと。例えば次のようにすると、図目次には「The 3rd EGRET catalog (Hartman et al. 1999, with modification)」ではなく、短い説明「The 3rd EGRET catalog」のみが表示される。
\begin{figure} \centering \includegraphics[width=14cm,clip]{fig/EGRET.pdf} \caption[The 3rd EGRET catalog]{The 3rd EGRET catalog \citep[with modification]{Hartman1999}} \label{EGRET} \end{figure}
そもそも図目次や表目次を利用する読者というのは多くないので、書いている本人が特に必要と感じないのであれば、ページ稼ぎの技として使用するのは控えましょう。
1.2 図の位置 (LaTeX 限定)
LaTeX の figure 環境で、図の位置を h で指定しないで下さい。h の指定をしないでも、LaTeX がちょうどよい場所に図を自動配置してくれます。論文の図は原則としてページの上部に置くのが慣習になっています。
\begin{figure}[h] %この [h] は取る。LaTeX の参考書で h を指定する例が載っていても絶対に取る。 \centering \includegraphics{fig/EGRET.pdf} \caption{caption} \end{figure}
1.3 画像形式について (LaTeX 限定)
線画では可能な限り vector 画像 (PDF や EPS) を使い、bitmap 画像の場合は PNG、GIF、JPEG を使い分けて下さい。例えば回路図のように線と文字しかないものは PDF を、オシロ画像には PNG を、回路の写真には JPEG を使います。JPEG を使うのは原則として写真のみと思って下さい。逆に、写真を PNG などで保存することも滅多にしません。
最近は PDF や PNG をそのまま LaTeX に貼り込めるので、古い LaTeX の本などに書いてあるように、必ずしも EPS にする必要はありません。やり方は、以下の通りです。
まず、fig/hoge.jpg などを用意した状態で次のコマンドのどちらかうまく動くほうを terminal から実行します。そうすると、fig/hoge.bb もしくは fig/hoge.xbb というファイルが生成されます。
ebb fig/hoge.jpg
extractbb fig/hoge.jpg
次に、LaTeX ソースの先頭のほうに次の行を追加します。
\usepackage[dvipdfmx]{graphicx}
そして、普通に figure 環境で JPEG 画像を指定すれば表示されます。
\begin{figure} \centering \includegraphics[width=5cm]{fig/hoge.jpg} \caption[]{素晴らしい実験装置} \label{fig_hoge} \end{figure}
1.4 図の説明について
図の説明 (caption) は簡潔である必要はありません。むしろ、図示されただけでは読者が分らない情報をそこでちゃんと説明して下さい。何か回路の写真を載せるとして、「図 1.1. 測定回路の写真」とだけ書くのではなく、「図 1.1. 測定回路の写真。左上にあるのが〜〜で、〜〜と接続されている。」のように、読み取って欲しい情報をちゃんと書いて下さい。その図の読み方を読者に丸投げするのは失礼です。
また、本文でゴチャゴチャと図の説明をするよりも、図の caption で説明をしたほうが良い場合が多々あります。例えば本文中で「黒実線は ADC 値の分布」と書くよりも、caption に書いたほうが効果的ですし、読者の目の移動量が圧倒的に減ります。
1.5 図の言及の仕方
本文で全く言及しない図と言うのはありえません。掲載する場合は、本文中で「図 1.1 で示すように」や「〜〜の結果を図 1.1 に示す」や「図 1.1 から明らかなように」などと必ず言及して下さい。これをしないとその図は存在する意味がありません。またその図を見ながら本文を読む必要がある場合には、どの図を見るべきかを指示してもらえないと読者はその図を眺めながら本文を読めません。
また、「宇宙線のスペクトルは冪乗で表される (図 1.1)」などと書くのではなく、「図 1.1 に示す通り宇宙線のスペクトルは冪乗で表される」のような書き方をするように、特にその図の初出時には注意して下さい。
1.6 caption の場所
図の caption はその図の下に入れて下さい。逆に、表の場合は表の上に入れます。この理由はしりませんが、そういう慣習です。
1.7 大きさ
印刷して文字が読めるように配慮して下さい。小さい文字や図の細部が読めないのは駄目です。修論のページ数は決まっていないので、のびのびと紙面を使って下さい。文書の形式が 2 columns の場合、1 column に収めようとせず、大きい図は 2 columns にまたがって表示して下さい。
1.8 他人の作った図の使用
原則として、あなたが発表する論文や集録ではあなたが作った図を使います。共同研究の場合に、どうしても他の人が作った図を掲載する必要がある場合は、先行論文などの出典を明記するか、図の提供者 (その本人が著作権を有している場合に限る) をきちんと載せるかします。そうでない場合、「この図は私が作りました」と嘘をつくことになります。またその図の著作権が既に出版社などに譲渡されている場合、適切な引用を行わないのは著作権の侵害になります。
また、論文を出版する際などに出版社に著作権が譲渡される場合、適切な引用をしないと、複数の出版社でその図に関する権利がぶつかり合ってしまうということも注意してください。
1.9 縦横比を変更しない
写真や図を使用するときに、規定フォーマットやページ数制限に収めるために、縦横比を元画像から変更する人がいますが、これはやめましょう。写真の場合は被写体が実際より歪んで見えますし、グラフなどの場合は文字が細くなったり太くなったりして可読性が下がります。
1.10 軸のラベル
こんなことは中学校レベルだと思うのですが、グラフの縦軸、横軸の説明のない図を平気で出してくる学生がいます。その物理量は何か、単位は何かを必ず図中に書いてください。
1.11 スクリーンショットを使って他人の図を引用しない
修士論文で散見されるのですが、他人の論文から図を引用するときに、論文 PDF を開いた状態でスクリーンショットを撮り、それを修士論文に貼り付ける人がいます。多くの図はベクター形式で作られているため、このようにスクリーンショットにしてしまうとビットマップ画像に変換されてしまいます。また印刷の質に耐えない解像度になり、文字や図が潰れてしまいます。
宇宙・素粒子関係であれば多くの論文が arxiv に乗っていますので、Download > Other formats > Source と進んで画像ファイル一式を落としてきましょう。落としたファイルは tar.gz で圧縮されていますが、拡張子がつかない場合は手動で .tgz などの拡張子をファイル名に追加してください。また論文 PDF から該当箇所をコピーもしくはクロップするという方法もあります。
1.12 無駄にたくさんの罫線を表に使わない
表を作るときに Excel 方眼紙のように、あらゆる場所に罫線を使う人がいますが、ほとんどの縦線も横線もなくて大丈夫です。
↓こういう表ではなくて、
------------------ | Fruit | Price | ------------------ | Apple | 150 | ------------------ | Orange | 150 | ------------------
↓こういう表にしましょう。
---------------- Fruit | Price ---------------- Apple | 150 Orange | 150 ----------------
2 日本語全般
2.1 略語
PMT や ADC などの略語は、必ず初出の場所で「光電子増倍管 (Photomultiplier Tube、PMT)」などと定義して下さい。「Cherenkov Telescope Array」のような語の場合は日本語訳がありませんが、PMT のように日本語で書けるものはちゃんと日本語を書きます。
英単語の場合は「CTA (Cherenkov Telescope Array)」ではなく「Cherenkov Telescope Array (CTA)」と書きます。これは前者の書き方をすると、英文添削では必ず間違いを指摘されます。あくまで省略しない形が正式名称であり、丸括弧で囲んだ略語は「以下〜〜と略す」という意味だからです。
また、なんでもかんでも略語を使って論文中で使いまくる人がいますが、分野違いの人が読む可能性のある文章では略語の多用は避けるべきです。普通の人はどこでその略語が定義されたか、元の意味がなんだったかを全て覚えていられません。略語の多すぎる文章は相手の負担を増やし、また理解の妨げになると思ってください。特に申請書などの場合は分野外の人が審査員に回ることが多々ありますので、注意が必要です。
2.2 回りくどい表現を避ける
「温度測定を行った」などではなく、「温度を測定した」などの簡潔な表現のほうが読みやすく、また伝えたいことが伝わりやすくなります。
2.3 定性的な表現を避ける
「フィッティングの結果が悪くなった」などの定性的な表現ではなく、「フィッティングをしたところ、chi2/ndf が〜〜から〜〜へと悪化した」のように定量的に書いて下さい。これは著者の主観的な判断を示すのではなく、読者が客観的に数字を評価できるようにするため必須です。また、数値で比べてみると案外悪化していなかったりすることもあるので、自分のやっている作業の定量的な確認にも役立ちます。
2.4 単位
「20 GeV」を「20GeV」などと繋げて書いたり、LaTeX 中で「$20GeV$」と書いて「GeV」が斜体にならないようにすること。数式中で普通の文字を使いたい場合は、「$20\,\mathrm{GeV}$」や「$k_\mathrm{B}$」とします。例外として、「°」と「%」は直前の数字との間にスペースを空けません (このルールは国、時代、分野によって異なる可能性あり、最近はスペースを入れるのが主流かも)。「25°」や「95%」は、「$25^\circ$」や「$95$\%」と LaTeX で入力します。
また数値と単位の間に改行が含まれてしまうと読みにくくなる場合があるため、LaTeX の場合は「20~GeV」と書くことで「20」と「GeV」の間に改行が入るのを防ぐことができます。本文を修正するたびに改行に遭遇するかどうかは変わるため、常に「~」使って入力する癖をつけましょう。
Word や Pages を使って文書を作る場合、LaTeX の「~」は使えません。その代わり Mac であれば option + space で改行されないスペースが入力できます。Windows だと control + shift + space です。
2.5 斜体
一部の論文誌では、人工衛星や望遠鏡の名前に斜体を用います。この理由が何なのかはよく知らないのですが、船の名前や飛行機の名前 (例えば Titanic や Enola Gay) には斜体を使うという慣習があり、それが人工衛星にも引き継がれたのだと思われます。また、人物名の Fermi とフェルミガンマ線宇宙望遠鏡の Fermi を区別することも可能になります。
Fermi や Chandra という文字を斜体にするときに LaTeX では「\textit{Fermi}」のようにします。たまに「$Fermi$」として数式中で変数が斜体になる LaTeX の仕組みを利用する人がいますが、数式と文中の斜体は異なります (実際に入力して、文字間隔を確認してみてください)。
また、変数名の添え字が変数でない場合は、その添え字に斜体は使わないでください。例えば $x_i$ などの i には斜体ですが、$E_threshold$ は $E_\mathrm{threshold}$ と書いて、E のみが斜体になるようにします。
2.7 鍵括弧の使い方
原則として、鍵括弧は以下の用途に使います。
2.9 記号
日本語で書ける記号は日本語で書く。例えば「20 GeV 〜 100 TeV」や「20 GeV – 100 TeV」は「20 GeV から 100 TeV」と書きます。「コンプトン散乱のエネルギー + 光電吸収のエネルギー」ではなく「コンプトン散乱のエネルギーと光電吸収のエネルギーの和」と書きます。
2.10 受動態と能動態
基本的に日本語の論文は能動態を積極的に使うべきです。主体が誰なのかを明確にする効果があります。「三日間に渡り温度変化が測定された」では誰がやったのか分かりませんが「三日間に渡り温度変化を測定した」であれば、主語がなくても著者がやったと分ります。
また、特に研究に参加したばかりの学生はまるで他人事のように感じているためか、「〜〜計画が国際共同で進められている」と受動態で書く場合が多数見受けられます。もっと自分が研究の中心なんだ、重要人物なんだ、自分が主体になって進めているのだという意識を持って (もしそうでないならば具体的に実行に移してください)、「我々は〜〜計画を国際共同で進めている」のように能動態に書き換えてください。
2.11 やたらとカタカナ語や英語を混ぜない
例えば「望遠鏡のコスト」は「望遠鏡の建設費用」とごく普通の日本語で表現できます。カタカナでしか対応する語句がない場合、もしくは日本語訳があまりに一般的でない場合を除き、日本語の文章は日本語で書きます。また英語をむやみに混ぜる人もいますが、これも一般的な日本語訳があり、英語で表現する必要性が全くない場合は日本語を使ってください。
2.12 主語と述語と目的語
あまりに長い文を書くと、その文中で主語と述語と目的語が離れ過ぎる場合があります。文を短くするか、それらが適切な位置関係に来るように工夫して書く必要があります。また長い文を書いているうちに主語や述語自体を書き忘れたり、主語が入れ替わったりする場合がよくありますが、絶対にこれは駄目です (日本語の常識として主語が省略出来る場合を除く)。
2.13 ハイフンとマイナス
マイナス記号とハイフンは異なります。メールなどでは「-20℃」と書きますが、LaTeX の場合これをやると、「-」がハイフンとして表示されます。$-20$℃と書けば「-」がマイナス記号になります。
また、天体名で例えば RX J1713.7−3946 などは、ハイフンではなくマイナスを使います。これは 1713.7 と 3946 がハイフンでつながっているのではなく、赤経 17h 13m 33s 赤緯 -39° 45' 36'' の場所にいるということを示しており、マイナス記号が使われます。
2.14 ハイフンとエンダッシュ
画面での違いが分かりにくいかもしれませんが、「-」と「–」と「—」は異なる文字で、それぞれ用途も違います。名前は、ハイフン、エンダッシュ (en dash)、エムダッシュ (em dash) です。Mac の場合、エンダッシュは option + - で入力し、エムダッシュは option + shift + - で入力します。LaTeX の場合、それぞれ「-」「--」「---」と入力します。
本来エンダッシュは比較的使う機会が多いのですが、見た目で違いがあまり分からないため、またメール文書などでは細かいことを気にしないため普通のハイフンで代用されることが多いです。ただし、英語の論文などではちゃんと違いに気をつけましょう。次の場合はハイフンではなくエンダッシュを使います。
- 数字の範囲などを示す場合。例： 20 GeV–300 TeV、300–800 nm
- 違うものを指す単語を連結させる場合。例：Davies–Cotton 光学系 (ただし、very-high-energy や two-year-old のように、単に前後の単語を繋ぐ場合はハイフンを使用する)
英語文章中のハイフンの使い方で注意したいのが、複合形容詞 (compound adjective) を作るときです。例えば「宇宙線」は「cosmic rays」と英語で書きますが、「宇宙線フラックス」を英語にするときは「cosmic-ray flux」とハイフンを使用します。これは「cosmic」が形容詞であるため、ハイフンを入れないと「ray」を修飾することになってしまうからです。「cosmic-ray flux」は「宇宙線の」フラックスという意味であり、「cosmic-ray」とハイフンを入れることによって複合形容詞になります。
同様に「超高エネルギー」は「very high energy」となりますが、「超高エネルギーの」と形容詞として使う場合には「very-high-energy」となります。ただし、「極高エネルギー」は「ultra-high energy」と書く場合があります。これは「very」が副詞なのに対し、「ultra」が接頭辞であるための違いです。複合形容詞として使う場合は「ultra-high-energy」とするのがやはり正しいように思いますが、これはなぜか「ultra-high energy cosmic rays」のように書くことが多いようです (どなたか理由を教えてください)。
2.15 「など」
「シンクロトロン放射などの過程」のように「など」を使って省略せず、数が限られており書くのが簡単な場合は「シンクロトロン放射、制動放射、逆コンプトン散乱」のように列挙したほうが良いです。
2.16 順接の「が」
「が」には順接と逆接の両方の使い方があります。順接の「が」は読者を混乱させる場合があるので、使わないようにしましょう。例えば「これまで温度測定を行ってきたが、今後とも継続する必要がある」のような書き方をすると、「が」の後に逆接が来ることを期待してしまいます (例えば「これまで温度測定を行ってきたが、今後は湿度測定を…」のような期待をする)。
2.17 本文中の数式
「dN/dE」のような簡単な数式は $$ 環境を LaTeX 中で使わなくても書けてしまいますが、N や E は斜体にすべきなので、必ず $$ 環境を使って $\mathrm{d}N/\mathrm{d}E$ と書きます。
2.18 「ch」
「ch」というのは channel の略なので、日本語で「分解能の悪い ch が存在する」のような表現はおかしいです。「チャンネル」とちゃんと書きます。「Ch 1 は分解能が悪い」は問題ないです。
2.19 何について書いてるのか明確にする
「精度が悪化する」とだけ書くと何の精度か分かりません。「エネルギー決定精度が悪化する」や「フィッティング精度が悪化する」のようにちゃんと書きます。「感度の向上」や「強度の低下」なども「ガンマ線検出感度の向上」や「ガンマ線強度の低下」のように、何を書いてるのか明確にします。
また、「信号を取得する」「データを転送する」のように漠然と記述されているのを散見しますが、どのような信号なのか、どのようなデータなのか (波形情報か、電圧値か、画像か) をちゃんと説明してください。書いている本人は何について述べているのか分かっているでしょうが、読者には分かりません。
2.20 英数文字と日本語の混在
日本語文章を書いているときに、句読点とコンマ・ピリオドが混在したり、半角の丸括弧と全角の丸括弧が混在している場合が多々あります。原則として日本語の文章中では、「、」「。」もしくは「，」「．」を使い、「,」「.」は使いません。また「(」「)」ではなく「（」「）」を使います。LaTeX を使っていれば、丸括弧の左右の余白は適切に調整してくれます。
特に、英単語を日本語文中で列挙している場合にこのミスが目立ちます。例えば「HESS, MAGIC, VERITAS といった望遠鏡」のような記述をするときに、アルファベットを打った勢いでそのままコンマを打ってしまうようです。
※と言いつつ、この blog の記事では「（」「）」の代わりに「 (」「) 」を使っています。理由は、世の中の web browser の組版が美しくないからです。LaTeX の組版は綺麗なので、ちゃんと使い分けましょう。
2.20 「数十」と「数 10」
ガンマ線業界では「数十 GeV」や「数百天体」という表現をよくしますが、これを「数 10 GeV」や「数 100 天体」と書かないで下さい。「数 100000 天体」とか「太陽質量の数 100000000 倍」になってくると、なにかおかしいなと分かるはずです。
2.21 文中の文献番号の場所
文献番号が末尾にくるとき、「〜〜と報告されている [3]。」のように書きます。「〜〜と報告されている。[3]」とは書きません。
2.22 Double quotation の向きを揃える (LaTeX 限定)
LaTeX 中で「"this is a pen"」のように書きたい時、「``this is a pen''」と書きます。「``」は「`」を二連続で、「''」は「'」を二連続です。面倒ですが、こうしないと PDF にしたときに向きが揃いません。
2.23 タイトル中の Times の英語とゴシック体の日本語の混在 (LaTeX 限定)
例えば jarticle がスタイルとして指定されている原稿を書く場合、「\title{Cherenkov Telescope Array の装置開発}」と書くと「Cherenkov Telescope Array」だけフォントが Times になり、「の装置開発」はゴシックで表示されて統一感がなくなる場合があります。これを回避するには、次の行を先頭のほうに書いておくと解決します。
\usepackage[deluxe]{otf}
2.24 RMS と標準偏差
主に ROOT を解析ソフトウェアとして使っている人の中に、RMS と標準偏差の区別がついていない人がたくさんいます。これは PAW の時代から引きずっている悪習です。統計用語として違う概念ですので、区別して使って下さい。放射線と放射能の違いには敏感な人が多い業界なのに、不思議な話です。
我々の業界でヒストグラムを作るとき、もし教員や先輩が「RMS」という言葉を発したら、それは標準偏差の間違いです。ROOT はバージョン 5 まで RMS という間違った用語を使っていましたが、バージョン 6 からは Standard Deviation (Std. Dev.) という言葉に直っています。GetRMS は GetStdDev です。
2.25 人名の姓名の途中での改行
集録などで著者名を書く時に、姓名の間に改行が入ってしまっている場合を散見します。例えば「奥村 曉」であれば「村」と「曉」の間に改行が入っていたり、「A. Okumura」であれば「A.」と「Okumura」の間に改行が入っていたりです。このように、姓名の間に改行が入るのはマナー違反とされています。
Word や Pages のようなワープロソフトや LaTeX の場合、それが人名だとは機械が判断できないため、改行しやすい場所で自動的に改行してしまいます。ここでは改行しないでね、と機械に伝えるためには、LaTeX の場合は「A.~Okumura」や「奥村~曉」と入力します。
また、Mac の Pages の場合は姓名の間の space の代わりに、option + space を入力します。そうすると自動改行がされなくなります。
2.26 「~」と「〜」
日本語文章で数字の範囲を書く時に、全角の「〜」の代わりに半角の「~」を使う人がいますが、これは違う文字です。後者はチルダと呼ばれる記号であり、範囲を表すために使う記号ではありません。そのため、英語文章で「300~650 nm」のように書くのは間違いです (日本人にしか通じません)。
2.28 なんでもかんでも「データ点」と総称しない
これは言葉の意味をよく考えずに書いているのだと思いますが、「得られたデータ点の統計誤差は」のような書き方をよく目にします。「データ点」は図中の測定値を表す点のことであり、実験であなたが得たものは「データ点」ではなく測定値です。また二次元、三次元の図では「データ点」は二つもしくは三つの座標を持つので、「データ点の誤差」のような書き方をされるとどの値の誤差なのか分からなくなります。
2.29 「における」の不適切な使用
物理学会の講演題目などでよく見かけるのですが、「における」という言葉の不自然な使い方をする学生が多いです。例えば「CTA 計画における大口径望遠鏡の開発」といった表現です。CTA 計画以外では大口径望遠鏡 (これはこの場合固有名詞です) の開発はやっていませんので、「における」は不自然です。「における」は複数ありうる中から特に限定した場所を指すときに使います。「日本における東京タワーの建設」は日本語としておかしいですよね、それと一緒です。
「における」の使用意図としては、「○○実験で使用する△△装置」という意味を持たせたいときに「○○実験における△△装置」という書き方をする場合が多いようです。この「△△」が仮に一般によく使用される装置、例えば光検出器などであれば、「○○実験における光検出器の使用」などとしても日本語としてはおかしくありません。
2.30 句読点
物理系の修士論文のような日本語の横書きの科学技術文書の場合、句読点は「、」と「。」の組み合わせ、もしくは「，」と「．」の組み合わせを使用してください。公文書では「，」と「。」の組み合わせを使うという指針が国から出されていますが、歴史的な理由からか科学技術文書では「，」と「．」が多く使われるのです。一般的には「，」と「．」の組み合わせが使われますが、私個人の好みは「、」と「。」です。あくまで好みの話なので、文書全体で統一されていれば好きなもので構いません。
2.31「講演」と「公演」
学会発表は「公演」ではなく「講演」と書きます。辞書で意味の違いを調べてください。
2.32「チャンネル」という言葉に「ピクセル」や「画素」という意味はない
よく「XX チャンネルの焦点面カメラ」のような表現を見かけますが、「チャンネル」には「ピクセル」や「画素」という意味はありません。「チャンネル」とは情報を伝達する経路のことです。我々の業界では、通常読み出し回路の数などを数える場合には「チャンネル」を使いますが、これは波形が信号線を通って読み出し回路に繋がっているからです。
2.33 体言止め
体言 (名詞) で文を終わる、いわゆる「体言止め」をしないこと。科学文書は文芸作品ではありません。
2.34 過去形と現在形
実験の説明は原則として全て過去形で述べてください。行った実験の事実は全て過去の出来事であり、現在形でも未来系でもどちらでもありません。一般論を述べる場合は現在形で構いませんが、自分の踏んだ実験手順をまるで料理のレシピのように現在形で書いてはいけません。
2.35 斜体と立体 (LaTeX 限定)
数式中や本文中の変数名は斜体にします。LaTeX の場合、「速度 v」と書くのではなく、「速度 $v$」と書きます。
また、変数の添え字は、それが変数であるか、何かの言葉であるかによって斜体と立体を使い分けます。例えば複数の電圧の測定値があるような場合は「$V_i$」と書き、i も変数であることが分かるようにします。しかし例えば電圧の最大値は「$V_\mathrm{max}$」のようにして、max の部分が斜体になるのを防ぎます。
2.36 わかりやすい変数名にする
「光電子増倍管のゲイン M」や「望遠鏡の有効面積 F」のように、その変数の意味する内容を推測できない変数名をつけてはいけません。多くの場合、英語の頭文字を使い、例えば「光電子増倍管のゲイン G」や「望遠鏡の有効面積 A_eff」のようにします。
2.37 「次」と「以下」を使い分ける
「以下」というのは、そこから後ろ全てという意味です。例えば卒業式などで「以下同文」という使い方をします。「次」というのは、その場所の次に書いてある箇所を指します。したがって、次の行に出てくるような式を指す場合は「次の式」のように書きます。
3 引用
3.1 引用と転載
引用と転載は異なる概念なので、注意して下さい。他の人の論文の図を自分の修論に掲載する場合、その図があくまで自分の論文に対して主ではなく従である必要があります。また、どこからか図を持ってきたら、必ずその出典を明記して下さい。Web にある画像は URL を載せて下さい。
日本語で「引用」と言う場合、英語の quote と citation の 2 種類の意味がありえます。大学などの学位論文作成の注意書きには、よく quote のほうの引用の説明が書かれています。しかし宇宙物理などの分野では citation のほうの引用しかほとんどしないでしょうから、「ちゃんと文献を引用しろ」と指導教員に言われたら、それは citation のことだと思って下さい。
他の先行研究から図を借りてくるような行為は、quote に入ります。
3.2 論文の引用 (citation)
自分が考えたことでない記述は、原則としてその原典を書くべきです。例えば「近年では Fermi 衛星の活躍により超新星残骸での陽子加速の証拠がほぼ明らかになった」のような記述をするときは、該当論文を書いて下さい。一方で、「宇宙線の謎はその発見以来 100 年にわたり」のようなごく一般的な共通認識は、わざわざ引用する必要はありません。
3.3 盗用と無断転載 (≒コピペ)
こんなことをわざわざ書きたくありませんが、他人の論文や Wikipedia などから文章を盗んでくる人がたくさんいます。学部のレポートではなく、修士論文の話です。人の書いた文章を参考にするのはもちろん構いませんし、学問の発展と営みというのはそういうものです。しかし、コピペはいけません。修士論文だと最悪の場合、学位の取り消しになり修了できない、進学できない、就職できない、という結末が待っています。
ばれないだろうと思って万引きのようにコピペをするのでしょうが、コピペは読者にばれます。「コピペルナー」のような専用ソフトを使わなくてもばれます。ただし、指導教員や審査員がそれほど真面目に読まない場合は、コピペに気がつかない場合が多々あります。またコピペは絶対にやってはいけないという指導が徹底されていないため、はっきり言って今の日本の大学院ではコピペが蔓延っています。報道に出てくるのは氷山の一角でしょう。
今までに気がついたコピペの発見には以下のパターンがあります (修論に限りません)。
- つい 1 週間前に読んだ論文と似た表現だなと感じた (某大学助教の学会申し込みの英文概要)
- コピペまではいかないが、Wikipedia のある項目の内容に非常に似ており、しかもその項目は僕が書いたものであった (某大学の修士論文)
- 日本語の表現として明らかにおかしく、原文は英語であったものを拙い翻訳をしたように見えた。しかも、その原文を書いた本人は僕だったので、ばればれ (某大学の修士論文)。
- 「てにをは」や文末だけが不自然なので、100% のコピペを防ぐために 2% くらいだけ自分で変更して逆におかしくなった (某大学の修士論文)
- 業界内では通常は使わないと思われる変な表現があったので、そんな用語があるのかと Google で検索したら他の公開されている修士論文からのコピペであった (某大学の修士論文)
- 他の場所はボロボロなのに、その箇所だけやけに上手にかけている
- やけに上手に書けているせいで、自分の修論と関係のないこと (コピペ元では必要な情報だったのでしょう) まで盛りだくさん。
- その場所だけ文体が違う
- イントロ部分が研究室、もしくは実験グループで代々引き継がれている
- 図の引用元が明記されていない。なぜかというと、他人の修論からコピペしたのに、コピペ元でもその図の引用をちゃんとしていなかったため、原論文が分からない。
3.4 引用した文献はちゃんと読む
当たり前のことですが、自分が引用する文献にはちゃんと目を通しましょう。全文熟読する必要はないですが (場合によりけり)、その論文の趣旨を勘違いして引用していたり、その論文が出典だと思っていた図が、違う論文から持ってきたり図だったりすることもあります。
よくあるのは先輩や他の人の書いた修論を参考にし、「あ、この図は使えそうだな」と考えて図の引用のみをする場合です。イントロなどで使える綺麗な図、よくまとまった図が欲しいだけで、元文献なんて読みもせず、download もせずに図だけ貼り付ける人がいます。
3.5 自己剽窃について
コピペが駄目というのは、何も他人の文書を盗用 (剽窃) するのが駄目ということに限りません。過去に自分が発表した文章や図をそのまま他で流用することも、場合によっては禁止されています。これを自己剽窃と言います。
なぜ駄目かというと、主に理由がふたつあります。ひとつは同じ内容で二重投稿をしないようにすること (ひとつの研究成果を異なる雑誌などに投稿すること。成果の水増しになるし、査読者などの負担を無駄に増やすことになる。)、また著作権の問題があります。
3.6 孫引き
あなたの使用したい図の初出が文献 A だとします (原典)。その図を他の論文やネット記事 (文献 B) が引用しているのをあなたが見つけるとします。このとき、あなたは図の引用元として文献 B を使用してはいけません。このような行為を孫引きと呼びます。あなたが引用元として明示するベきは、文献 A です。
4 概要 (abstract)
4.1 概要とは
概要はあくまで本文全体のまとめです。概要に既に書いたから本文には書かないで良いとか、概要に書いてあるのに本文に書かれていない記述があるということは、ありえません。概要は概要のみを取り出しても意味が通じるように書き、また本文は本文のみで取り出しても意味が通じなくてはいけません。
したがって、例えば概要で「Photomultiplier Tube (PMT)」と書いたとしても、本文中で PMT を使う時には初出の箇所で再度定義する必要があります。
4.2 概要をいつ書くか
概要は普通、修士論文の先頭 (表紙の直後) に来ます。そのためか多くの学生が、修士論文を書き進める前に概要に着手することがあるようです。しかし修士論文の筋書きや実験、計算結果などが全て揃っている場合を除き、修士論文を書き始めた時点でその結果や結論までが見えているのは稀でしょう。結論のあたりまで執筆が進んだ時点で、概要を書き始めるので良いと思います。
ただし、提出日当日に結論を書き終え、それから概要を書き始めるのでは間に合いません。概要を書くのに半日以上はかかると見込んで予定を立てましょう。
自分の職場だと、修士論文本体に加えて要旨の提出も求められます。これの作成作業についても、概要と同じことが言えます。
5 添削や指導の依頼の仕方
5.1 依頼をする前に
指導教員や先輩などに論文の添削をする前に、まずは最低限、ここに書かれていることを自分で直してから提出しましょう。論文の添削というのは全体の構成や論理展開、実験や考察の不足、間違いの指摘などを行うことが主な目的です。決して、「数字と単位の間にはスペースを入れるように」なんて下らない指摘をするために時間を浪費するためのものではありません。
一度ちゃんと気をつけて書くようになれば、書いている最中につまらないミスをすることはなくなります。書いている本人と添削する側の時間をお互いに無駄にしないために、ここに書かれていることは厳守しましょう。
5.2 時間に余裕をもって
第一草稿を真面目に添削をすると、例えば 50 ページの修論を読むのに 5 時間はかかります。4 ページの夏の学校の集録でも 1 時間はかかります。
論文の添削は大学教員の業務の一環なので、もちろんどんなに時間がかかろうが添削をします。しかし、添削以外にも大学教員は多くの仕事を抱えています。そのため、締切直前に添削依頼が来ても対応することができません。仕事の合間を縫って、睡眠時間を削って、家族との時間を割いて、添削せざるをえなくなります。
締切直前に添削依頼がくると、余裕をもって依頼が来た時に比べて当然添削にかけられる時間が減少します。そうすると十分な添削ができませんし、書き直しの指示を反映してもらう時間も無くなってしまいます。
添削結果をもらいたい三日前くらいには、依頼をするようにしましょう。
5.4 指摘された箇所は全て修正してから次の添削に出す
添削をしていると、「なぜ前回指摘した箇所の複数がまだ直っていないのか」と思うことが多々あります。これは本当に時間の無駄ですし、馬鹿にされているのかとさえ思います。指摘された箇所は全て直してから次の添削に回しましょう。
もし、修正する必要がないと思って修正しなかった場合、その理由を説明してちゃんと伝えましょう。添削者の思い込みなどで、見当違いの指摘が来る場合もあります。おかしいなと思った指摘に対しては、「〜〜の論文には〜〜と書いてあるため、現在の文章で問題ないと思います」のようにちゃんと説明をすることが大切です。
5.5 どこを直したかを分かりやすくする
大幅な改訂ではなく、細かい改訂の場合は、どこをどのように変更したか分かるように、もしくは伝えるようにしましょう。何ページもある PDF を渡されて、前回の版と何が違うのかが明示されていないと、添削する側は全文を読み直さなくてはいけません。
LaTeX を使っている場合は latexdiff を使うと便利です。
latexdiff version1.tex version2.tex > diff.tex platex diff.tex dvipdfmx diff.dvi
のようにすると、PDF 中に差分が分かりやすく表示されます。latexdiff は標準では入っていないので、LaTeX のパッケージと別途インストールが必要と思います。
5.6 謝辞にも可能なかぎり目を通してもらう
修士論文の最後に謝辞を書く場合がほとんどだと思いますが、ここが添削の対象になることはほとんどないと思います。自分も謝辞の添削まではしていません。また、学生本人の感謝の気持ちなどを書く場所であり、執筆の最中に指導教員に読まれるのが気恥ずかしいというのもあるのか、修士論文の提出直前に謝辞を追加する場合が多々あるようです。
ただし、謝辞の中で人名や職階の記入を間違えていたり、事実誤認が含まれている場合が多々あります。せっかく謝意を示す文章の中で、その相手の氏名を入力し間違えていては、大変失礼にあたります。可能であれば、謝辞も先輩などに確認してもらいましょう。
また謝辞で「指導教員」を「指導教官」と書いたり、「助教」を「助教授」としてしまう間違いがよくあります。国立大学が法人化された後は「教員」と呼びます。また昔の「助教授」は「准教授」に変わり、「助手」が「助教」と「助手」の二つに細分されました。
ついに ROOT で日本語を使えるようになりました (使わないけども)
(多分) ROOT 5.34 から TMathText という新しい class が導入され、ついにマルチバイト文字の扱いもできるようになりました。QtROOT を使えば以前から同じようなことが出来たのですが、非標準の ROOT は使いたくないので試したことがありませんでした。日本語を使いたいという機会が滅多にないですし。
また、マルチバイトの取り扱いができることよりも、TMathText の最大の売りは LaTeX 機能の改善です。TLatex でも LaTeX のような汚い何かは入力できていましたが、TMathText でかなり表示が改善されています。タイトルや軸など、TLatex で表示されていた部分は全て TMathText で置き換わりましたので、今後は TMathText に慣れましょう。
さて、実際に使って試してみます。まずは C++ の例です。japanese.C を utf-8 で保存しましょう (円記号の表示は、実際は backslash で入力)。
void japanese() { TH1D* h = new TH1D("h", "\\hbox{標準偏差 }\\sigma=1\\hbox{ の正規分布の例};\\hbox{物理量};\\hbox{頻度}", 100, -5, 5); h->FillRandom("gaus", 10000000); h->Draw(); }
$ root root [0] .x japanese.C
こちらは Python 版です。先頭に utf-8 であることを明記して、C++ と同様、文字列中にそのまま日本語を書き込みます。これも utf-8 で保存します。
# -*- coding: utf-8 -*- import ROOT def japanese(): global h h = ROOT.TH1D("h", "\\hbox{標準偏差 }\\sigma=1\\hbox{ の正規分布の例};\\hbox{物理量};\\hbox{頻度}", 100, -5, 5) h.FillRandom("gaus", 10000000) h.Draw()
$ python >>> import japanese.py >>> japanese.japanese()
さて、出力結果は次のようになります。うまく表示できた、と思いきや、「偏」の旁の上の部分がおかしいですね。おかしいというか、日本の漢字ではなく中国の簡体字です。
▲ ROOT で日本語を表示した例。「偏」の字がおかしい。
なぜ日本の漢字ではなく簡体字になるかというと、ROOT と一緒に配布されるフォントが DroidSansFallback.ttf というものだからです。このフォントには日本語、韓国語、中国語などが含まれているのですが、異体字は同じ文字として扱われているため、日本語と簡体字の区別がちゃんとされていません。そのため、異体字が日中で重複してしまうような場合は簡体字が表示されてしまうのです。
それでは、他のフォントにしてしまえば良いのでは? という疑問が湧きますが、DroidSansFallback.ttf 以外のフォントを指定する方法は今のところ無いようです。TTF.cxx などにも、ベタ書きされています。
そこで、$ROOTSYS/fonts/DroidSansFallback.ttf を他のフォントで書き換えてしまいます。例えば、Osaka フォントを無理やり置いてみます。
$ cd $ROOTSYS/fonts $ mv DroidSansFallback.ttf DroidSansFallback.ttf.bak $ cp /Library/Fonts/Osaka.ttf DroidSansFallback.ttf
この状態で japanese.C を再度走らせたものが次の図です。「偏」の表示は日本語らしくなりましたが、なぜか縦軸も横軸もタイトルが消えてしまいます。もう少し調べる必要がありそうです。
▲ 「偏」は直ったが、縦軸と横軸が表示されない。
仕方なく DroidSansFallback.ttf を使うとして、それでもまだ問題があります。まず、PDF に直接保存すると日本語部分が表示されません。仕方なく EPS に保存すると、今度は Mac の Preview.app では PDF に変換できません。Acrobat X を使っても開けません。gs で開くと日本語も表示されますが、うちの環境だと「量」の字が豆腐に化けました。ps2pdf を使って EPS を PDF に変換すると、同様に「量」が化けてしまいました。また、DroidSansFallback.ttf が全て EPS に埋め込まれる仕様のため、EPS の大きさが 20 MB を超えてしまいます。
とまあ、色々とまだ問題があります。
美味しいオクムライスの作り方
オクムライスとは
まあ、冷蔵庫にあるものでタコライス的なものを作ろうとしたら違う料理になってしまった感じ。でもこっちのほうが美味しいし簡単。
用意するもの (二人前)
- 炊き立てのご飯 2 合
- 卵 4 つ
- レタス 4 枚 (大きめ)
- トマト 2 つ (大きめ)
- もやし 1 袋
- 牛挽肉 300 g (合い挽きでも可)
- ニンニク 3 かけ
- グラタンチーズ適量
- 中濃ソース適量
- ケチャップ適量
- コショウ適量
- サラダ油適量
手順 (所要時間 15 分)
1. ご飯を炊いて、蒸らしている間に 2. へ。
2. トマトはサイの目に切ってボウルへ。
3. レタスは太めの千切りにしてザルで水を切る。
4. ニンニクをスライスしてサラダ油で香りがでるまで炒める。
5. 牛挽肉を 4. に追加して火が通るまで炒める。
6. もやしを 5. に追加して 1 分くらい炒め、中濃ソースとコショウを適量加える。中濃ソースで味の濃さが決まるので、1 人 1 合食べるのに丁度良さそうな濃さまで適当に。
7. ご飯をドンブリか深めの皿に盛り、グラタンチーズを好きなだけ乗せる。
▲ チーズはたくさん乗せたほうが美味しい。
8. チーズがちゃんと溶けるように、6. をチーズの上からかける。
▲ 熱々をちゃんと乗せてチーズを十分に溶かすこと。
9. 別のフライパンで目玉焼きを作り始める。
10. 目玉焼きができるまでの間に、レタスとトマトを 8. に乗せる。レタスとトマトは多めのほうが美味しいので、こぼれないように大きめの器が良い。
▲ これの 1.5 倍くらい野菜を乗せても良い。好きなだけ。
11. 半熟の目玉焼きを 10. に乗せて、ケチャップをかける。
▲ 完成!!!
12. グチャグチャとスプーンでかき混ぜながら食べる。
CMake と SWIG を使って C++ と Python と ROOT に対応させる
やりたいこと
CTA の焦点面カメラの開発に必要なソフトを新たに書く必要があり、以下の条件を満たす必要があります。
- 速度重視の用途に耐えるため、また multi thread に対応するため、中身は C++ で書かれていること
- 速度を重視しない場合や簡単な試験にすぐ使えるように、Python からも利用可能なこと
- C++ を使えない人にも使いやすいこと (これもすなわち、Python で動くこと)
- ROOT からも動くこと
- OS X でも Linux でも動くこと
- Engineer の人でも使えるよう、将来的に Windows 対応もできること
- ROOT に不慣れな人、ROOT を install していない人でも動かせること
- PyROOT ではなく、純粋に Python のみで動くこと
つまり、標準では C++ の shared library を生成し、必要に応じて Python 用の library も生成し、さらに必要に応じて ROOT 用の library も生成するものが必要です。動作環境も全部載せです。
解決策
結論として、CMake と SWIG を使うことにしました。
まず、Autoconf を今更勉強したくなかった*1ので、CMake にしました。それと、CMake のほうが文法が簡単そうというのも理由です*2。また、最近の Geant4 では CMake が標準になったのも理由です。ROOT も新しいものは CMake に対応しています。Geant4 と ROOT が CMake に移行しているのだから、CMake の勉強しておけば役に立つだろう、と。
次に、C++ で書かれた code を Python に持って行くには、やはり SWIG が標準的だそうで、SWIG を使うことにしました。CMake から SWIG を呼び出すのも簡単なことが分かったのも理由です。
簡単と言えば簡単なのですが、CMake の分かりやすい解説はそれほど整備されていません。数日間にわたる Google 検索と試行錯誤の結果をここにまとめます。
使い方
階層
どのように directory や file を置くかは好みですが、自分の試した構成は次の通りです。実際にはもっと inc と src の中身は増えます。
target+
|-CMakeLists.txt
|-inc+
| |-BasePacket.h
| |-CommandPacket.h
| |-ResponsePacket.h
| |-LinkDef.h
|
|-src+
|-BasePacket.cxx
|-CommandPacket.cxx
|-ResponsePacket.cxx
|-CMakeLists.txt
|-target.i
それぞれの中身
cmake_minimum_required(VERSION 2.6 FATAL_ERROR) project(TARGET) set(TARGET_VERSION_MAJOR 1) set(TARGET_VERSION_MINOR 0) option(PYTHON "Build the Python version of TARGET library" OFF) option(ROOT "Build the ROOT version of TARGET library" OFF) subdirs(src) include_directories("${TARGET_SOURCE_DIR}/inc")▲ target/CMakeLists.txt
aux_source_directory(. SOURCES) add_library(TARGET SHARED ${SOURCES}) install(TARGETS TARGET DESTINATION ${CMAKE_INSTALL_PREFIX}/lib) if(ROOT) message("ROOT support is added") find_package(ROOT REQUIRED) include(${ROOT_USE_FILE}) include_directories(${ROOT_INCLUDE_DIRS}) file(GLOB INCS "${TARGET_SOURCE_DIR}/inc/*h") file(GLOB LINKDEF_H "${TARGET_SOURCE_DIR}/inc/LinkDef.h") list(REMOVE_ITEM INCS ${LINKDEF_H}) ROOT_GENERATE_DICTIONARY(RTARGETDict ${INCS} LINKDEF ${LINKDEF_H}) ROOT_LINKER_LIBRARY(RTARGET ${SOURCES} RTARGETDict.cxx LIBRARIES Hist MathCore) ROOT_GENERATE_ROOTMAP(RTARGET LINKDEF ${LINKDEF_H} DEPENDENCIES Hist MathCore) endif(ROOT) if(PYTHON) message("Python support is added") find_package(SWIG REQUIRED) find_package(PythonLibs REQUIRED) include(${SWIG_USE_FILE}) set(CMAKE_SWIG_FLAGS "") include_directories(${PYTHON_INCLUDE_DIRS}) set_source_files_properties(target.i PROPERTIES CPLUSPLUS ON) set_source_files_properties(target.i PROPERTIES SWIG_FLAGS "-includeall") swig_add_module(target python target.i ${SOURCES}) swig_link_libraries(target ${PYTHON_LIBRARIES}) execute_process(COMMAND python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()" OUTPUT_VARIABLE PYTHON_SITE_PACKAGES OUTPUT_STRIP_TRAILING_WHITESPACE) install(TARGETS _target DESTINATION ${PYTHON_SITE_PACKAGES}) install(FILES ${CMAKE_BINARY_DIR}/src/target.py DESTINATION ${PYTHON_SITE_PACKAGES}) endif(PYTHON)▲ src/CMakeLists.txt
#ifndef TARGET_BASE_PACKET_H #define TARGET_BASE_PACKET_H namespace TARGET { class BasePacket { private: public: BasePacket(); virtual ~BasePacket(); }; } // TARGET #endif // TARGET_BASE_PACKET_H▲ target/inc/BasePacket.h
#include "BasePacket.h" namespace TARGET { BasePacket::BasePacket() { } //______________________________________________________________________________ BasePacket::~BasePacket() { } } // TARGET▲ target/src/BasePacket.cxx (中身はまだ空です)
#ifdef __CINT__ #pragma link off all globals; #pragma link off all classes; #pragma link off all functions; #pragma namespace TARGET; #pragma link C++ class TARGET::BasePacket; #pragma link C++ class TARGET::CommandPacket; #pragma link C++ class TARGET::ResponsePacket; #endif▲ inc/LinkDef.h
%module target %{ #include "BasePacket.h" #include "CommandPacket.h" #include "ResponsePacket.h" %} %include "BasePacket.h" %include "CommandPacket.h" %include "ResponsePacket.h"▲ src/target.i
Build
$HOME に target という directory があると仮定します。
$ mkdir build $ cd build $ cmake ~/target -DPYTHON=ON -DROOT=ON (snip) $ make (snip) $ sudo make install [ 35%] Built target RTARGET [ 57%] Built target TARGET [ 92%] Built target _target [100%] Built target libRTARGET.rootmap Install the project... -- Install configuration: "RelWithDebInfo" -- Installing: /usr/local/lib/libTARGET.dylib -- Installing: /usr/local/lib/libRTARGET.so -- Installing: /usr/local/lib/libRTARGET.rootmap -- Installing: /Library/Python/2.7/site-packages/_target.so -- Installing: /Library/Python/2.7/site-packages/target.py
これで、/usr/local/lib に C++ 用の library である libTARGET.dylib、ROOT 用の libRTARGET.so と libRTARGET.rootmap、また /Library/Python/2.7/site-packages に Python 用の _target.so と target.py が install されました。
実際に使ってみる
>>> import target
>>> base = target.BasePacket()
root [0] TARGET::BasePacket* base = new TARGET::BasePacket()
動作試験環境
Linux
- Scientific Linux 6.3
- GCC 4.4.6
- Python 2.6.6 (yum で python-devel を入れる必要あり)
- ROOT 5.34/04
- SWIG 1.3.40 (yum)
- CMake 2.8.10.2 (yum で導入可能な 2.6.4 では、ROOT の build でこけるので、2.8 以上を自分で導入する必要あり)
ROOT と CMake 以外は全て yum で取ってこられる最新のもの。
ただし、Scientific Linux の環境では /usr/include/python2.6/Python.h を見つけてくれなかったため、次のように実行しました。CMake はこれくらい自動で見つけてほしいですが…。
$ cmake ~/target -DPYTHON=ON -DPYTHON_INCLUDE_DIRS=/usr/include/python2.6 -DROOT=ON
