Skip to content

bioruby であそぶ

17-9月-17

自分用メモ

古い情報が多いので少しずつ切り貼りしていく。

参照情報

BioRuby の使い方
・独自のシェル機能の説明が続いてなかなか本論に入らない。本当にシェル機能は必要なのだろうか

塩基・アミノ酸配列を処理する (Bio::Sequence クラス)

・Bio::Sequence::NA クラス
・Bio::Sequence::AA クラス

ファイルを開く

今日の落書き bioruby を眺めてみた

07-9月-17

正確にはbiorubyのyard documentをながめてみた。

眺めた感じだと、Bioモジュールの中に、「手法/プログラム」を扱うクラスと、「ファイル」を扱うクラスと、「データベース」を扱うクラスみたいなのがあるっぽい。
ところがクラスのドキュメントにもOverviewやDiscriptionがないのが多くて、どのクラスが何を扱うクラスなのか、理解するのに若干の困難を感じる。

逆にいうとちょっとドキュメント追記するだけで、Pull Requestがはかどりそうである。多分そういうドキュメントが整備されていないクラスはあまり大事じゃないクラスなんだろうけれども、大事じゃないなら大事じゃないことがすぐわかるようになっててほしい。もうひとつOverviewが書かれないクラスが存在する理由は、同一ファイル内の別クラスに、ほぼ同様の記述があるからじゃないかと想像するが確かめてはいない。

ざっと眺めて感じたのは、Biorubyは処理をするための道具ではなく、ワークフローを書くことを意図しているのだろうということ。
速度を必要とする処理に関しては、C言語なんかで書かれた個別のプログラムを利用するべきなのだと思う。

逆にいうと、今後 Bioruby がどれだけ便利に使っていけるかということは、新しい手法/プログラム/ファイル形式が、どれだけ柔軟にBioモジュールに追加できるかどうか、という点にかかってくると思われる。(もちろんそのような公益な作業をしたい人よりも、単に追加されたクラスを使いたいだけの人が多いに決まっている。)

となると、なぜ2016年で開発が急にストップしているように見えるのかが気になる。

正直なにが何なのかよくわからないので今日はこのぐらい。

numo-gnuplot playground

06-8月-17

今日の落書き red-arrowで遊ぶ

05-8月-17

難しそうなので今日まで敬遠していたred-arrowを使ってみた。
公式の通りインストール。手順通りコピペでインストールしているだけなので何もわかっていないけど、そういうアホなユーザーも世の中一定数いるから仕方ないよね。Pythonの方もcondaでPyArrowをインストールした。

難しそうなので公式のexampleを試すだけ

パイソン

ルビー

おお、普通に動くじゃないか…。
/dev/shmというのが何か気になったのでインターネッツでググるとRAMディスクのことらしい(正確には違うらしい)。

ということは…なにこれすごい∑( ゚д゚ )

公式スライド

正直Webサイト製作に関するプロの道具であることを求めなければ、Rubyでデータ解析できる状況は十分に整ってきていると感じる。

機械学習に関してはscikit-learnのようなライブラリの力を借りる必要があり、pycallを呼び出して適宜red-arrowでデータを変換していくような使い方が望ましいのかもしれない。

RubyやPythonといった便利な道具があることを知らない or キャリアをまともにこなしていると学習コストを支払えない制度設計になっているために、プログラムでやった方が早いことも含めてプログラムと縁のない方法で仕事をこなさざるをえない非エンジニアの世界の方が、エンジニアの世界よりも広いのである。。

今日の落書き Rubyでアヤメ(Iris)のデータを眺める

29-7月-17

データを用意する

https://raw.githubusercontent.com/pandas-dev/pandas/master/pandas/tests/data/iris.csv

Jupyter Notebookを起動する

※ホビーでRubyを手軽に使うのにJupyter Notebookが必ずしもベストとは思わない…

ライブラリを読み込む

CSVファイルを読み込む

