なにかキャンペーンをやっているというので

はてなブログ1周年おめでとう! id:hatenablog

http://staff.hatenablog.com/entry/1st-anniversary

はてブがMarkdown記法に対応したらしい

はてなブログMarkdown記法に対応したらしいですよ。

基本機能確認

見出し

# シャープで始まる行は見出し
## 増やすと階層化

見出し1
======

見出し2
------

でもおk

リストを作ってみる

* アスタリスク
- ハイフン
+ プラス

を行の先頭に書くとリストが作れる。
  • アスタリスク
  • ハイフン
  • プラス

を行の先頭に書くとリストが作れる。

1. 2. って書くと番号付き

1. 番号
2. 付き
  1. 番号
  2. 付き

HTMLを書いてみる

HTMLタグを直接書いてテーブルを作ってみるテスト

ほげほげ ほむほむ

jQuery使ってみた。

<input type="button" value="テスト" id="alerttest">
<script>
$("#alerttest").click(function () {
    window.alert("Hello World!!!");
});
</script>

引用してみる

> 引用ですよ

引用ですよ

コード

`で囲むと文章の一部にコードが書ける。

  • printf ←囲んだ
  • printf ←囲んでない

固定幅になってますね。

リンク

This is [an example](http://example.com/ "Title") inline link.

[This link](http://example.net/) has no title attribute.

This is an example inline link.

This link has no title attribute.

GitHub Flavored Markdown

GitHub Flavored Markdownにも 一部 対応しているらしい。

シンタックスハイライト

シンタックスハイライト試してみた。 とっても、残念な結果になった。

```c

include <stdio.h>

