Starry night

星空を見上げて

PovRayを用いて星空を撮影しました。撮影と言ってもカメラのレンズを空に向けるのではなく、星のデータを元に星空をコンピューター上で再現したものです。今回はstarmap.incを用いて簡単に画を作成しました。

starmap.inc のダウンロード用リンク先です。公開は可能だが、コピーライトを主張しないようにと言うようなことが書かれていましたので、とりあえず、リンク先のみ。

<http://news.povray.org/povray.binaries.scene-files/attachment/%3C4a02be66%40news.povray.org%3E/starmap.inc.txt>

 

いよいよ、お写真の撮影です。スクリプトは次のようになります。

#declare LimMag = 6;
#declare fDec=15;
#declare fRA=75;

#macro StarMapStar(vPosition, fMag)
#if (fMag < LimMag)
#local vPos = vrotate(vPosition, <0, -fDec, -fRA>);
#local c = ((LimMag+1)-fMag)/(LimMag+1);
sphere
{
vPos * 10000, 32
texture{pigment{colour rgb<c, c ,c>}finish{ambient 1 diffuse 0}}
}
#end
#end

#include “starmap.inc”

camera {
spherical
location <0,0,0>
look_at <0,0,1>
angle 270
}

Sample size calculation for a classical case-control study

ケースコントロールスタディのサンプルサイズの見積もり

臨床試験だと、試験に参加する被験者をリクルートするのは骨が折れる仕事ですので、必要最低限の被験者で正確な結果を得たいという欲求は大きく、「サンプルサイズ」の正確な見積もりが求められます。ケースコントロールスタディをする場合も、最終的に元資料を確認したり、新たにデータを入手したりする手間は少ない方が良いので、精密な見積もりが出来た方がベターです。しかし、新たにデータを得ることを想定していないデータベース研究では、サンプルサイズを見積もる要求はどのあたりに発生するでしょうか?データベースをベンダーから購入したり、解析をCROに依頼する際に目的の結果にアプローチできるだけの情報を持っているかどうかを見積もる場合には有用かもしれません。まぁ、流行だということで偉い人からの号令で動いているような多くの人は、何らかの結論にアプローチしたいのではなく「アプローチしている姿勢を見せる」と言う、行動計画ありきで動いているみたいですので、当該ベンダーのデータには、リサーチで明らかにしたい結論に到達できるような、十分なデータが含まれないことが購入前あるいは解析の発注前に明らかになったとして、頭を切り替えるかそのまま突き進むかは目に見えていますが。

それはさておき、単純にケースおよびコントロールでそれぞれ、何人中何人が被疑薬に曝露されていて、そのオッズ比を求めるというようなデザインでのサンプルサイズの求め方がありますので、次の資料のデータをトレースしてみます。

Woodward M (2005). Epidemiology Study Design and Data Analysis. Chapman & Hall/CRC, New York, pp. 381 – 426.

(p. 412) A case-control study of the relationship between smoking and CHD is planned. A sample of men with newly diagnosed CHD will be compared for smoking status with a sample of controls. Assuming an equal number of cases and controls, how many study subject are required to detect an odds ratio of 2.0 with 0.90 power using a two-sided 0.05 test? Previous surveys have shown that around 0.30 of males without CHD are smoker.

事前の見積もりに必要なのは、odds ratio 2.0, power 0.90, two-sided 0.05 testという、研究者が設定するパラメータと、先行研究から得ておくべき背景の情報として「冠動脈疾患にかかっていない男性の30%がスモーカーだ」という、コントロール群の曝露頻度に相当する情報です。あと、コントロールを選ぶ際はマッチングは行わないで、ケースと1:1となる人数にするとしています。ここで設定しているオッズ比は、「オッズ比2.0以上だとリスクとして警告する価値がある」と研究者が思い込むような任意の数字で、基準があるわけではないです。これを、認識しているかどうかで、結果が出た際に(特に差がつかなかった時に)データの解釈の書き方が大きく変わります。

> epi.ccsize(OR = 2.0, p0 = 0.30, n = NA, power = 0.90, r = 1, rho = 0,
+ design = 1, sided.test = 2, conf.level = 0.95, method = “unmatched”,
+ fleiss = FALSE)
$n.total
[1] 376

$n.case
[1] 188

$n.control
[1] 188

答えは
A total of 376 men need to be sampled: 188 cases and 188 controlsだそうですので、一応、数値は正解です。