SepalLength SepalWidth PetalLength PetalWidth Name
0 5.1 3.5 1.4 0.2 Iris-setosa
1 4.9 3.0 1.4 0.2 Iris-setosa
2 4.7 3.2 1.3 0.2 Iris-setosa
3 4.6 3.1 1.5 0.2 Iris-setosa
4 5.0 3.6 1.4 0.2 Iris-setosa
5 5.4 3.9 1.7 0.4 Iris-setosa
6 4.6 3.4 1.4 0.3 Iris-setosa
7 5.0 3.4 1.5 0.2 Iris-setosa
8 4.4 2.9 1.4 0.2 Iris-setosa
9 4.9 3.1 1.5 0.1 Iris-setosa

アヤメの品種を確認する

Name
0 Iris-setosa
50 Iris-versicolor
100 Iris-virginica

基礎統計量を表示してみる

PetalLength PetalWidth SepalLength SepalWidth
count 150.0 150.0 150.0 150.0
mean 3.759 1.199 5.843 3.054
std 1.764 0.763 0.828 0.434
min 1.0 0.1 4.3 2.0
max 6.9 2.5 7.9 4.4

グループにしてみる

SepalLength SepalWidth PetalLength PetalWidth
Iris-setosa 5.006 3.418 1.464 0.244
Iris-versicolor 5.936 2.77 4.26 1.326
Iris-virginica 6.588 2.974 5.552 2.026

アヤメの品種ごとにデータをわける

SepalLengthのヒストグラム DataFrameから

Nyaplotを使う場合

※ Daruから NyaplotやGnuplotrb、Plotlyを通してグラフを描けるらしい. 残念ながらNyaplotの開発は止まっている…

SepalLengthのヒストグラム Statsampleから

StatsampleがDaruと統合する前に独自に持っていたグラフ機能が残っている

setosaの散布図を描く

Nyaplotを使うとき

Numo::Gnuplotを使うとき

Daru::Vector→RubyArrayへの変換が必要。

相関係数を求める

SepalLength SepalWidth PetalLength PetalWidth
SepalLength 1.0 0.747 0.264 0.279
SepalWidth 0.747 1.0 0.177 0.28
PetalLength 0.264 0.177 1.0 0.306
PetalWidth 0.279 0.28 0.306 1.0

散布図行列

現状では簡単に描く方法は存在していないとおもわれる。

単回帰分析を行う

Numo::Gnuplotで回帰直線を描く

多分Nyaplotでも描ける

重回帰分析

【Daru】Rubyでデータ分析【Statsample】

13-7月-17

Rubyのデータサイエンスに関するコミュニティはまだ小さいです。これはPythonのような、成熟して手の入る余地の少ないプロジェクトよりも遥かに将来性があり、あなたが貢献する余地がたくさん残されているということを意味します。ワクワクしませんか?
このページは素人がテキトーに書いています。まああれだ。頑張れ。

このページで使うライブラリ

Numo::NArray
数値計算
Numo::Gnuplot
グラフ作成
Statsample
統計
Daru
データフレーム

このページで使わないが重要なライブラリ

・red-arrow
・pycall
・rb-libsvm
・liblinear-ruby

便利なので使っているが好きではないライブラリ

・Jupyter-notebook(Jupyterが嫌いなのではなくて、JupyterでRubyを動かすのが何となく嫌)
・IRuby

人気はあるが本当は性能が低いと感じられるライブラリ

・NMatrix
(性能は低いが、作者の政治力と顕示欲は高い。糞味噌に書いたがScirubyへの貢献は大きく、みんな気を使っていると思われる。※個人の意見です)

ライブラリを読み込む

長いので短縮する

いわゆるやりたい放題。SFloatやDataFrameがトップスペースから呼べたらもっと楽しいが…

楽に配列を作成する

棒グラフを描く

折れ線グラフを描く

ベクトルを生成する

NArray配列を生成する

平均値(mean)

