NextReality

2013-04-06

■ MS Word で LaTeXのソースを書く (macos)

Wordで(英文)論文を書こうとしても、図はどっかに飛んで行くわ文献管理はしにくいわで大変なので、だいたいはLaTeXとEmacsで論文を書いているのですが、Wordにも２点だけいいところがあります。

ひとつめはスペルチェッカーと文法チェッカーが入っていること。オンザフライでスペルミスが分かるのありがたい。文法チェッカーは単純な主語と動詞の数の一致ぐらいなのですが、それでも見つけてくれるとケアレスミスが減る。Emacsでもispellは論外としてもflyspellみたいにリアルタイムにスペルチェックしてくれるモードもあるけど、使い勝手はWordのほうがよい。よい文法チェッカーがEmacsにもあればいいのにと思ってました。

もうひとつは編集履歴が残せることで、複数人で論文をリバイズしたり、コメントを書き込んだり、英文校正業者に出したりするときに便利。

しかしWordですべて論文の割り付けまで含めてやるのはいやだと思っていたので、WordでLaTeXソースを書けるように工夫してみました。

まずWordにEmacs キーバインドを設定します（ここなどを参考に：http://d.hatena.ne.jp/phithon/20111127/emacs_like_shortcuts_on_microsoft_office_word

)。

次に、wordフォーマット(**.docx)のままではLaTeXが処理できないので、プレーンテキストに変換します。Wordはテキストファイルも読み込めるのですが、そうすると上で言った第２の利点である編集履歴が残せません。またTeXコマンドの"\"（バックスラッシュ）をWordのほうでも解釈して変な文字に変換してしまって収集つかなくなってきます。そこで、以下のようなRuby スクリプトを作りました(macos専用）。ポイントはtextutilというmacosに備わっている便利コマンド。wordフォーマットをテキストに変換してくるのですね。さらに、TeXの記号である"\"がそのままでは別の文字に変換されるので元に戻し、引用記号"abc"などもTeX式に``abc''に変換してます。

#!/opt/local/bin/ruby

word=ARGV[0]
tex=ARGV[1]
temp="/tmp/word2tex#{$$}.txt"

system("rm -f #{temp}")
system("textutil -convert txt #{word} -output #{temp}")

File.open(temp, "rb") { |f|
   line = f.read
   line.gsub!(/\xC2\xA5/n, "\\")
   line.gsub!(/\xE2\x80\x9C/n, "``")
   line.gsub!(/\xE2\x80\x9D/n, "''")
   line.gsub!(/\xE2\x80\x98/n, "`")
   line.gsub!(/\xE2\x80\x99/n, "'")
   File.open(tex, "wb") { |out|
      out.write(line)
   }
}

system("rm -f #{temp}")

あとはronbun.docxなどにLaTeXソースを(Word)で書いていって、こんな感じのshell script でフォーマットすればOKです。

TARGET=ronbun
LATEX=pdflatex
ruby word2tex.rb ${TARGET}.docx ${TARGET}.tex
${LATEX} ${TARGET}
jbibtex ${TARGET}
${LATEX} ${TARGET}
${LATEX} ${TARGET}

何と快適！

Permalink | コメント(0) | トラックバック(0) | 11:36

idトラックバック

2013-02-03

■ 安村先生最終講義 - Most of them have tricks of their own

昨日2月２日は慶應義塾大学湘南藤沢キャンパス（慶應 SFC)で安村通晃先生の最終講義だった。安村先生は日立中央研究所でS810の並列コンパイラのチーフデザイナなどコンピュータシステムの研究開発をされたあと、SFC創設時に大学に転じられ、以降20年以上にわたってヒューマンインタフェースの研究と教育に従事された大先輩だ。

安村先生の研究室からは、後にイグノーベル賞を受賞することになる塚田浩二君（お茶の水女子大学）や、ERATO五十嵐プロジェクトで活躍されている渡邊慶太君といった多くの個性的な人材が輩出している。未踏プロジェクトの採択数も単一研究室としては最多ではないだろうか。

