査読者はその論文しか見ない。従前の議論なんかフォローしてないのでself-containedにする 読んだらわかるやろ的な態度はNG。わかってほしいことはちゃんと書く

産学連携というのは一目美しい。公の目的のために、産業界がカネや資源を提供し、知恵のある研究者がそれをつかって研究する。もしくは、研究者の知見を産業界が応用して公に利益に役立てる。 半導体の開発や新しいモビリティの開発、地方創生のための農作物…

複数論文を同時に出すのは考えもの。 - コンテクストスイッチのコストが半端ない - 単純に追い込みの時期に時間が1/2になる ただし、一つの論文はメインじゃないとか、一つの論文は改訂版とかならよいかも

査読の結果がたくさん帰ってきた。 データの扱い、実験の仕方が突っ込まれた。 人工データで実験=>実データでやれや プロプライエタリ実データで実験=>倫理観どうなっとるんじゃ。公開データでやれや再現性どうなっとるんじゃ。 実データをオープンにすると…

actor-critic理論というものがある。強化学習の枠組みでactorの行動をcriticが制御するような構造になっている。文章を書いている時に書き苦しさを感じるのはこのcriticが強すぎるのではないかと感じる。一旦、リミットを外して書き殴るということが必要なの…

無料でPrivateが使えるプランができた今すべてをGitHubにあげることを目標にする。

delma.hatenablog.com delma.hatenablog.com 最近、Apple PencilでiPadに書きつけた手書きのメモをjupyterで from IPython.display import Image, display_png Image("tegaki_memo.jpg") と表示することで、メモ書き（＝構想）、コード（＝作業）を一体化し…

今回のプレゼンは微妙。 やはり覚え込むまで練習しないとだめだ。しゃべるときに迷うようであればすでにだめ。覚えていないことで自信がないから早口になったりするし。 準備不足。 しかし、時間はかけた気がする。とにかくスクリプトがぜんぜんできなかった…

delma.hatenablog.com delma.hatenablog.com delma.hatenablog.com delma.hatenablog.com プレゼンについていろいろつらつら考えてきた。 今回はひたすらスクリプト作成から入った。 時間がめちゃくちゃかかった。だいたい20分のプレゼンで10時間くらいはか…

最初に書く \documentclass[sigconf]{acmart} こうすればカンファレンス情報落としたArXiv用 \documentclass[sigconf, nonacm, screen]{acmart} こうすればダブルブラインド対応 \documentclass[sigconf, anonymous]{acmart}

数週間は同じタスクに集中する 1日うち3時間は割くが、だらだらやり続けない。疲れてきたら、あるいは沼にハマってきたら休憩して別のことをする。もしくは散歩する。 人に話す

前提 AWS EC2 (ubuntu) Python3.6.3 バックグラウンドで動かす ssh接続が結構切れるので基本バックグラウンドで動かすべし nohup jupyter notebook > /dev/null 2>&1 & Elastic IPにすべし EC2はデフォルトだとインスタンスを停止するたびにIPが変わる。いち…

delma.hatenablog.com 課題点 * サーバーでやったのか、ローカルでやったのかわからなくなる。 どこかにまとめるべき？ * RでやったのかPythonだったのかよくわからなくなる。 どっちかにまとめるべき？ →日誌を書いたほうが良い気がしてきた。 1タスク1ノー…

chrome.google.com そもそも使ってなかったのがおかしいんだけど、これまで、論文はPDFをZoteroにドラッグ・アンド・ドロップしてメタデータを抽出していた。 この方法だと殆どの場合うまく書誌データを拾ってくれない。 Zotero-connectorを使えば、Google S…

論文を一本出し終わったので反省会。 今回はすべてRで、しかもローカルでやりきった。 メモリをそんなに食わない研究だったのでローカルでやったのは問題ない。 ただ、クラウドでやったほうが日々の仕事とコンフリクトしないからよかったかも。 Rを使ったの…