中央値(median)

分散(V:variance)

標準偏差(SD:standard deviation)

歪度・尖度

※Numo::GSLを使えば、NArrayでも求められる

範囲

ターミナル上で基礎統計量を表示する

ターミナル上にヒストグラムを表示する

ヒストグラムをSVG形式で保存する

1標本T検定

F検定

U検定

2標本T検定

箱ひげ図を描く

χ二乗検定

散布図

散布図その2

3D散布図

相関係数を求める

Spearmanの相関係数

単回帰分析

重回帰分析

主成分分析

データフレームを作成する

配列からデータフレームを作成する

行や列の情報を取得する

データフレームに行を追加する

CSVファイルからデータフレームをつくる

Microsoft Excelファイルの読み込み

ActiveRecordから読み込み

データフレームの最初と最後を表示する

データフレームの”列”にアクセスする

データフレームの”行”にアクセスする

データフレームの列名を取得する

ソートする

条件によって行を抽出する

行を削除する

列を削除する

データフレームの行⇔列を入れ替える

欠損値のある行を取り除く

グルーピング/集約

データフレームのマージ

※2017年7月時点ではindexによるjoinは開発中らしい
※mergeはpandasのconcatのaxis=1のような動きをするメソッド(vectorをマージするの意味らしい)

軸による連結

数値ベクトルのみのデータフレームを取り出す

時系列のベクトルを作る

時系列ベクトルからグラフを描く


※ GnuplotRBを使用する

データフレームをCSVに書き込む

ロジスティック回帰

statsample-glmを使用する。信頼性はいまひとつか。

【Ruby】 Numo::Gnuplot で箱ひげ図 (boxplot)

09-7月-17

忘れないうちにメモ

1.配列をさっと比較したいとき

2.ラベル付きのデータのとき

using の設定がややこしいけど、丸暗記するしかないっぽいね

なぜゲノムの分野に楽観的な気持ちになれないのか考えた

06-7月-17

漠然とした話。IT系の人達と一部の医療関係者はゲノム解析の分野に大きな期待を寄せているが、どうも個人的にはゲノムにそこまで強い希望を持てない。特に分子標的治療薬によるガンの個別化治療に対してはかなり否定的な気持ちを持っている。どうして自分がゲノム解析にそこまでポジティブな気持ちにならないのか、その理由が少しだけ自分でもわかってきたのでメモしておく。(あまりこういう分野について考えたこともないので用語は変だと思う)

まず、一般化した話から。
技術の進歩を2つに分けて考えてみる

1. 手間(工数)を増やすことによって品質を向上するもの
2. 品質は据え置き〜低下させて、手間(工数)を減少させるもの

 暗黙の了解として、昭和の日本では、実行可能な工数は増え続けるという前提があった。エネルギー革命により石油資源から電気を生み出し、電化製品が家庭でも使われるようになった。労働人口も増加し続けた。その結果1の、工数を増やして品質を向上させる技術がもてはやされるようになった。

 しかし、ついに生産年齢人口は減少し、旧来の方法を漫然と続けるだけでは品質を保つのも困難な時代になってきた。コンプライアンスの強化が叫ばれており、現場は過剰なコンプライアンスに疲弊しているといわれている。これは、本当はこのような活動をしなければ、すぐにでも品質が維持できない状況に陥りそうだということを意味する。

 したがって、今後の日本で評価されるべきなのは、2品質は据え置き〜低下させて、手間(工数)を減少させる技術であると予想される。つまり、技術の評価軸を変える必要がある。

 先進国では、これから日本のような少子高齢化が問題になると予想され、工数を減らす技術が品質を向上させる技術よりも高く評価されるのは、世界的なトレンドになっていくと考えられる。(※個人の意見です)