「冠動脈疾患にかかっていない男性の30%がスモーカーだ」という先行研究も、よくよく考えると書かれていることがあいまいです。冠動脈疾患にかかっていない男性が将来かからないとは言えないですし。禁煙に成功した人をどう扱っているのか情報もないです。ま、それもさておき、背景の喫煙男性が30%も世の中にいたおかげで、少ないサンプルで研究が成立しそうです。これが、世の中の男子の1%しか使用していない曝露(これが医薬品への曝露なら、世の中の1%の男性が使用しているような薬ならブロックバスターですが)曝露との関係を見ようとすると、次のようになります。

> epi.ccsize(OR = 2.0, p0 = 0.01, n = NA, power = 0.90, r = 1, rho = 0,
+ design = 1, sided.test = 2, conf.level = 0.95, method = “unmatched”,
+ fleiss = FALSE)
$n.total
[1] 6418

$n.case
[1] 3209

$n.control
[1] 3209

6418例の情報を収集する必要が出てきます。このくらいの数になると、どのようにデータを集めるにしても自前でデータを準備して集計するのは大変そうです。組織だって行動する必要がありそうです。さらに、背景の曝露を0.1%に下げると、次のように6万人超えのサンプルの収集が必要になります。

> epi.ccsize(OR = 2.0, p0 = 0.001, n = NA, power = 0.90, r = 1, rho = 0,
+ design = 1, sided.test = 2, conf.level = 0.95, method = “unmatched”,
+ fleiss = FALSE)
$n.total
[1] 63158

$n.case
[1] 31579

$n.control
[1] 31579

副作用を研究対象にしていると、このcaseの3万人超えの副作用が出ていないと、結論が出せないように見えます。つまり、副作用の例にあてはめますと、3万人以上の患者さんが副作用になるという、結構な大惨事になってからしかこの方法で結論が出せないという、悲惨な手法です。どこに間違いがあるのでしょうか。おそらくそれは、有名なレンツの研究では結果として上記の例よりかなり大きな数字になっているパラメータでしょう。「オッズ比が20~50になるくらいの本当の強いリスクかどうか」を検証したいという、リサーチクエスチョンを立てるのです。

もう一点できる事やるべき事は、背景での曝露頻度を上げるために、対照集団を絞り込むこともできそうです。結論部分で述べたい一般論との兼ね合いにもなりますが、多くの場合世の中一般の集団からサンプルを得る必要はなく、気になる医薬品が使用されるような特定の基礎疾患にかかっている人の中での曝露でp0を設定すれば、調査対象数を少なく見積もることもできそうです。

Don’t forget to load a library prior to the above-mentioned scrips.

library(epiR)

Gali proof of a specialty journal

今月は2件のガリプルーフのチェックを行いました。ないときは何か月もないのですが、集中する時は近いタイミングで発生します。2件のうち1件は非常に短い(語数が少ない)ので、確認は楽勝でしたが、もう1件は、自分自身が非専門領域の専門誌で、全体で3000語弱の英文のフルペーパーでしたので神経を使います。このジャーナルはaccept前のレビューも若干長めで時間がかかっていましたし、レビューワーのコメントもデータの解釈の方向や議論の主張の仕方など細かい指示が多かったように思います。一方、多くのジャーナルで指摘される「英語が読みにくい」「専門の英文校閲会社を利用しなさい」といった指摘はありませんでした。私が急に英作文が上手くなったはずはなく、その専門領域の先生方の特性を反映しているものではないかと思います。

今回イラついたのは、出版社が組版に際して手を加えてきたことでした。a や theを入れ替えたり、文法が間違ったりしているのを修正すると言うのは他の出版社でもあります。しかし、今回は1つのテーブルを2つに分割して、新たにテーブル番号を振ってきました。テーブルは本文で参照する際に紐付しているのですが、紐付が間違っていて、本文中で参照するテーブル番号が当初意図していたのとは別のテーブルを指しています。これを修正するのは神経を使います。そして、出来上がってみたら、参照する順に番号が1, 2, 5, 3, 4になって、途中で参照するTable 5が最後のページに来るといった仕上がりになります。間違って紐付するよりはましだけど、なんか不愉快な感じです。

安楽死

安楽死について

2018年6月はじめに、京都大学で開催されました米国内科学会日本支部年次総会の役員会で、黒川清先生が安楽死について語っておられました。これだけ高齢化が進むことが何十年も前から予測されながら各時代の政権が実質的な手を打たずに、不作為を続けてきてしまった、というご認識でいらっしゃるようで、声を上げておられるという事でした。安楽死と高齢化? これを結びつけたロジックが解りませんでしたが、年をとったら(健康であっても?)自分で死を選ぶオプションを想定しているのであれば、SFの世界の様な話です。何か見解があれば、ご自身のブログにコメントを寄せてほしい、と言う事でしたのでそのブログを見に行きました。