最終講義「「インタラクションデザインとSFCと私」では、日立時代のお話から（今からは隔世の感があるけれど、当時のスパコンは日本の独壇場で日立のS810とNECのSX-1/2 が世界最高速コンピュータとして凌ぎを削っていたのです）、SFC創立時のエピソードや学生との研究の話など盛りだくさんの内容で、予定の90分があっという間にすぎてしまった。

講演終了後の質疑の時間に、学生の指導についてどういうことに気をつけているか、とお聞きしたところ「学生のアイデアをなるべく尊重するようにしている／それでもこれはどうなのか、というところにはアドバイスする／いつも楽しくやるように心がけている」とお答えいただいて、なるほど安村研の明るくポジティブな雰囲気が伝わってくるような気がした。

私自身も2007年から大学にも身を置く立場になり、企業研究所から大学という、安村先生が歩まれた道を辿ることになった。そして人に何かを教えるというのはいったいどういうことだろうと自分なりに考えるようになった。もちろん教えることについて単一の答えはないし、教える相手やフェーズによっても違ってくるので日々模索の過程だが、ネガティブであるよりはポジティブに、そして皆の「持ち味」をなるべく引き出せるように心がけている（つもりである）。

また、個人的にはスタイルを見せることが重要かなと思っている。自分自身ではそれなりにスタイルを持って研究をしているつもりで、それが唯一無二ではもちろんないのだが、どういうところを大事だと思っているのか、揺るがせにしてはならないところ、力を抜いてもいいところ、がどこなのか、という方法論のひとつのインスタンスとして観てもらえればと思っている。

安村先生の講義を聞いて、そのあとも教えるって何だろうと考えていたら、シェーンという古い映画のことを思い出した。「シェーン、カムバック！」という最後のシーンで有名だが、いろいろ含蓄のある台詞が多いので好きな作品だ。その中で、シェーンが少年ジョーイに拳銃の使い方を教えるシーンがあって、こんなやりとりがある：

Shane: Most of them have tricks of their own.

One, for instance, likes a shoulder holster.

Another one puts it in the belt of his pants.

And some like two guns.

But one's all you need if you can use it.

Joey: Which is the best way?

Shane: What I'm telling you is as good as any, better than most.

シェーン：たいてい皆、それぞれに自分のやり方を持っている。たとえば肩掛けのホルスターを使いたがるのもいるし、ズボンのベルトにガンを差すのもいる。2丁拳銃を好む連中もいる。でも、使いこなせるんだったらひとつで充分だ。

ジョーイ：どれが一番いいやり方なの？

シェーン：今教えている方法は他のどれとも同じぐらいはいいし、大抵のものより優れているよ。

ということで、私も自分のやり方が better than most だと信じて観てもらうしかないのかなと思った昨日だった。

So all I can do is keep telling my own trick, hoping that it is better than any other.

P.S.: 安村先生は、退官後、SFCの非常勤をされる傍ら、「起業」に挑むとのことです。Mike先生の今後のますますのご活躍が楽しみです。

Permalink | コメント(0) | トラックバック(0) | 12:30

idトラックバック

2011-10-02

■ Ubicomp, Mark Weiser, 梅棹忠夫

先日、北京で開催されたユビキタスコンピューティングの国際学会 Ubicomp 2011 で、Mark Weiser の Scientific American論文"Computer for the 21th Century" 20周年記念のパネルセッションが開催された。

http://www.ubicomp.org/ubicomp2011/panel.html

セッションチェアは元Xerox PARC, 現Georgia TechのBeth Mynatt, パネリストはWeiserの同僚でもありPARCの所長でもあったJohn Seely Brown (JSB), UC IrvineのPaul Dourish, Georgia Tech のGregory Abowd, と私（暦本) だった。

Weiser の"Computer for the 21th Century" は、コンピュータサイエンスの論文としてもっとも重要かつビジョン指向の論文のひとつであり、その後の情報通信技術の方向性を決定づけたといってもよい。冒頭の美しい文章：

The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it.