一般的な話おわり。ここでゲノムの話に戻る。

 ゲノム解析に展望は、個別化医療によって、分子標的薬の治療の品質を上げていくというものであった。個人や病気に最適化された分子治療薬を開発し、それを使う。それは確かに素晴らしいことだと思う。しかし、これは工数を増やしながら品質を向上させる技術である。

 しかし個別化医療をルールベースで行うと多くの思考をともない現場がもたない。これを圧縮するために、人工知能を使用する。なぜならば、人工知能の世界では、今後も計算力の増加が見込まれており、実行可能な工数=計算力は増加し続けると考えられているからである。

 ゲノムによる個別化治療とは、工数を増やすことによって品質を向上させるタイプの医療である。その追求は大変おもしろいだろうし、患者さんにも大きな効果を発揮するだろう。しかし、それはわずかな品質向上のために、莫大な計算力を費やすタイプの医療かもしれないのである。
 そしてそのような医療は、解決しなければならなない社会問題のトレンドや、社会的な要請からは本当は少しずれているかもしれないと考える。

 もちろん僕の考えが間違っている可能性もあるが、正直にそう書いておく。これが僕がゲノム医療に感じる違和感の正体で、そこまでポジティブになれない理由なのだと思う。

 ここまで書いた違和感のほかに、ゲノム研究そのものに対する不満もある。

 そもそも素人考えでは、がん遺伝子がすべて解明できたとしても癌のことが理解できるとは思わない。癌細胞を眺めている人たちは、がんは成功者であるという発想に陥りがちだ。つまり、がん細胞はいくつかの遺伝子を変えて、自ら無限に増殖できるように変身したしたずる賢い成功者だと。癌の本態は遺伝子なのだから、そのような遺伝子をみつけて叩けばいいのだと。

 しかし、私にはそのような腫瘍観は、時代遅れだと思う。癌の本態は本当に遺伝子だろうか。偉い先生は心から本当にそう思っているだろうか。それとも癌全体を理解することは難しいので諦めてしまっているのだろうか。それとも研究費が貰うためにそう言っているだろうか。

 私のなかでは癌は成功者というよりは、貧困地帯に広がるスラム街のようなイメージである。きっと多くの人はそのようなイメージを持っているのではないだろうか。華々しい成功者のイメージは癌にふさわしくない。

 それでも癌を成功者と見なしたいのなら、個別の成功者よりも、そのような成功者を生みだし、許容し、成長させるに至った背景や仕組み、条件に着目したいところだ。個々の成功者のキャラクターや特色、それは成功者を構成するパーツではあるけれども、そればかりに「成功」の原因を帰着するのは狭い考え方だと思う。

 癌を遺伝子病とみる立場は、それと同じような視野狭窄があると感じられる。遺伝子を調べる技術は手元にある。しかし癌をうみだす背景である加齢現象を理解する方法はない。だから癌を治したいという気持ちを強く持って、わかることを一生懸命に調べていると、自然と「癌は遺伝子疾患」という気持ちが過剰になりすぎてしまうのだと思う。その気持ちはわかる。気持ちはわかるのだが、賛成はしない。

 そのほかの意見も、免疫ががん細胞を排除するといった話ばかりで、世知辛い気持ちになる。若年者に癌が生じないのは本当に免疫のためばかりなのだろうか?(直感的には違うと思うけれども、何の根拠もない)

 時代のブームは、物事をみる目を曇らせるし、私達の頭の中を少し不自由にする。
 だからせめて、妄想日記の頭の中ぐらいは、役に立たないことばかり考えて自由にしていたいと思う。

医療とAIの未来について再び妄想する

04-6月-17

頭の整理をするために、また医療とAIの未来について考えている。

医療データサイエンス 1.0