黒川先生のブログ

まず、ブログを見て圧倒されたのが文字数の多さです。一通りザーッと流し読みするにも小一時間。そして、このテーマを「医学生のお勉強」として取り上げておられることもびっくりしました。安楽死にまつわる周辺の様々なことについて議論されています。雑談の様に雑多な話題から周辺の情報もちゃんぽんの様に入っている。議論として積みあがるというよりは、周辺ばかり。そう、話題の「安楽死とは」どういうものを言うのか、定義していない。何について議論しているのか、共通の認識を確認しないまま進んでいるのでなにか落ち着かないのです。

なぜ定義にこだわるのでしょうか。それなしでは、何を議論してどこに落ち着こうとするのかが見えないからです。いろいろな定義があってしかるべきですが、少なくとも「自分たちが、今議論しているものはこういうものだ」というのを確認する必要はあります。

自分が死にたいと思って死を選ぶ、「安楽死」-「尊厳死」-「自殺」 何が違ってどこに境界線があるか、整理できてますか? 国内では「安楽死」は過去に裁判を通して司法が4要件(6要件)を示して整理してくれています。4要件を少し緩めた物が「尊厳死」ですが、海外では日本の「安楽死」の要件を緩めて「安楽死」の様に扱っている様でもあります。「尊厳死」と「自殺」は、一般の人が思い浮かべるようなイメージでは明確に分かれていると思いますが、性質としては非常に近くて線引きは難しいものです。そこに至る社会的な背景が違うだけのようにも思います。安楽死を選ぶ権利を許容するが、自殺は許容しない、といった具合に真逆な判断をするためには、その2者の間に明確な線を引くことが必要になります。