int main(void) { printf("Hello World!!\n"); } ```

A bit of the GitHub spice

まあ、対応してませんよね。

  • SHA: be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
  • User@SHA ref: mojombo@be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
  • User/Project@SHA: mojombo/god@be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2
  • #Num: #1
  • User/#Num: mojombo#1
  • User/Project#Num: mojombo/god#1

シンタックスハイライトまだー?

レーザー核融合反応の実験・・・?

昨日、レーザー核融合反応の実験に成功、クリーンエネルギー実現か=米国 2012/07/20(金) 09:49:46 [サーチナ]について色々考えてみたことについてまとめておく。

おかしな所整理

その1 500兆W=米国全土の消費電力量の1000倍・・・?

米国全土の消費電力量の1000倍以上に相当する500兆ワットのエネルギー

ワットというのは「電力」の単位で「電力量」とは本質的に異なるもの。本質的に異なるものを直接比較はできない。2chのレスにもあったけど、「新幹線の速さは時速300 kmで、これは東京-新潟間の距離に等しい」と言っているのと同じ。

その2 本当に核融合したの?

「レーザー核融合反応の実験に成功」とかかれると核融合反応が起きたみたいだけど、この記事だけだと核融合したか疑問。核融合って起こすことももちろん難しいけど、続ける方がもっと難しい。なんだか5兆Wが強調されているけど、本当に核融合ができたなら注目すべきは核融合の持続時間。それが書かずに反応成功というのはなんだか不自然。

ソース情報を確認してみる

そういうわけでソース情報確認。この記事は、NIFのプレスリリースNational Ignition Facility makes history with record 500 terawatt shotが元になっているらしい。はじめの段落に概要が書いてあります。

The NIF laser system of 192 beams delivered more than 500 trillion watts (terawatts or TW) of peak power and 1.85 megajoules (MJ) of ultraviolet laser light to its target. Five hundred terawatts is 1,000 times more power than the United States uses at any instant in time, and 1.85 megajoules of energy is about 100 times what any other laser regularly produces today.

自信ないけど、日本語訳するとこんな感じ?間違ってたら教えてください。"at any instant in time"の意味するところが正確にはわかってないけど、きっとこんな感じ。

192本のビームを有するNIFのレーザシステムは、最大パワー5兆W(500TW)、1.85MJの紫外レーザパルスをターゲットに与えることに成功しました。500TWはアメリカの瞬間消費電力の1000倍、エネルギ1.85MJは従来の他のレーザが生み出すものの100倍に相当します。

アメリカの消費電力

日本語記事の「消費電力量」は「瞬間消費電力」の間違いだったんですかね?Wikipediaの消費電力の項消費電力 - Wikipediaによると、2008年のアメリカの年間消費電力量は4,401,698GWh。一年は8784時間だから、これで割ってあげると、平均消費電力は約500GW。500TWの約1000分の1ですね。

(ところでWikipedia、電力の単位はW、電力量の単位はWh、消費電力の単位はWhってなっている。消費電力は電力量って入ってないけど、電力量なの?)

これは元記事もちょっと不親切だったかもしれないね。電力とレーザ光の強さはどちらもWという単位で表されるけど、エネルギの形態が違う。
電力は電気エネルギ、レーザ光は光エネルギ。もちろん本質的には同じもので相互に変換したり比較もできるんだけど、両者を直接比較すると、同じ種類のもので同じ目的に使うんだろうと思えてしまう。特に、W=電気の何かとしか思ってない人はね。

核融合なんてなかった

元記事のこの第一段落には一番大事なことが書いてあるはずなのに、核融合なんて言葉は出てこない。その後の偉い人が「これは点火を達成しクリーンな核融合エネルギ実現に近づくステップとなるでしょう」みたいなコメントをしていて、ここで核融合が出てくる。が、この人が言っているように、今回は核融合を実現したわけじゃなくて、その前段階の実験が成功しただけ。核融合はこれからです。

結局何がすごかったの?

今回の実験単にレーザ光照射と言っているけど、実際は192本のレーザビームの組み合わせらしい。超強力なレーザビームのそれぞれの強さ、照射タイミングを正確に合わせた、ってところがすごいんだと思う、たぶん。

ず's » 「米国がレーザー核融合に成功、電気出力500テラワット」という釣り記事についてでも触れている通り、記事中の1.85MJっていうのは、電力量に直すと0.514kWh、熱量に直すと442kcal程度でしかない。(有効桁数と単位は重要です。)この程度のエネルギ時間を掛けてターゲットへ渡すことは簡単だけど、1兆分の数秒というすごーく短い時間の間に行えたというのがこの実験。

1.85MJってカロリーにすると442kcalでしょあんまり多くない・・・って思ったけど、金属を溶かしてしまうレーザ溶接機でも1パルスあたりのエネルギ量は70J程度(低価格・高品質・高出力 YAGレーザー溶接機「LR-300A」 - YAGレーザー溶接機|メカトロジャパン)レーザ溶接機の約26万倍のエネルギをレーザ溶接機の約1億分の1の時間で照射しているわけですか。条件が違うのでちょっと比較対象としては不適かもしれませんが、NIFのレーザがかなりの高出力なのは想像できるんじゃないかと思います。

米国立点火施設-National Ignition Facility-におけるレーザー核融合および高エネルギー密度科学研究の展望という解説記事によると

来年中に,NIF の紫外レーザーのエネルギーは設計上限値である 1.8 MJ に達し,核融合点火および基礎科学研究
で必要とされる高い温度,高い密度を実現する予定である.

とある。
この解説記事が書かれたのは2011年なので、2012年の今年予定通りに実験に成功したというわけですね。NIFについてはよく知りませんでしたが、解説記事を読むとすごい規模なんだとわかります。「33,500以上の大型・小型の光学素子で構成され,200 万行以上のプログラムで書かれたソフトウェアで 60000 箇所以上が制御されている」とか怖い・・・。

まとめ

igo-javascript を node.js で動かしてみた

igo-python 作った人がこんなことつぶやいていたので、node.js で動かせるようにしてみた。

https://twitter.com/#!/hideaki_t/status/181186221073117185

ブラウザ上で使えてたTyped ArrayがNode.jsでは使えないので、Bufferにちょこちょこと書きなおし。とは言っても名前が違うだけでどちらも普通の配列っぽく振る舞うのでそんなに大きく書きなおさずにすんだ。あとはエラーチェックが少し厳密みたいなので少し書きなおした程度。ソースはgithubからどうぞ。

https://github.com/shogo82148/igo-javascript

MeCabのnode.jsバインディングが使えないホスティングサービスなんかでも使えるはず。



使えるはず、というだけでは何なのでアカウントを取ったまま放置してたherokuで動かしてみたよ!

http://warm-moon-4139.herokuapp.com/

heroku初めて使ったけど楽チン。gitの使い方で手間取った事(テスト用にmasterからブランチ切って作業してたのを忘れてチュートリアル通りにコマンドを打ってた・・・)はすんなりといった。
でもherokuって WebSocket 対応してないんだね・・・せっかく node.js 使うならやってみたかったのに。


ちなみに heroku にプッシュしたレポジトリは github-pages に上げたものと全く同じ。
サーバが動的ページを表示できるかを自動判別して、動的ページを表示できる場合はサーバ側のigo-javascriptを、静的ページしか扱えない場合はigo-javascriptをダウンロードしてクライアント側で実行します。

サーバ側で実行しているigo-javascriptとクライアント側で実行しているigo-javascriptは全く同じソース。同じソースがどちらでも動くって面白い。

igo-javascript で N-Best解を出力してみた

igo-javascript で N-Best解を出力してみたよ。

http://shogo82148.github.com/igo-javascript/

Igoは前から順番にビタビアルゴリズムで最小コストを求めた後、後ろから最小となるルートを貪欲法でたどっていきます。これは単純な動的プログラミングなので簡単ですが、これからNBest解の求め方がよくわからなかった。

で、いろいろ調べたところ、後ろ向きの検索を貪欲法でなくA*のような検索アルゴリズムにすればよいようです。(そろそろChaIMEについて一言いっておくか - 射撃しつつ前転)

A*検索には「ゴールにたどり着くにはどれくらいのコストがかかるか」を予想するヒューリスティック関数が必要となります。ヒューリスティック関数は何でもいいわけではなく、最適解が出力されることを保証するためには「ヒューリスティック関数≦実際にゴールにたどりつくまでのコスト」という条件を満たさなくてはいけません。(A* - Wikipedia)
ビタビアルゴリズムで求めた最小コストはこの条件にぴったりなので、これをヒューリスティック関数として使うと効率的な検索ができます。最適解が見つかった後も検索を続ければNBest解の出力もできるというわけです。


この検索方法を実装するにあたって、解の候補から最小コストのものを取り出す、という操作をしなくてはなりません。
これを効率的に行うためにヒープ(優先キュー)をJavascriptで実装しました。ライブラリ部分だけ取り出して別レポジトリに上げておいたので見たい方はそちらから。

https://github.com/shogo82148/jsheap


さて、NBest解を使って何をしようか・・・

zipjsでigo-javascriptの辞書を圧縮

この前作ったJavascript形態素解析をするプログラム、辞書をダンロードする関係上起動がやたら長い。2回目以降はキャッシュが効くから速いけど、初回だけとはいえ40MBのダウンロードはさすがにでかすぎるよね・・・。

そういうわけで、辞書の圧縮をしてみた。Javascriptだけでzipの解凍をするというのを見つけたので解凍部分はこれで。

https://github.com/hinassan/zipjs

ところが実際試してみると巨大ファイルの展開がうまくいかない。次のところでスタックオーバーフローを起こす。

String.fromCharCode.apply(null, this.data);

不勉強でapplyとかcallとかいうのをこの件で初めて知った。この二つのメソッドは、普通は暗黙的に設定されるthisを明示的に設定するためのもの。たとえば、次のプログラムの各行はすべて同じ動作をする。

"a,b,c".split(',');
String.prototype.split.call("a,b,c", ',');
String.prototype.split.apply("a,b,c", [',']);

一番上が最も一般的だと思うんだけど、実は他の書き方のシンタックスシュガーみたいなものだったわけですね。
で、最後の方法では引数の受け渡しに配列が使えるから、これを上手く使うと可変長の引数の受け渡しが簡単にかけると。
PythonでいうところのfromCharCode(*data)みたいなことができるわけですね。

で、結局このコードは

fromCharCode(this.data[0], this.data[1], this.data[2], ... , this.data[this.data.length-1]);

と同じことをしているわけで、this.dataの中身を全部スタックに積んでしまうから馬鹿でかいデータではスタックが溢れてしまったようです。
シンプルに書けてかっこいいんだけど、扱えるデータサイズに限度があるし、実は素直にループで書いたほうが早かったりするので使い所は慎重に選びましょう。


単純にループを回してもいいんだけど、そもそも文字列変換ってオーバヘッドになるよね。
最近のブラウザではTypedArrayという高速な配列が使えるというのでこれを使って書きなおしてみた。

https://github.com/shogo82148/zipjs


あとからTypedArrayを使って機能も豊富な jsziptools っていうのを見つけたんだけど、TypedArray版zipjsのほうが高速になったので、辞書の解凍にはzipjsを使うことにした。手元でunzipコマンド叩いたときの5割増くらいで解凍できたので割りと高速なのでは。



このzipjsを組み込んだigo-javascriptをgithubのほうに上げておきました。

http://shogo82148.github.com/igo-javascript/

解凍を高速化したとはいえ40MBものデータの解凍には5,6秒かかってしまうので、WebWorkerを使って並列処理してます。
初回起動は速くなったかな?
しかし、今度は2回目以降の起動が・・・