（もっとも深淵なる技術はみえなくなる。それ自身が生活の一部として織り込まれ、不可分のものとなる）

からもわかるように、ユビキタスというのは単にコンピュータが沢山あることではなく、生活の背景に技術が溶け込んでいくありさまを指向している、つまりCalm Technology(静かな技術)というのがWeiserの哲学である。この論文が醸し出す一種独特な格調の高さと、永遠に新しく見える何かには、再読するたびに強く感銘を受ける。すべての古典がそうであるように。パネリストのGregory Abowdも、「年に一度は読み返している」と言っていた。

そこから20年、我々は何を成し遂げてきたか。そして未来に向けて何をすべきなのか。

パネルセッションはJSBのWeiserとの回想にはじまった。Mark Weiserはすぐれた科学者であると同時に傑出したビジョナリーであり、人間をもっとも深いレベルで考えている、という趣旨で、ショーペンハウアーの言葉を引いていた：

“Thus, the task is not so much to see what no one yet has seen, but to think what nobody yet has thought about that which everybody sees.”

私自身は、Weiser以降のUbicompの広がりが、文明の発達過程を逆にたどりながら、より生活の基盤となる分野に浸透してきていると指摘した。人類学者／文明学者であり日本を代表するビジョナリーでもある梅棹忠夫の「情報産業論」になぞらえて、文明の進化を内胚葉（農業時代）→中胚葉（工業時代）→外胚葉（情報時代）とするならば、Ubicompは外胚葉時代から逆に文明を遡り、農業（食）やエネルギー、健康などに浸透してきている。

パネルでは時間の都合上、詳しく説明できなかったが、梅棹は「知的生産の技術(1969)」のなかでも"Calm Computing"に関連することを述べている：

秩序としずけさ

… 知的生産の技術の話全体が、能率の問題としてうけとられやすいのである。しかし、じっさいをいうと、こういう話は能率とは無関係ではないにしても、すこしべつのことかもしれない。… これはむしろ、精神衛生のもんだいなのだ。つまり、人間を人間らしい状態につねにおいておくために、何が必要かということである。… 整理や事務のシステムをととのえるのは、「時間」がほしいからではなく、生活の「秩序としずけさ」がほしいからである。

（梅棹忠夫「知的生産の技術」)

国際会議の出席者がどれくらい梅棹忠夫とその言説を認知しているかはわからない（たぶんほとんど知られていないだろう）。が、個人的には文明を「装置＋社会の系(システム)」として捉えていた梅棹の文明論とUbiquitous Computing, Calm Computingの関連についてはもっと考えてみたいと思っている。それは、工学／技術としてのUbicompから、「システム文明論」としてのUbicompへの発展につながるという思いも含んでいる。

一方、Gregory Abowdはこのように拡大しているUbicompについて、領域としてのidentity crisisが起きていると指摘している。たしかに、すべてのコンピュータサイエンス（あるいはすべての「技術」）は何らかの意味でUbicompであるし、実際にUbicompの学会が捉えていないアクティビティのほうがむしろ重要になってきているのかも知れない。彼は問う：「もしMark Weiserが生きてたとして、彼はこの学会に参加するだろうか」。

パネルセッションのプレゼンテーション部分は録画されているのでより詳しくは以下からどうぞ：

http://www.slideshare.net/search/slideshow?searchfrom=header&q=%22ACM+UbiComp+2011+Panel%22

Permalink | コメント(0) | トラックバック(0) | 12:53

idトラックバック

2010-12-17

■ 修論(D論)参考

これも研究室内文書から転載します。前回のエントリと多少重複してますが、修論（D論）執筆についての注意ポイントです。これも同じく工学系（コンピュータサイエンス系）を想定してます：

