2017年9月 8日 (金)

古めの論文でテキスト選択がおかしい時の対処法

Multicolumn

例えば、Acrobatを使っているときに、テキスト選択ツールで、左のカラムを文章をコピーしたい。一行しか選択しないのなら問題はないが、複数のラインになるとまれに、右のカラムにまで選択範囲が行ってしまって、そっちじゃねーよとなる。

古めの論文にありがちですね。上のイメージは2005年のNeuron。

これは、古めの論文だとPDFに文章の構造を指定するタグをちゃんと埋め込んでいないため、PDFリーダーが賢くないとカラムの構造の類推に失敗することから起こる問題のようです。というかAcrobatでもダメなのでタグが無いようなPDFは出版社が悪いと思う。

ウィンドウズの場合は、PDF-XChange Editorだったら下の様に簡単にボックス選択できるのでなんとかなる。PDF-XChange Editorはフリーで、互換性まったく問題なし、本家Acrobatより速いのでおすすめです。

Pdf_xchange

Macな方の場合、PDF-XChangeがないのでAcrobatを使うしかないのが問題でしたが、最近Acrobat Proならばタグを自動で埋め込むことで大部分解決することを発見。たまにPDFからテキストをコピペするとスペースが抜けている場合がありますが、これもタグを削除して、自動生成し直すと治る。

やり方は「既存の PDF へのタグの追加」を参考に、ツールからアクセシビリティを選んで、文書にタグを追加を選択する。そうすると文章の構造を適当に認識してタグを追加してくれる。これで、大抵は治る。Acrobat Proじゃないといけないのが残念。

タグを直したほうが、ボックス選択よりも文章の選択が細かにできるので、Proのライセンスあるのならタグを追加するのが一番よい。PDF-XChange Editorでタグの編集とか追加はちょっと試したが、できなそうかな。。

なぜアクセシビリティにそんな機能があるのかというと、文章の読み上げ機能にカラムの構造の正しい認識が必要なため。

2017年8月 1日 (火)

Juliaやってみよう。五日目。Pythonと速度比較。

def test():

    Ne=800;                 Ni=200;
    re=rand(Ne,1);          ri=rand(Ni,1);
    a=vstack([0.02*ones((Ne,1)), 0.02+0.08*ri]);
    b=vstack([0.2*ones((Ne,1)),  0.25-0.05*ri]);
    c=vstack([-65+15*re**2,  -65*ones((Ni,1))]);
    d=vstack([8-6*re**2,       2*ones((Ni,1))]);
    S=hstack([0.5*rand(Ne+Ni,Ne), -rand(Ne+Ni,Ni)]);
    v=-65*ones((Ne+Ni,1));    # Initial values of v
    u=b*v;                 # Initial values of u
    firings=[];             # spike timings
    for t in range(1000):            # simulation of 1000 ms

        I=vstack([5*randn(Ne,1), 2*randn(Ni,1)]); # thalamic input
        fired=find(v>=30);    # indices of spikes
        if fired.any():

            if firings == []:
                firings=vstack([t+0*fired,fired]).T
            else:
                firings=vstack([firings, vstack([t+0*fired,fired]).T]);

            v[fired]=c[fired];
            u[fired]=u[fired]+d[fired];
            I=I+sum(S[:,fired],1).reshape(-1,1);

        v=v+0.5*(0.04*v**2+5*v+140-u+I); # step 0.5 ms
        v=v+0.5*(0.04*v**2+5*v+140-u+I); # for numerical
        u=u+a*(b*v-u);                 # stability

全快の記事では、Izhikevichモデルを1000 msほどシミュレーションした時のjuliaの実行時間は785 msでした。

速度比較のため、上記のようなnumpyバージョンを作ってみたところ、253 msでした。

Python版ではfiredを調べて空だったらシナプス入力の計算を端折るようにしたので、そのせいで速い可能性もあるので、juliaも同様に

if length(fired) > 0

という風にチェックを入れたら625 msまで速くなった。それでもPythonが三倍くらい速いとかあり得ない。なにかおかしい。

もしかしたらjuliaのJITが温まる前なのかな。ループを長くしたら逆転するかも。PypyのJITが温まるまで4秒くらいとか聞いた気がするので、シミュレーションを1000 msから30000 msにしてみる。

Python2   23.4 s
julia    34.48 s

結果、差はだいぶ縮まったが、それでもPythonがちょっと速い。これならJITのあるjuliaが有利な条件だと思うけども。ふーーむ。juliaの偉い人が颯爽とアドバイスくれたりないかなぁ・・。

まあKyle Barbary氏の2014年のブログ記事の信憑性がましてしまった。

«Juliaやってみよう。四日目。@timeでプロファイリング

広告欄


やっつけタイムライン

広告欄

はてブ

人目の訪問です。

  • follow us in feedly

    かなり更新が不定期なため、RSSリーダーをオススメします。現在Feedlyに122人登録頂いています。多謝!RSSを表示

    ブログランキング用 にほんブログ村 IT技術ブログ Pythonへ ブログランキングならblogram






    Jenny Mayhem
2017年9月
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

IT技術注目記事

無料ブログはココログ