投稿
いろいろと調べてみたら
https://www.amazon.co.jp/dp/B07W6ZKJWJ/ref=psdc_2151981051_t2_B07T1G26NX
という「超軽量薄型PC」と打ち出してあるだけあって、ビックリするぐらい軽量で、「商品重量4.54g」と書いてある。たぶんCPU１個分よりも軽い。
こういうのは単なる入力間違いだと思うけど、こういう単なる入力間違いを自動的に検出できる機能があれば面白いと思う。例えば、病院の薬剤の量などを入力間違いしたときに自動的に注意してくれるシステムなどにも使えるのではないかと思う。
2019年11月30日土曜日
2019年11月12日火曜日
Julia でパッケージを作る
Julia で公式パッケージに登録するのは比較的簡単で、やり方としては
Julia でのパッケージの作り方
https://qiita.com/cometscome_phys/items/989389db3540ebd9e026
がとても参考になる。
ただ、若干情報が古いようで、「リリースの登録」にある
https://github.com/attobot/attobot
については、Registrator.jl によって登録するようになっている。
https://github.com/JuliaRegistries/Registrator.jl
具体的には、
https://pkg.julialang.org/registrator/
で「Log in to GitHub」を使ってログインして、
URL of package to register:
Git reference (branch/tag/commit):
Release notes (optional):
を入力して、「Submit」を押せばよい。
こうすると
https://github.com/JuliaRegistries/General/pulls
にNew packageとして登録されるので、これが承認されるのをじっと待てばよいことになる。
承認待ちのリストを見ると、だいたい一週間以内には承認されるようだ。
他に参考になったのは
覇権を取る、Juliaパッケージの作り方 Part2
https://logmi.jp/tech/articles/321564
のあたり。
Julia でのパッケージの作り方
https://qiita.com/cometscome_phys/items/989389db3540ebd9e026
がとても参考になる。
ただ、若干情報が古いようで、「リリースの登録」にある
https://github.com/attobot/attobot
については、Registrator.jl によって登録するようになっている。
https://github.com/JuliaRegistries/Registrator.jl
具体的には、
https://pkg.julialang.org/registrator/
で「Log in to GitHub」を使ってログインして、
URL of package to register:
Git reference (branch/tag/commit):
Release notes (optional):
を入力して、「Submit」を押せばよい。
こうすると
https://github.com/JuliaRegistries/General/pulls
にNew packageとして登録されるので、これが承認されるのをじっと待てばよいことになる。
承認待ちのリストを見ると、だいたい一週間以内には承認されるようだ。
他に参考になったのは
覇権を取る、Juliaパッケージの作り方 Part2
https://logmi.jp/tech/articles/321564
のあたり。
2019年11月9日土曜日
beamerのコンパイル速度を上げる
beamerのコンパイルが遅いので調べてみたら、ある特定のページだけをコンパイルする方法があった。
https://tex.stackexchange.com/questions/27351/speed-up-beamer-compile-time
のところの最初の Answer に載っているが
\includeonlyframes
を使えば可能である。
「いま編集しているページをコンパイルして確認したい」ということは多いので、これによって解消できる。
一方で、１ページだけコンパイルすると preamble の部分 (\begin{doument}よりも前の部分）がコンパイルに時間がかかっていることが分かる。
preamble だけを別にコンパイルする方法が
https://ubutun.blogspot.com/2015/06/precompiled-preambleplatex.html
に載っているので、これを\includeonlyframesと合わせて試してみたら、相当コンパイルが速くなった。
ただ、preamble の部分を別にコンパイルしたものをチェックしてみたら 8MB もあった。つまり、beamer をコンパイルする、というのは１ページだけであっても8MBぐらいバイナリーファイルを生成するようなコンパイルをしているわけであって、beamer のコンパイルが遅いのも納得である。
うーん、latex も C言語みたいにオブジェクトファイルとか生成出来たら、べんりなのかもしれない。
https://tex.stackexchange.com/questions/27351/speed-up-beamer-compile-time
のところの最初の Answer に載っているが
\includeonlyframes
を使えば可能である。
「いま編集しているページをコンパイルして確認したい」ということは多いので、これによって解消できる。
一方で、１ページだけコンパイルすると preamble の部分 (\begin{doument}よりも前の部分）がコンパイルに時間がかかっていることが分かる。
preamble だけを別にコンパイルする方法が
https://ubutun.blogspot.com/2015/06/precompiled-preambleplatex.html
に載っているので、これを\includeonlyframesと合わせて試してみたら、相当コンパイルが速くなった。
ただ、preamble の部分を別にコンパイルしたものをチェックしてみたら 8MB もあった。つまり、beamer をコンパイルする、というのは１ページだけであっても8MBぐらいバイナリーファイルを生成するようなコンパイルをしているわけであって、beamer のコンパイルが遅いのも納得である。
うーん、latex も C言語みたいにオブジェクトファイルとか生成出来たら、べんりなのかもしれない。
2019年11月7日木曜日
Android の Termux のplatexで日本語PDFを作る
Android のタブレットで PDF を生成できるか、というテストを行ってみたら、上手くできたのでステップを書いておく。
1. Google Play で Termux をインストールする
2. Termux の中で termux-setup-storage を実行してファイルシステムへのアクセス権限を付与する
3. pkg update
4. pkg upgrade
5. (オプション作業) sshd をインストールするとパソコンからログインしてキーボードで作業できるので便利である。
pkg install openssh
でインストールした後に ~/.ssh/ に普段通り鍵を置いておいて、Termux で
sshd
とする（ポート番号は 8022になる）。終了するには
pkill sshd
である。
6. pkg install texlive texlive-bin texlive-fontutils texlive-langjapanese texlive-tlmgr ghostscript wget
必要に応じて他のパッケージもインストールする
7. これで pdflatex は使えるようになっているので、適当に英語だけのtest01.texをviなり他のエディタで作成して
pdflatex test01.tex
で test01.pdf ができることを確認する。test01.pdf は Termux から
termux-open test01.pdf
とすれば、Android で普段使っている PDF リーダーが起動する。
8. pdflatex だと日本語が通らないので、日本語を通すために IPAex フォントをインストールする
mkdir ~/.fonts
cd ~/.fonts
wget https://ipafont.ipa.go.jp/IPAexfont/IPAexfont00401.zip
unzip IPAexfont00401.zip
mv IPAexfont00401/ipaexg.ttf ~/.fonts
mv IPAexfont00401/ipaexm.ttf ~/.fonts
rm -rf IPAexfont00401*
9. mktexlsr
10. fc-cache -v
11. ~/.fonts/cid-x.map のファイルを以下の内容にする
rml H ipam.ttf
gbm H ipag.ttf
rmlv V ipam.ttf
gbmv V ipag.ttf
2. IPAexフォント Ver.004.01
https://ipafont.ipa.go.jp/node193
3. LaTeXdvipdfmxdvi を pdf に変換
http://www.yamamo10.jp/yamamoto/comp/latex/dvipdfmx/dvipdfmx.html
1. Google Play で Termux をインストールする
2. Termux の中で termux-setup-storage を実行してファイルシステムへのアクセス権限を付与する
3. pkg update
4. pkg upgrade
5. (オプション作業) sshd をインストールするとパソコンからログインしてキーボードで作業できるので便利である。
pkg install openssh
でインストールした後に ~/.ssh/ に普段通り鍵を置いておいて、Termux で
sshd
とする（ポート番号は 8022になる）。終了するには
pkill sshd
である。
6. pkg install texlive texlive-bin texlive-fontutils texlive-langjapanese texlive-tlmgr ghostscript wget
必要に応じて他のパッケージもインストールする
7. これで pdflatex は使えるようになっているので、適当に英語だけのtest01.texをviなり他のエディタで作成して
pdflatex test01.tex
で test01.pdf ができることを確認する。test01.pdf は Termux から
termux-open test01.pdf
とすれば、Android で普段使っている PDF リーダーが起動する。
8. pdflatex だと日本語が通らないので、日本語を通すために IPAex フォントをインストールする
mkdir ~/.fonts
cd ~/.fonts
wget https://ipafont.ipa.go.jp/IPAexfont/IPAexfont00401.zip
unzip IPAexfont00401.zip
mv IPAexfont00401/ipaexg.ttf ~/.fonts
mv IPAexfont00401/ipaexm.ttf ~/.fonts
rm -rf IPAexfont00401*
9. mktexlsr
10. fc-cache -v
11. ~/.fonts/cid-x.map のファイルを以下の内容にする
rml H ipam.ttf
gbm H ipag.ttf
rmlv V ipam.ttf
gbmv V ipag.ttf
12. 日本語を含む test02.tex を作成して
platex test02.tex
dvipdfmx -f ~/.fonts/cid-x.map test02.dvi
とすると、日本語を含むPDFとしてtest02.pdfができるので、これを
termux-open test02.pdf
で開いて内容を確認する。
参考にしたサイト
1. TermuxでSSH Serverを起動する
https://qiita.com/dev100kg/items/11fdaac265c35e7776642. IPAexフォント Ver.004.01
https://ipafont.ipa.go.jp/node193
3. LaTeXdvipdfmxdvi を pdf に変換
http://www.yamamo10.jp/yamamoto/comp/latex/dvipdfmx/dvipdfmx.html
2019年11月6日水曜日
Vimの読み方
もうひとつ最近気になっているのが Vim の読み方で正しくは「ヴィム」という発音に近い、ってことです。Vim の解説を読んでみると
http://vimdoc.sourceforge.net/htmldoc/intro.html#pronounce
にあるように「Jim っていう名前はジェー・アイ・エムじゃなくてジムって一つで読むだろう、だからVim はヴィー・アイ・エムじゃなくてヴィムなんだ」というようなことが書いてあるのです。
個人的には、「だったら、USAも名前の一種だから「ウサ」って読むってことなのか？」とか思ったりで（そもそも Vim も Vi IMproved から来ているので一単語ではない）、やはりこのあたりは英語のネイティブに聞いてみないと分からないのかも、と思ったりする日々なのです。
http://vimdoc.sourceforge.net/htmldoc/intro.html#pronounce
にあるように「Jim っていう名前はジェー・アイ・エムじゃなくてジムって一つで読むだろう、だからVim はヴィー・アイ・エムじゃなくてヴィムなんだ」というようなことが書いてあるのです。
個人的には、「だったら、USAも名前の一種だから「ウサ」って読むってことなのか？」とか思ったりで（そもそも Vim も Vi IMproved から来ているので一単語ではない）、やはりこのあたりは英語のネイティブに聞いてみないと分からないのかも、と思ったりする日々なのです。
「査読」という古い文化について
最近、Githubをそれなりに使い始めていろんな機能があるなぁ、と思い始めているわけですが、その中で「査読」っていうプロセス自体はGithubの時代には古いやり方なのかもしれない、と思ったりしています。（個人的な感想だけど。）
Githubの機能にはたくさんの機能がありますが、そのなかでも Issues と Pull Request が良い機能だと思います。
従来の査読の問題点だと思うのは
１．基本的に密室で行われているので、査読者と編集者の意向に左右されやすい（査読者などには当たり外れがある）
２．一度 publish されてしまうと、そのあと間違いがあっても余程の間違いでないと修正されない
３．論文を読んだ人が新しいアイデアとかできても、それを掘り下げるような議論をする場所がメールだったり国際会議だったりに限定されてしまう
４．arXivにあがっている原稿と比べると、査読を通ったあとの最終稿のほうが質は当然上回るけど、ほとんどの場合はarXivの原稿の時点で研究の核となるアイデアは理解できる。つまり、arXivの原稿を読んでいるだけでも、かなりの研究ができる時代になり、査読の相対的重要性が下がった
などなどだと思います。
このあたりが Github で論文を公開して、そのあとを Issues なりでフォローしていくようになれば、かなり改善できる考えられます。
まぁ、実際にやろうとしたら脈々と続いてきた古い文化をなくすので相当大変だと思います。その一方で例えば「Githubの運営者が勝手に編集できてしまうのでは？」とかいう疑問などについては「Gitlabとかを複数たててミラーリングする」なり「論文掲載にブロックチェーンの情報を追加して改ざんすると分かるようにする」なり、いろんな疑問も現在のITを使うと結構クリアできるのでは？と楽観的に考えたりもしています。
もちろん、査読にもいい面が当然あるわけで、世の中で使われているわけです。
ただ、Github など最近のものに触れていると、そういったものも変わっていくのが世の中にとっては必然なのかもしれないなぁ、と思ったりする、というところです。
Githubの機能にはたくさんの機能がありますが、そのなかでも Issues と Pull Request が良い機能だと思います。
従来の査読の問題点だと思うのは
１．基本的に密室で行われているので、査読者と編集者の意向に左右されやすい（査読者などには当たり外れがある）
２．一度 publish されてしまうと、そのあと間違いがあっても余程の間違いでないと修正されない
３．論文を読んだ人が新しいアイデアとかできても、それを掘り下げるような議論をする場所がメールだったり国際会議だったりに限定されてしまう
４．arXivにあがっている原稿と比べると、査読を通ったあとの最終稿のほうが質は当然上回るけど、ほとんどの場合はarXivの原稿の時点で研究の核となるアイデアは理解できる。つまり、arXivの原稿を読んでいるだけでも、かなりの研究ができる時代になり、査読の相対的重要性が下がった
などなどだと思います。
このあたりが Github で論文を公開して、そのあとを Issues なりでフォローしていくようになれば、かなり改善できる考えられます。
まぁ、実際にやろうとしたら脈々と続いてきた古い文化をなくすので相当大変だと思います。その一方で例えば「Githubの運営者が勝手に編集できてしまうのでは？」とかいう疑問などについては「Gitlabとかを複数たててミラーリングする」なり「論文掲載にブロックチェーンの情報を追加して改ざんすると分かるようにする」なり、いろんな疑問も現在のITを使うと結構クリアできるのでは？と楽観的に考えたりもしています。
もちろん、査読にもいい面が当然あるわけで、世の中で使われているわけです。
ただ、Github など最近のものに触れていると、そういったものも変わっていくのが世の中にとっては必然なのかもしれないなぁ、と思ったりする、というところです。
登録:
投稿 (Atom)