とりあえず、東海大学安楽死事件の判決文を張っておきます。4要件が書かれています。(つづく

魚雷観音

魚雷観音

2018年6月はじめに学会で京都に行きました。今回は学会前日の理事会から始まって、最終日最後のプログラムのビジネスミーティングまでいたので週末ずっと京都にいました。理事会は金曜日午後ということで、出席するために会社の方は有休を取りました。そして、少し早めに行って観光をしました。場所は嵐山付近を散策しました。立派なお寺を一つ観て、「これはかつて我が家の定番カレンダーだった、シオノギ卓上カレンダーか国鉄壁掛けで絶対に観たことがある」と思える景色を観てきました。その、普通の感じのやつはいいとして、そのカレンダー寺の付近で気になるオブジェを見つけました。

まず、このネーミングにひっかかりました。「魚雷観音」平和なイメージの観音様と戦争なイメージの魚雷、このミスマッチな組み合わせが、他のオブジェとは何か惹きつけるものを持っていました。

この魚雷は、インプットしたスクリュー音を追尾する仕組みでもなく、あらかじめプログラムされた航路を進む仕組みでもなく、人がマイクロプロセッサ代わりに搭載されていたそうです。

作戦に関わった多くの方が亡くなっていますので、その方々を慰める観音様ということだろうと思います。

 

 

 

 

 

 

 

Statistical Code for Clinical Research Papers in a High-Impact Specialist Medical Journal

インパクトの大きな医学研究で使用した統計ソフトのコードを公開するべきだという論評

Assel M, Vickers AJ. Statistical Code for Clinical Research Papers in a High-Impact Specialist Medical Journal. Ann Intern Med. 2018;168:832–833. doi: 10.7326/M17-2863

<原文は自前のデータを提示してはいますが、ほぼ、思うところを述べている論評です>


1.      定量的医学研究・分析の中核となるはずのコーディングを教える教育プログラムが少ない、としているが、あるのか日本には? (医者でちょっと深くやろうとすると、システムエンジニアや数理統計学者の真似みたいなことに向かおうとするような人もいる。自分のサイロに閉じこもって医学研究と言う当初の目的から離れていったりしていないかい?)

First, software practices and principles should become a core part of biostatistics curricula, regardless of the degree (under- or postgraduate) or subject (biostatistics, public health, or epidemiology). Given that students will have to write code when they perform analyses as practicing investigators, we question why so few degree programs in quantitative medical science teach good coding practice.


2.      教室内で、統計解析のコードをピアレビューすべきだというが、教室内にいるのかな自分以外でコードがわかる人が? 仮にいたとして、他人の書いたプログラムを読むのはかなり厳しい。それより、ダブルプログラミングして答え合わせする方が現実的。

Second, statistical code should undergo intramural peer review. Colleagues should routinely share code to receive constructive criticism just as they share drafts of scientific papers.


3.      自分自身が「エレガント」だと思うような綺麗なコードは、おそらく他人から見て意味不明で、何でこれで正しい答えが出るのが不思議なやつになっている(と思う)。若干冗長でも、何をやっているのか解りやすいほうが後日のデバックや学習用には向いている。

Finally, code associated with published research should be archived. Doing so would not only improve transparency and reproducibility but also help to ensure that investigators write better-quality code…. We believe well-written code has more than cosmetic value and that dirty code may lead to scientific errors.


We urge the medical research community to take immediate remedial action」:自分では他の人ができないようなことができるから、他人より一歩前に出ているという認識があって、皆ができるようになると「なぁーんだ」てな感じで埋もれてしまいそうだから、実は現状がちょうど良いというような気もしなくない。

# ちなみに、この論評で推進を論じているcode share、「格安航空会社のホームページでチケットを予約したのに、空港で待っていたのは国内大手の機材だった」感じです。

 

 

 

TRUMPET ENSEMBLE SEED

SEED – trumpet ensemble

2018/4/27(FRI) @ Casa Classica

ぱんだウインドオーケストラのトランペットパートメンバーによるアンサンブルSEEDのライブに行ってきました。出演されたのは、笠原日向さん・片野和泉さん・佐藤玲伊奈さん・重井吉彦さん・中村諒さんの5名。会場には若い方が多かった中、舞台目の前に陣取ったテーブルに私と、メンバーの片野さんのお母さんが世代が上で保護者席の様な感じになっていました。そこまで広くない会場で、トランペット5本が目の前で鳴ると音圧がすごい迫力でした。中村さんの相変わらずの安定した音は聴いていて安心できます。笠原さん、通常は耳に突き刺さるようなハイノートを楽しませてくださいますが、この日は「3万円ほどでヤフオクで落札した」というバストランペットにトロンボーンのマウスピースを付けてアンサンブルに入っておられました。みなさんおしゃべりは苦手な様ですが、前半おしゃべりが少なくどんどん進んでいくと少しバテから回復する時間がないのでは、という感じでした。チラシは重井さんがスマホアプリで作成されたものだそうです。

https://drive.google.com/file/d/0B23Rvhh_yGe1SkRMeUtUV2U5a19MdURVSmcyTTIxdnpaXzdz/view?usp=sharing

全体を録画したつもりなのですが、うまく取れていたのは最後の曲だけでした。(失礼)

なお、この楽曲はJASRAC DB上はPublic Domainなのですが、youtubeに掲載しましたところ「Hexacorp (music publishing)」というところが何らかの権利を有していると主張してメールを送ってきました。動画の掲載は継続していてよいが、広告が現れる場合がある(広告収入がHexacorpに入るものと思われます)と言う連絡を受けました。継続して掲載可能という事ですので特に異議を主張していません。将来条件が変わり削除を求められるようなことになりましたら、削除するかもしれませんのであしからず。

in-store-live of Sabão (ex Hysteric Blue)

Sabão (ex Hysteric Blue) インストアライブ

実は、このSabaoというグループ、寡聞にして2018年現在活動を続けておられることすら認識していなかったのですが、今回のライブの数日前にたまたま検索する気になって、このインストアライブを知ることになりました。目的は1999年紅白歌合戦でも披露した「春~spring~」 です。その紅白を見た当時、我が家は私の米国留学中で、数少ない日本からの放送(当時)で聴いた曲です。当時、米国から見て太平洋の向こう側のNHKホールのステージで歌っておられて、文字通り手の届かないような場所にいらっしゃったお二人が、本当に手の届きそうな目の前で曲を演奏しているのを見て感動です。そして、約20年と言う長い年月が経ってますます歌声に磨きがかかっていたのも素敵でした。特にファンという訳でもなかったので、大ヒットしたspring以外の他の曲はよく知らないわけですが、今回のライブで少し聴いてみようかなと言う気になりました。

リハーサル風景の動画

ライブ中からサイン会終了までは撮影・録音・録画禁止という事でアナウンスされていました。このページに貼ってある画像や動画は、リハーサルの音出しのと時にほんの少しだけ、録画・撮影しました。じつは音出しの時にはちゃんとバランスよく音が出来上がっていたのに、本番が始まるとボーカルの音がほとんど聞こえません。にもかかわらず、vocalのtamaさんはミキサーに向かって、音量を下げるようにと言う合図を何回も出します。別のスタッフは客席の後ろからミキサーのところまで駆け寄ってきて何か指示しています。2曲目まで終わったところで、解ったのですが、内音はvocalの声量が大きくてバランスが悪かったという事です。で、外音にはvocalが出ていなかったこともステージに伝わりました。結局DJのマイクをvocalが使用することで、残りの2曲は無事バランスよく楽しむことができました。4曲目が目的の「春~Spring~」でした。

 

 

PlayPlay

R のアンインストール MacOS

MacOS での統計ソフトRのアンインストール

MacにインストールしたRが古くなり、パッケージが動かない状況も見受けられるので一旦アンインストールして、その上で最新版をインストールしようと思いました。でも、RってApplestoreからインストールしたアプリでないのと、アンインストーラが付属していないので、どうやって削除するのか。まずは下調べです。

<https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Uninstalling-under-macOS>

4.2 Uninstalling under macOS

R for macOS consists of two parts: the GUI (R.APP) and the R framework. The un-installation is as simple as removing those folders (e.g. by dragging them onto the Trash). The typical installation will install the GUI into the /Applications/R.app folder and the R framework into the /Library/Frameworks/R.framework folder. The links to R and Rscript in /usr/local/bin should also be removed.

If you want to get rid of R more completely using a Terminal, simply run:

sudo rm -rf /Library/Frameworks/R.framework /Applications/R.app \
/usr/local/bin/R /usr/local/bin/Rscript

The installation consists of up to four Apple packages:18 org.r-project.R.el-capitan.fw.pkg, org.r-project.R.el-capitan.GUI.pkg, org.r-project.x86_64.tcltk.x11 and org.r-project.x86_64.texinfo. You can use pkgutil –forget if you want the Apple Installer to forget about the package without deleting its files (useful for the R framework when installing multiple R versions in parallel), or after you have deleted the files.

Uninstalling the Tcl/Tk or Texinfo components (which are installed under /usr/local) is not as simple. You can list the files they installed in a Terminal by

pkgutil –files org.r-project.x86_64.tcltk.x11
pkgutil –files org.r-project.x86_64.texinfo

These are paths relative to /, the root of the file system.

上記を自動翻訳するとこんな感じです。

4.2 macOSでのアンインストール

R for macOSは、GUI(R.APP)とRフレームワークの2つの部分で構成されています。アンインストールは、それらのフォルダを削除するだけで簡単です(例えば、ゴミ箱にドラッグするなど)。標準的なインストールでは、GUIは/Applications/R.appフォルダに、Rフレームワークは/Library/Frameworks/R.frameworkフォルダにインストールされます。 / usr / local / binにあるRおよびRscriptへのリンクも削除する必要があります。
ターミナルを使用してRをより完全に削除したい場合は、次のコマンドを実行します。
sudo rm -rf /Library/Frameworks/R.framework /Applications/R.app \
/usr/local/bin/R /usr/local/bin/Rscript
インストールは、最大4つのAppleパッケージで構成されています:18 org.r-project.R.el-capitan.fw.pkg、org.r-project.R.el-capitan.GUI.pkg、org.r-project.x86_64 .tcltk.x11とorg.r-project.x86_64.texinfo。 ファイルを削除せずにパッケージをAppleインストーラに忘れさせるには(複数のRバージョンを並列にインストールするときにRフレームワークに役立つ)pkgutil –forgetを使用することができます。Tcl / TkやTexinfoコンポーネント(/ usr / localにインストールされている)をアンインストールするのは簡単ではありません。ターミナルにインストールしたファイルを

pkgutil –files org.r-project.x86_64.tcltk.x11
pkgutil –files org.r-project.x86_64.texinfo

これらは、/に関連するパスで、ファイルシステムのルートです

ん? 次のコマンドだけでTcl/Tk以外を完全に削除できるということかな?もしそうなら、これのコピペでいいじゃん。
> sudo rm -rf /Library/Frameworks/R.framework /Applications/R.app \
/usr/local/bin/R /usr/local/bin/Rscript
この rm -rf のコマンドはそのディレクトリ以下のファイルが警告・確認なしに削除されるため、必要なファイルが削除される危険があります。どうぞ、使用される際にはご注意ください。
なお、次のコマンドをLinux上で実行した際のスクリーンを記録した動画が公開されています。視聴者の反応からも、そのコマンドの危険さが感じられると思います。
rm -rf /
Translate »