まず、誰に読んでもらう文書（論文）なのかを認識する。修士論文の第一義の目的は、自分とは必ずしも専門（研究テーマ）が一致していない(ここ重要）所属学科の審査教員に、自分のやった研究の内容と意義を理解してもらうことである。

したがって、通常の学会・研究会論文よりも、研究の背景、動機、位置づけ、その分野の研究動向（サーベイ、関連研究）みたいなところは意識的にしっかりと書く。だいたいの構成は以下のとおり。

概要
謝辞
目次
図目次
序論　ー　副題があったほうがいいかも
 - 研究の動機、位置づけ　（英語だとMotivation)
 - 研究サマリ, コントリビューション（何を達成したのか）サマリ、と以下の論文構成
関連研究
自分のやったこと１
自分のやったこと２
。。。
結論と今後の展望
参考文献
付録

博士論文の場合は、さらに就職のための重要な資料となる（自分の研究能力を証明するために）。D論を英語で書くことをすすめるのはそのため。
まず目次案をつくり、それぞれの章で書くべきことを箇条書きレベルで入れていく（この段階でいちどチェックします）。これが各パラグラフのトピックセンテンス原案になる。あとは基本的にはひたすら書くだけだが、書いているうちに追加実験したくなることもあるので着手ははやめに。
概要は本当のサマリで、やった内容についてまとめる（字数制限がある場合もある）
前半（1/3ぐらい？）部分は、研究背景・立脚点について説明する。今後この分野を研究したい、と思っている人のための教科書のつもりで書くといいでしょう。
序論は研究背景（なぜこの研究をやるのか）、研究のアプローチ、結果のサマリ、以降の章構成を述べる。同じ分野の専門家が読んで、序論だけでこの研究の概略と意義が分かるように。以降を読むべきかの価値判断ができるような情報を入れる。
関連研究は本研究の前提となるもの。量が多い場合は大きくグループわけしてそれぞれ章を立てる。淡々と既存研究を紹介するだけでなく、研究動向全体の流れがわかるような指標（たとえば分類項目を立てたり、評価軸にマップしたりするような）を入れる。どういう観点から関連研究をまとめたのか、は自分の研究の立ち位置を説明することにもなり重要。価値のあるまとめかたは執筆者のオリジナリティでもある。
後半は自分のやった研究のところなので、どこが新規なのか、実験の手法、評価、どれくらいうまくいったか、などを順序だてて述べる。これは通常の学会論文と基本的には同じ。ただし修論は教育訓練の側面もあるので「実験手順（作業量）」「予備実験してだめだった例」など頑張りアピールに通じるところも書いていい（と私は思ってます）。
最後に結論でやったことをまとめ、今後の展望で、この研究の先にどんな課題／展望があるか、などを述べる。結論は、この研究から実証できた（根拠があり、自分で責任をもてる）内容。展望は、今後の話なので推定・想像が議論に入っていてもよい。博士進学の場合は、この展望が自分のこれからの研究計画のベースになっているとさらによい。
論文としての体裁（フォーマット）を意識する。パラグラフ分け、章立てから、図やグラフの書き方、実験手法の説明、その結果の吟味、参考文献やその参照の仕方など一連の論文フォーマットに則って書けているかどうか（要するに論文という文書の「型」を会得できているか。これも教育訓練の側面からはきわめて重要）。
用語の使い方に気をつける。最初に使うときに定義を説明しておく。審査教員が同じ専門分野とは限らないことを考慮して、普段の学会論文よりもさらに丁寧に。とくに略語はかならず何の略であるかを記載する。研究室内で符牒のように使っている言葉や言い回しを不用意に使わない。口語的表現も避ける。
細かいシステムの情報, 設計図、基板図、回路図、仕様書など入れたければappendixとして追加する。修論の場合、（査読付き）学会論文もappendixとつけるのもありでしょう（博士の場合は業績集を別途作る）。
参考文献は修論でも最低30ぐらいできれば50件ぐらいは欲しい。ページ数は最低でも50P以上か？（博士の場合、参考文献100件以上、最低ページ数100P以上かな？ページ数で規定するのはなかなか難しいところですが）
自分の対外発表一覧は参考文献とは独立してリストアップする。
ページ数について：厚いから優秀とは限らないが、修論／博論の評価基準の一つが「どのくらい本気で研究したのか／どのくらいの作業量だったのか」なので、尺度としてページ数はやはり大事。「書くことが少ない≒やったことが少ない」なので。言いたいことが沢山あって困る、ぐらいの修論はやはり読みでがある。といって無理やり文章を水増ししたり、スカスカの図を入れたりする必要はない（無理やり伸ばしたところは、ちょっと読めば一発でわかってしまう）。
学生レポートとの違い：学生レポートは、通常その作業の「動機（なぜそれをやるのか）」を議論することは必要ない（与えられた課題を正しく解いてそれをレポートすればよい）。一方修論／博論では、「研究の動機／価値」を理解してもらうところが重要かつ難しい。課題を解きました、だけでは不十分で、その課題の意義、位置づけ、既存研究との関係、新規性、など「研究の価値」に相当する部分に注意すること。たとえテーマを指導教官から与えられたとしても、自分なりに意義を考えることが大切。自分のやったことの価値を論理的に、説得性をもって人に説明できるスキルは、研究職であるかそうであるかに関わらず今後も重要なので、ぜひこの機会に身につけておいてほしい。
参考になりそうなのを挙げておく。修論執筆で参考になるのは、まず先輩のもの（主に構成、フォーマットの観点）だが、修論執筆者でも博士論文を参考にすることをおすすめする。博士論文をまねるぐらいのつもりで修論を書くとちょうどいい。たとえば：