これは、近い将来にきっと起きる変化だ。AIの医療応用を考える多くの人が思い描いている未来だ。
具体的には
・CTやMRI画像などが、Deep Learning技術で自動的に診断できるようになる
・医療用のデータセットを作成する患者団体や、病院、学会が現れる
・APIを用いて医療データを取得する手段が整備されはじめる
・データセンタを持つ企業が医療データを低価格で診断するサービスを始めてデータを収集・蓄積しはじめる 
・対抗して、よりオープンな医療データセットやオープンなモデルも公開される
・大病院が工学技師としてデータサイエンティストを雇いはじめる
・もしくは医者がデータサイエンスをかじりはじめる
・少しずつ人工知能が普及しはじめる
・画像診断の精度、血液検査の精度、内視鏡の精度、遺伝子の解析、心電図モニタリングetc
 すべてでコンピュータが人間を上回る
・個別化された医療が行われるようになる
・診断だけではなく、治療にロボットの活用がはじまる
・確実にどんどん成果を生まれ、治療成績も激的に向上していく
・にもかかわらず、不思議なほど医療そのものには何らの変化がない なんでだろう?
・保険点数が厳しく減額され、利益が減少したりする
・IT企業に対する患者の医療訴訟が多発するようになる。高額の賠償が請求される事例も発生する
・IT企業も、次第に状況を理解して(最初は不合理だと思っていた)製薬会社のやり方を真似するようになる
・もしくはもともと無料でサービスを提供できる体力のあるところだけが他の会社を焼き払う形で生き残る
・最初からこうなることを見越していた老舗企業もしぶとく生き残る
・患者とエンジニアの間にゆっくりと失望が広がっていく
・業界の熱気が冷めて、少しずつ落ち着いてくる
・なんかいい感じになる
といった感じだろうか。とってもワクワクしないよね。あまりにも想像するのが容易だ。
妄想にしても陳腐だ。
こういったことに無邪気に夢を感じるには、少し歳をとりすぎた気がする。

問題は、ここからだと思っている。上記の筋書きはちゃんと考えれば誰もが見通せる素直な未来だ。
未来は、だいたい思い描いた通り素直には歩いてくれない。

医療データサイエンス 2.0

上で描いた1.0は人工知能は、あまり医療の本質に触れていない。
つまり1.0は来るが、そのままの形ではこない。

僕が思いつくだけで大きな焦点は2つあると思う。
1つ目の焦点は、割と簡単だ。簡単だということは、乗り越えうるということである。
乗り越えた先は、たとえばアルファ碁のあとの囲碁界みたいな事になっていると思う。ある意味楽しい世界である。

2つ目の焦点も簡単だが、もう少し医療の本質に関わる問題である。
この問題が乗り越えられるかどうかはわからない。乗り越えるとしたら、人工知能は俺が考えているよりもやばい。
少なくとも、今の段階では人工知能がこういった問題を乗り越えることは想像できないな。多分、人工知能はこの問題を乗り越えられずに迂回すると思う。
少なくとも人間は、こういう問題を直接乗り越えるよりは迂回することを好む。

この問題について、ちょうどいいツイートがあったので引用しておく

そしてその根本にある問題や、その他の問題もおぼろげに見える気がする。

いつものことだが妄想日記にしても考えがよくまとまらない。

考えれば考えるほど、やっぱり人工知能も今までの技術革新と同じで、結局は医療は変わらないという説の方を採用したくなるね。

Rubyを使ってDICOM画像で遊んでみる

25-5月-17

RubyでDICOM画像を扱う情報がほとんどないので少しずつメモしてみる。

ruby-dicomhttps://github.com/dicom/ruby-dicom

インストール

DICOM画像を読み込む

メタデータを取り出す

画像データを取り出す

IRuby Notebook上にDICOM画像を表示する

imageメソッドで、ImageMagickオブジェクトに変換できる。
内部ではrmagickもしくはmini_magickが動いている。
rmagickは更新が滞っているので、mini_magickがおすすめ。


※画像はDSB2017に使用されたsampleの1つです

ヒストグラムを表示する


Guido ZuidhofFull Preprocessing Tutorial
の序盤をRubyに書き換えてみた。とりあえず動いてくれればOKという発想なので、例によって間違いあるかも。