さまざまな元素の同位体がどのように崩壊するかを調べてみた
サイエンス系のネタは本当は大好きなのですけどブログではほとんど書いてませんでした。
さて、ちょいと理由があって、どんな元素がどのように崩壊するかの資料を探してみたくなりました。
そもそも元素というの原子核に陽子と中性子があるわけですが、中性子の数によって安定性が違う、というのは高校生の理科でも学ぶ範囲ですよね。安定性が悪い原子核はその安定度に応じて一定の確率で壊れていくわけです。壊れる時にはα粒子（ヘリウム4の原子核）やβ線（電子や陽電子）などを放出するということです。
そして安定的なものを安定同位体、不安定なものは放射性同位体と言われます。
さて、放射性同位体がどのように崩壊するか、という一覧の情報は Wikipedia には見当たらないのですが、いろいろ探してみると実はIAEAのサイトにこんな図表がありました。
Livechart - Table of Nuclides - Nuclear structure and decay data
この図表は縦向きが原子番号順、横向きには中性子数の違いによる同位体が配置されています。スクリーンショットはウラン235を選択した状態です。そしてその元素で起こりやすい崩壊の種類によって色分けされています。これをみると安定同位体より質量が重い場合はβ-崩壊になり、質量が軽い場合はβ+崩壊またはα崩壊が起こりやすいように見えます。
こういう可視化が見たかったので、私のニーズにはこれがピッタリ合っていました。
C++Builderの浮動小数点のバイト数と精度を調べてみる
自分用の覚書。
浮動小数点の有効桁数が気になったので調べて表にしてみた。
Subject は C++Builder と書いているけど、Delphi も基本的に同じ。
なお、比較のために Linux gcc の内容も記入している。
結果はこちらの表の通り。
有効桁数は log10(2^2進数桁数) で算出した。
| 型 | バイト数 | ビット数 | 指数 | 仮数 | 2進数桁数 | 10進数有効桁数 |
| float | 4 | 32 | 8 | 23 | 24 | 7 |
| double | 8 | 64 | 11 | 52 | 53 | 15 |
| long double (Windows 64bit, iOS 32bit, 64bit) | 8 | 64 | 11 | 52 | 53 | 15 |
| long double (Windows 32bit) | 10 | 80 | 15 | 64 | 64 | 19 |
| long double (Linux 32bit gcc) | 12 | 80 | 15 | 64 | 64 | 19 |
| long double (Linux 64bit gcc, macOS) | 16 | 128 | 15 | 113 | 113 | 34 |
long double について、Windows 32bit だけは拡張倍精度であり、その他は基本的に倍精度です。ただし macOS だけは4倍精度です。
このように、プラットフォームごとに long double のデータサイズが大きく異なることに注意が必要です、。
Win32 の long double のバイト数が大きいのは浮動小数点処理に FPU を使うことにあるようです。
これに対して Win64 は SSE を使っていることで FPU 利用時よりもバイト数が小さくなっているそうです。
http://docwiki.embarcadero.com/RADStudio/Berlin/ja/浮動小数点演算について
Linux の long double が32bitで 12バイトなのは……イマイチよくわからないけど、sizeof(long doble)すると12が返ってくるので、12というのはおそらく事実。ただし指数、仮数に関する一次ソースが見当たらなかったので、この情報は Win32 と Linux64bit の比較から推測しています。 いろいろ調べてみると、データサイズとしては12バイトだけど実際には10バイトしか使っていないらしい。10バイトで処理すると遅くなるからでは、と推測している方がいらっしゃる。
浮動小数点演算ではまった話 - bkブログ
melancholic afternoon
自分が描くコードではこの違いが影響するほどの精度で数値を扱うことをしないので平気だけど、状況によっては問題が出ることもあるだろうから、実数を扱うコードを書くときは気をつけたい点かも。
RaspberryPi3用に買った3枚のmicroSDHCカードをベンチマークしてみる
microSDHCって公称スペックが同じなら、どれ買っても同じなのでは？
ええ、私もそう思っていましたよ。でも、どうもけっこう違うっぽい。今回は新規に3種類のmicroSDHCカードを調達する必要が出てきたので、3つとも違うカードを入手して速度を測ってみることにします。
使用した SDリーダ
今回は SDリーダも新調する必要があったので、USB3.0対応のこちらのリーダを買ってみました。
速度を測ってみる
速度は2種類の方法で測ってみます。一つは macOS 向けの Blackmagic Disk Speed Test で測る方法。もう一つは Raspbian Jessie のイメージの書き込み速度を測る方法。
Blackmagic Disk Speed Test の結果
| item | write | read |
| TOSHIBA MU-F016GX | 12.6MB/s | 43.6MB/s |
| Lexar LSDMI16GBJPR300A | 10.1MB/s | 80.6MB/s |
| Transcend TS16GUSDU1PE | 13.0MB/s | 85.9MB/s |
Transcend LSDMI16GBJPR300A が読み書き共に最もよい。Lexar LSDMI16GBJPR300A は書き込み速度が少し劣る。読みは速い。TOSHIBA MU-F016GX は書き込みは良いけど読み込みが他の半分くらいしか出ない。
Raspbian Jessie の書き込み
Raspbian Jessie の書き込み速度は macOS 上で以下のように実行して計測しました。pv は Homebrew からのインストールです。pv を通過するデータの流れる速度や処理時間を表示してくれるのでとても便利なのです。
pv 2016-11-25-raspbian-jessie.img | sudo dd of=/dev/rdisk2 bs=1m 4.07GiB 0:07:12 [9.64MiB/s] [========================================>] 100%
※実際の書き込みでは上記処理を内包した write_img2sd.sh で行っています。
そして結果はこちら。さきほどのベンチマークと概ね同じ結果が出ました。
| item | time | write |
| TOSHIBA MU-F016GX | 05:15 | 13.2MiB/s |
| Lexar LSDMI16GBJPR300A | 07:12 | 9.64MiB/s |
| Transcend TS16GUSDU1PE | 05:17 | 13.1MiB/s |
単に処理速度だけをみると、Transcend の速度が良さげですねえ。
なお、これらの3枚はいずれも Raspbian が起動できることは確認しました。
Macbook Pro 2016 13inch を普通の 5V 2A なUSB充電器で充電してみた⇨不使用時ならOK。使用時は無理。
ノートPCの電源アダプタは3つ欲しいと思いませんか？
少なくとも自分にとっては3つがベストです。職場用、持ち運び用、自宅用。
外出先での一時的は持ち運び用を使うけど、会社や自宅で毎度毎度カバンから電源アダプタを出し入れするのは時間の浪費のような気がします。
だから、製品附属のものに加えて、あと2つ欲しい。
さて、Macbook Pro 2016 は USB-C で充電するわけですが、この充電仕様は USB-PD (USB Power Delivery) を採用しています。
今までのMagSafeは独自仕様だったから電源アダプタも高価だったけど、今後は標準仕様なのですからサードパーティ製品の利用もアリですよね。
また、USB充電器はすでに持っているケースが多いと思いますが、それらがMacbook Proの充電に使えるかどうかも気になります。
そこで、手持ちのUSB充電器が使えるかどうかを試してみました。
サードパーティ製品を使う場合に気をつけたいこと
ノートパソコンの充電に100均などのチープな製品を使うのは全くオススメしません。
最低限、充電器には十分なコストをかけるべきと考えます。そしてケーブルも品質が担保されているものを選ぶべきと考えます。
電源トラブルはGalaxy Note7のように、最悪の場合は燃えますから、これは本当にやばい。
USB-PD の仕様について調べてみる
さて、USB-PD の供給電力に関する仕様を調べてみると、http://www.usb.org/developers/docs で配布されている「Universal Serial Bus Revision 3.1 Specification (.zip file format, size 68.8 MB)」の中にある "USB_PD_R2_0 V1.2 -20160325 - ECN clean markup 20160802.pdf" の p.492 に "10.2.2 NormativeVoltagesandCurrents" という項目がありました。
ここに掲載されていた表を rewrite したのが以下の表です。
| 電力(W) | 5V | 9V | 15V | 20V |
| 0.5 < x ≦ 15 | x ÷ 5 | - | - | - |
| 15 < x ≦ 27 | 3A | x ÷ 9 | - | - |
| 27 < x ≦ 45 | 3A | 3A | x ÷ 15 | - |
| 45 < x ≦ 60 | 3A | 3A | 3A | x ÷ 20 |
| 60 < x ≦ 100 | 3A | 3A | 3A | x ÷ 20 |
USB-PD の仕様と Macbook の電源アダプタを比較してみる
さて、Macbook の電源アダプタの仕様を調べた上で、上記の表と比べてみましょう。
| 機種 | ワット数 |
| 15inch Macbook Pro 2016 | 87W |
| 13inch Macbook Pro 2016 | 61W |
| 12inch Macbook | 29W |
うーん、ということは、Macbook Pro に使うなら、45W 以上の出力に対応した製品を使うのがよさげですね。Apple の仕様に合わせるなら 60W のものを調達できれば、13inch/15inch の両方ともいけそうな感じ。
ただしこれはあくまで使用しながら、の話。不使用時ならここまでの電力供給は当然不要なはずです。
実際にUSB充電器で給電してみる。
そこで普通のUSB充電器で充電可能かどうかを試してみました。使用した一式はこれです。
充電器は以前から使っていたもの。USB-Cケーブルは今回新たに購入したものです。電圧電流計も以前から使っているもの。
この組み合わせで試してみると、電圧 = 5.1V、電流 = 2.4A での給電が行われていました。つまり、約12Wですね。Apple の電源アダプタの 1/5 しかありません。
実際にやってみると、不使用時なら30分で10%くらい程度で充電できる感じです。緊急用としては許容可能な範囲。出張のお供にもっていって、寝てる間に充電するならアリかも。しかし使用時は当然ながらまったく充電できず、わずかながらバッテリーが減る始末です。
というわけで、非常用としてはアリだけど、使用しながら使うのは厳しいです。
ではUSB-PDでMacbook Proに給電可能なUSB充電器の妥当な選択肢は？
2016年12月時点で言えば、Macbook Pro に給電可能なUSB充電器で持ち運びに適したものは、Apple 純正品しかないと思います。
純正品以外のUSB充電器（AC側が電源ケーブルではないもの）で 60W 給電に対応したものを、いまのところ見つけきれていません。
60W 給電に対応しているのは、現時点ではおそらくはこういうドッキングステーションだけです。自宅で据え置きで使うなら悪くない選択でしょうけれど、ちょいとお高い。
これは45W給電なので、少々力不足ではあるけれど、Macbook Pro への給電はイケるかもしれません。ただしデザインはイマイチですけど。
あとは 12inch MacBook での利用を想定した製品ばかりが目につきます。13inch/15inch Pro のユーザには向かないかも。
というわけで、現時点でMacbook Pro 13inchのユーザが取りうる選択肢は以下の3つと思います。
- Apple純正品のPro13inch向け61Wを買う。
- とりあえず 2A 5V の普通のUSB充電器を使い、今後増えるであろうUSB-PD 60W 対応USB充電器を待つ。
- 力不足なのはわかっているけど 12inch Macbook 向けを想定したUSB-PD充電器を買う。
なお、USB-PD 充電器を買う時は、ケーブルの組み合わせにも注意が必要です。ケーブル側のスペックが低いと十分な電流量が流れないので残念なことになります。
Pebbleが終わった今、代わりになるスマートウォッチはあるんだろうか。
Fitbit による買収について、オフィシャルな案内が出てしまった。
blog.getpebble.com
日本語のニュース記事も engadget に出ている。
japanese.engadget.com
自分がスマートウォッチに求める要件は、ただ一つ、バッテリーが数日持つこと。
Pebble 以外でこの要件を満たせるのってあったっけ？
Apple Watch はイマイチ食指が動かないし、Android Wear も同様。
汎用的な作業用のベースとなるWindows環境を仮想マシンで作る時の作成メモ
仮想マシンをセットアップするときは、汎用的に使える状態の環境を作りこんだうえでスナップショットをとっておくと、とても便利ですよね。いろんな検証環境を作りたいときに、そのスナップショットから分岐して環境を作れば作業の手間が省けます。
だけど、必要な構成を漏れなく盛り込むのは意外に大変なので、自分にとって予め行っておきたい環境構築作業を並べてみました。
VMの設定ファイルでの調整が必要な項目を設定しておく
Host側のリソースが潤沢な場合はガンガン使って欲しいので、そのためのチューニングを施しておく。
ホスト側にGoogleドライブの同期アプリを入れておく
これを行なっておくと、別の物理PCとの間でのファイルやり取りが楽になるわけですが、そのこと自体はGuest側の作業効率にはあまり関係がない。しかし、次の項目と組み合わせると、とても使い勝手が良くなる。
VMwareの共有フォルダ機能で、ホスト側のGoogleドライブフォルダを共有しておく
これをしておくと、他の物理PCで作成編集したファイルをGoogleドライブ経由でVMware Guest側と共有したり、あるいはVMware Guest側で編集したものを別機材で使う、という作業がシームレスに行える。
また、この方法でGuest OSからHost OSのGoogleドライブフォルダをマウントする分には実体は１つだけだからストレージの過剰消費も起こらない。
個別のGuest OSでGoogleドライブクライアントを動かすと「GuestOSの個数 x Googleドライブのusage」のストレージが消費されるので辛いのだけど、そういうこともないので、これは本当にオススメと思う。
Googleドライブ内には、各環境で使用する Portable なツールを入れておく
汎用的に使いたいツールの Portable Version を入れておくと個々の環境で個別インストールしなくて済むので作業が捗る。
例えばこういう類のもの。
リモートデスクトップ接続は有効化しておく
リモートデスクトップを有効にしておくと、その仮想PCを他の物理PCから操作しやすくなるので、これは案外大事。Windows HomeはRDPがないけど、その場合は仮想PCのVNCを有効にするのでも良い。
.NET Framework 3.5 はインストールしておく
これを要求するソフトがあるから、あらかじめ入れておく。同様の理由により、VCのランタイムも入れておくと良い場合もある。
標準的に使いたいツールを入れておく
- Google Chrome といくつかの拡張機能
- Wireshark
- netcat
- telnetクライアント(Windows標準のやつ)
ncがあるならtelnetクライアントは不要のような気もしますが、手が覚えてしまっているので、これは自分にとっては案外外せない。
追加フォントをいれる
Ricky とか noto hans san とかの類をいれておきます。
OS インストール時点での最新のパッチを当てておく
これはコメント不要。
ここまでを作り込んでおけば、自分の場合は概ね不都合なく使えます。
Ubuntu on Windows の環境を再インストールする。
Ubuntu on Windows の環境を間違って壊してしまったので WSL (Windows Subsystem for Linux) の再インストールを試みたけど、それだけではうまく行かなかったので、手順をメモしておく。
- Windows Subsystem for Linux (Bata) をアンインストールする。
- OSを再起動する。
- Windows Subsystem for Linux (Bata) をインストールする。
- OSを再起動する。
- PowerShell から lxrun /uninstall /full を実行して既存のファイルを削除する。
- %USERPROFILE%\AppData\Local\lxss も削除して完全消去する。
- PowerShell から lxrun /install を実行して必要なファイルの再配置を実施する。
この手順は以下２つの記事を参考にしています。