Last Minute チェックポイント：

提出前に最低でも以下だけは絶対に再度確認：

提出期限・提出部数・フォーマット・提出方法。年度によって提出方法等が改訂されている場合があるので必ず自分で確認。
カバーページ：論文タイトル・所属・名前にミスプリがないか。
目立つところその１：abstract（全文）、第１章のはじめの部分、最終章（結論）のはじめの部分。このあたりに文章の誤りや誤字があると、それ以外のところをどんなに頑張って書いても意味がなくなる。文章として分かりにくくなっていないか、自分以外の人にも読んでもらうこと。
目立つところその２：あきらかにパラグラフが抜けている（章だけあって中身がない、文章の途中で終わっている）、メモ書きが残っている、などないように。後回しにして別のところを書いているうちに忘れてしまう。
目立つところその３：図中の文字や図のキャプション。ここも文章が変だったり誤字があると目立つ。
目立つどころその４：グラフ。理工系の教員ならかならず変数名や単位が気になる。それが抜けていると１００％指摘される（論文の内容とは無関係に指摘できるところなので）。
目立つところその５: 数式、特殊文字（βとかΔとか)。画面上でちゃんと見えていてもプリントしたときに文字化けしている可能性がある。必ず紙面で確認。
目立つところその６：参照が"??"になっている(latexエラー)。参照先がない、文献参照が失敗している、これも目に飛び込んでくる。

チェックポイント（その２）：

これも内容というより編集レベルでのチェックポイントです（すべて実際に遭遇したミスorz）。