サーベイはアウトプットに利用しやすいようにまとめる サーベイが使われるのは、 Literature Review/Related Workでの言及 Reference レビューセクション以外での数字やデータ、手法等への言及 Referenceにどうせ載せるのであるから、Zoteroに研究論文一本に…

論文生産のスピードを上げたい。 アイデアはあるしデータもある。ないのは技術と知識、時間

グローバル変数が危険すぎる。 特にRStudioだと雑になりがちなので、実行前に必ずクリーンアップする。 3時間程度溶かしてしまった。。

これまでも散々書いているが、データ加工プロセスは細かく切ってディスクに落としておく。また、それぞれの小プロセスのvalidationをしつこくやる。 これをしないとヘンテコな結果になる。

研究、地道に計画立ててコツコツやって成果が出ればいいが、だいたい上手くいかずに気持ちがしぼんで投げ出したりする。 しかし、それでも立て直してうどうだやってるとある時一気に進む。 進まなくてもうだうだ進めることが大事だし、進められる時は一気に…

連休中に研究を進めようかと思ってたがとってもエンジンがかかるまで時間がかかる。 distractionがたくさんあるというのもあるけど、たっぷり寝てもだめだったり。 たっぷり寝て、 その研究への興味関心を高めて タスクを細分化してやることを明確化して 携…

やりたいプロジェクトが多すぎるということもあるが、一週間のうちにプロジェクト間のスイッチを何回も行う。前そのプロジェクトをやっていた時期から時間が経つと集中が始まるのに時間がかかりすぎる。 よくあるのは、机に座ってやる気を出すために、spotif…

分析稼業はループの繰り返し。 あたりをつけて分析してそこで得られた知見をもとにまた計画を練り直してという感じ。 データが新しくなれば、手法が新しくなれば、前の知見は通用しないことが多い 結果的に無駄なぐるぐるを繰り返すことになるが、それは結果…

delma.hatenablog.com 書いてから２週間経ったので振り返り。 新ルール（仮） とっかかりはrmdかjupyter。 検索可能性が上がるようにproject毎にまとめる。 projectごとにレポジトリを作る 作業のおおまかな計画的なやつはreadmeを更新していく。タスク管理…

課題感 様々な分析しごとをどうオーガナイズするかめちゃくちゃになっているのでルールを決めたい。 現状 研究 jupyter notebookかRmarkdownで実施。コードを書く前に動作を確認したいときはSQLミドルウェアも使う。 Pythonコードはgithubで管理。 最近あま…

年も改まったことだし論文管理環境を再構築する。 もともとmendeley派だったが、色々トラブルが多く一度Zoteroに以降した。ただ、ZoteroとSugarsyncを並行して使っていたためおかしなことに。 丸一日格闘した結果、Zoteroの動作をようやく理解したのでメモし…

リサーチを効率的に進めるには段取りやスケジューリングがすべてと言っていいほど重要。 何をどこまでいつやるか。 何をするか決まればあとは作業するだけ。ここは純粋に作業なので大して脳には負荷がかからない。 むしろ何をすべきか、様々な条件から最適な…

そそっかしい性格である。 当然、慎重さが要求されるコーディングやデータの管理には向かない。 特に、疲れてくると適当になる。 learning by doingで良い局面ならそれでもいいが、一旦コンピューターに計算を投げるという工程では、正確を帰さないと時間が…

研究は熟考し呻吟し深い考察を得ることが真髄であることは論を俟たないが、生産性革命、働き方改革の時代、研究者に時間を浪費することは許されていない。 研究の質を犠牲にすることなく最速でアウトプットを出すためには時間の浪費を避けなければいけない。…

データが大きいということは様々なリスクがあるということ。基本はしっかりアセスメントを行ってから分析を実行すべきということ。 まずは、メモリ管理。せっかく計算ができてもメモリエラーで止まってしまっては意味がない。一気に計算させて大丈夫なのか、…