図、参考文献番号の参照もれ、Latexの指示間違いがないように。 Figure ? などなっているところがないか。LaTeXエラーファイルを見て確認。
参考文献番号と、参考文献は合致しているか。「***というシステム[10] 」という本文に対応した10番の参考文献が全然関係ないものを指していないように。
参照していない図を載せていないか。図だけあって、対応する本文がない。図番号も本文に参照がない。
逆に、参照だけして図が存在しないことはないか（Latexなら参照すべき図のtagが見つからないので?となるが)。
図と説明文(キャプション)は対応しているか。 (図で取り込むファイルの指定を間違えるとこうなる)
キャプション中の、(a) (b)などの図への参照に対応する記号が図中にあるか。
図の参照順序は正しいか。　本文中で　「図 4 では、図 3 では」、と図番号が逆転しないように。図番号は本文での参照順にするべき。
図 / Figure 表 / Table などの呼称を統一する。スタイルファイルを変えるとこうなる場合がある。キャプションではFigureと言っていて本文では図　と呼んでいるなど。
図はグレイスケールで印刷しても意味が通じるように。色がないと識別できない図は(1)媒体が白黒印刷の場合破綻する (2)ユニバーサルアクセスではない(色覚に関して)ので避けるべき。
固有名詞、人名、組織名などに誤りはないか。日本語の論文に英語が混ざるときにスペルチェックが甘い場合がある。(信じがたいことに自分の所属学科や謝辞する相手の氏名すらも間違えている場合がある）。
参考文献をbibtexなどで自動生成している場合に、生成結果をチェックすること（日本語の文字化け、姓／名の順、スペルなど）。

idトラックバック

2010-12-15

■ よい論文の書き方

研究室用に書いた文書を転載します。主に工学系（コンピュータサイエンス系）分野の査読付き学会や論文誌に投稿することを想定しています。

以下は論文を書くときに個人的に気をつけていることです：

メッセージをシンプルに：要するに何が言いたいのかが一言でサマライズできていること。記憶に残ること。
メッセージが伝わらないと、そもそも査読で落とされるし、たとえ学会で発表できたとしても誰も覚えていてくれない。実際、国際学会でも発表論文の多くが誰にもリファーされず、翌年になると忘れられている (どんな論文がどのくらい参照されているかはMicrosoft Academic Searchなどでわかる）。
なぜこの問題が重要なのか・問題の原因は何か・どんな解決案を提案するのか・その効果は本当か・他にどんな研究があるか（なぜそれらの既存研究ではだめなのか）・誰のために役に立つのか・どう発展できるか（どんな応用があるか）、などを明確に述べる。
これらの項目は、論文を書き始めるときではなく、研究を始めるとき（アイデアを思いついた瞬間）に、まずまとめておくのが望ましい。この箇条書きがスムーズに出てくるのが「素性の良い研究アイデア」と言える。「あ、ひらめいた」というときに、３.の各観点からアイデアを吟味してみる。また「もしこのネタ（アイデア）で論文書くとしたら、どうなるだろう」と論文ストーリーを書きだしてみる。たぶん10分もかからない作業だが、こうやって言語化することでアイデアの良し悪しや素性が見えてくるし、最初のひらめき以上にアイデアを膨らますことができる。もうひとつの指標としては「論文タイトルがすっきりと決まる」ような研究アイデアは素性がいい。論文を書き始めるときも、まずこれらの要素がちゃんと自分で整理できていると「書けそう」という気になる。
逆に、かなり作り込んでしまってから「これどうやって論文にしよう」と悩みだすと苦しいし、たいていうまくいかない。(最近こういう相談をよくされるので強調しておく。考えなしにやりだしてもダメ。出来た！これでいける、と思ってもうまくいかないのが研究。ましてや....）作っているうちに何かみえてくるだろう、というのはリスキーな考え方。また、ぱっと見素性の良くなさそうなアイデアは結局素性がよくない場合が多い。 最初の方向を間違うと一生懸命頑張っても時間が無駄になる。
査読者フレンドリーに。査読する人の立場になれば逆にどんな論文が「良い」かがわかる。テクニカルには「通る論文が良い論文」だし「論文は査読者のために書くもの」とも言える。査読する人は、タイトルを確認して、論文全体をパラパラと見渡して、図を見て、abstractとconclusionを読んで、ぐらいの段階である程度は判定態度を決めている。そこまでで「つまらない」と思われるともうだめ。文章だけではなく、全体のレイアウト、版面としての美しさにまで気を配るべき。
査読者フレンドリーに(その２)。査読者は神様ではないしすべてのテーマに精通しているわけではない。普通の人間なので内容が分かってもらえない限り落とされる。落とされるかなりな理由が研究内容が悪いからではなく、研究の内容や価値を伝えられなかったから。 査読者がまだ知らないことを書かなければ論文としての新規性はないわけだが、「新しくかつ価値がある」ことを理解してもらうのは想像以上にむずかしい。人間は新しいことに出会うと、それを既存の知識に照らし合わせてその中で理解しようとする。つまり新しいものであるがゆえに「＊＊と何がちがうのか」と批判されがちである。そこを先回りして、査読者が知っていそうな「既存の知識」との差分が説明されていないとならない。したがって、単にやったことを羅列するのではなく、メリハリをつける。どこが論文の価値なのか、何が新しいのか、をできるだけていねいに、筋道を立てて、査読者にわかるように書く。
「なぜ」この研究をやるのか、をそもそも説明できない人が多い。研究に従事しているうちに、そもそも何でそのテーマをやっているのかが（ある意味自明になりすぎて）自分で説明できなくなる。ので、研究を始めるときに文章としてきちんと記録しておいたほうがいい。
図を効果的に。英語力で勝負できない日本人はせめて図は綺麗に的確に。査読するときにも図に気合が入っている論文は熱意が伝わってくる。特に英語論文に慣れていない人は、図を整備しながらストーリーを作って行くぐらいのほうが楽。図の説明(caption)を詳しめに書くのも個人的にはおすすめ（本文と多少重複していても構わない。対応する本文を読まなくても図だけで意味が理解できるように）。*1
それぞれの図の存在理由を吟味する。また図のサイズにも気をつかう。あまり本題と関係ない詳細なシステム構成図や、単にページ稼ぎのような画面例などを入れないように。また図中のフォントサイズにも注意（印刷したときにちゃんと読めるように）。
関連研究（参考文献）を吟味する。査読で一番痛いのは「この論文に似ている○○○が参照されてないじゃないか」と指摘されること（それが査読者自身の論文である場合も結構ある）。その分野のことを知らないで研究していると思われるとまずい。さらに、先行研究があっても知らないふりをした、と思われると研究者倫理上も致命的。一方、あまり関係ない論文をずらずら列挙してもページ稼ぎだと思われる。
ページ制限限界まで書く。とくにショートペーパー(2page, 4page)で、論文の最後が半端に空いているのは「内容の乏しさ」の象徴に見えてしまう。ショートペーパーの場合、普通は書きたいことをそぎ落としてページに収めている、という前提なので「余白がある＝ショートペーパーでもページが余るぐらい内容に乏しい」ということになる。
正しい文章で（あたりまえか）。「1パラグラフ1主題」とか「事実と意見を混用しない」、「論理を飛躍させない」など「理科系の作文技術」（中公新書）は基本。技術英語関係の授業が取れたら受講しておいたほうがいい（パラグラフや文章構成手法などは英語に限定されないので、日本語もうまくなります）。
研究の心構えについて「素人のように考え、玄人として実行する」は必読。
英語で書く場合、せめてスペルや数の一致や"a"と"an"などはミスがないように。スペルチェッカーがある時代にスペルミスするのは語学力以前の問題であり、論文を真面目に書いていないと査読者は判断します。LaTeXの参照ミス(図番号が"??"になるなど）も同様。
英語ネィティブチェックは魔法ではない。英語の表面的なミスは直っても、当然だがロジックやパラグラフ構成など内容に関わるところを直してくれるわけではない。またロジックがあまりに不明瞭だとチェックするほうも想像で修正しだすので、修正結果の品質が著しく悪くなる。あくまで自分できちんと書くように努力するのが大前提。
そもそも、投稿要領に「よい論文の書き方・どうすれば採録されるのか」というのがちゃんと掲載されている場合が多い。審査の手の内を明かしてくれているわけなので、これらを読まずに論文通らないと言っていても始まらない。

　参考文献

Permalink | コメント(4) | トラックバック(7) | 09:49

*1：最近は、最初の図(Figure1)として研究内容が一目でわかるような図を入れるのが流行している。これも「サビ頭原則」のバリエーションか。

idトラックバック

2013-04-06

■ MS Word で LaTeXのソースを書く (macos)

2013-02-03

■ 安村先生最終講義 - Most of them have tricks of their own

2011-10-02

■ Ubicomp, Mark Weiser, 梅棹忠夫

2010-12-17

■ 修論(D論)参考

Last Minute チェックポイント：

チェックポイント（その２）：

Reference:

2010-12-15

■ よい論文の書き方

参考文献

　参考文献