JavaScript のビット演算は遅くない？

JavaScript の「ビット演算」は遅くていいことがないと、JavaScript: The Good Parts では悪者扱いされています。 遅くなる理由として、ビット演算を行う際に倍精度浮動小数点型を整数に変換し、ビット演算後にまた倍精度浮動小数点型に戻す処理を行うため、とある。

では、この処理でどのくらい遅くなるのだろう？
Chrome で次のようなコードで試してみた。

// 足し算 +
var flag,
    v = [1, 2, 4, 8, 16, 32, 64, 128];

for (var i = 0; i < 9000000; i++) {
    flag = v[0] + v[1] + v[2] + v[3] + v[4] + v[5] + v[6] + v[7];
}


// ビット演算は '+' を '|' に置き換え
    flag = v[0] | v[1] | v[2] | v[3] | v[4] | v[5] | v[6] | v[7];

足し算とビット演算をそれぞれ 9000 万回実行して時間を計測してみると、普通の足し算では平均して 151 ms で ビット演算では 122 ms。
 ・・・えっ、ビット演算の方が速いではないか！

ビット演算は言われているほど遅くなく、むしろ速いようです。

僕の中では、ビット演算子は "good parts" に昇格です。


JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス


リンク：JavaScript のビット演算は遅い？

JavaScript のビット演算は遅い？

JavaScript: The Good Parts によると JavaScript のビット演算は予想に反して、ハードレベルに近い演算からは程遠く、遅いとのこと。
JavaScript の数値オペランドである倍精度浮動小数型を整数に変換して、それから演算を行い、また倍精度浮動小数型に戻すという処理をしているため。

そのため、ビット演算を使う必要性が無いので「悪いパーツ」とされている。

しかし、JavaScriptグラフィックス で興味深い説明があった。
ビット演算を使うことによりアルゴリズムを変更できる時には、高速化に使える場合がある。
あるプロパティが存在するかどうかを示すフラグとして、変数のあるビットが立っているかどうかを見るという使い方をすることがある。

こんな例が示されている。

var search = ['big', 'young', 'white'];    // このプロパティを持った犬をさがす
for (var c = 0; c < search.length; c++) {
    if (dog[search[c]] == undefined) break;
}
if (c == search.length) {
    /* 見つかった！ */
}

上記のようにしたい時は、下記のようにビット演算を使うと高速化できる。

var searchFlags = 128 + 32 + 4;    // 128: big, 32: young, 4: white を表す
if (searchFlags & dog.flags === searchFlags) {
    /* 見つかった！ */
}

なるほど。「悪いパーツ」と言われているものを盲目的に切り捨ててもいけない。
というか、いろんな人の意見を聞くというのは大事なんだなぁ。


JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティス

JavaScriptグラフィックス ―ゲーム・スマートフォン・ウェブで使う最新テクニック


リンク：JavaScript 本：「JavaScript パターン」と「JavaScript: The Good Parts」
リンク：JavaScript のビット演算は遅くない？

JSLint のページがリニューアル

昨日とは違う画面になっていた。
JSLint のページが新しくなっていました。

オプションの有効・無効の設定が、今までは、白と黒と灰色の表示でしたが、False と True と Default という文字の表示になってわかりやすくなっている。

これまで、オプションの設定に白と黒と灰色の３種類あって、なんで２種類じゃなくて３種類なんだろうと思っていたら、３つめは "Default" だったのか！

んっ、Default ?
Default って True と False のどっちなんだろう・・・。

JSLint で自分のコードをチェックしてみた

JSLint でチェック

JavaScript の品質チェックツールである JSLint を使ってみました。
Web 上で実行してみると警告メッセージがたくさん出た。
見慣れないメッセージがたくさんあり（初めてなので見慣れないのは当たり前だが）、何を直せばいいのか一瞬途方に暮れる。

JSLint は JavaScript の書き方をより良いものにするためのチェックをしてくれるわけですが、では "より良い" というのは、何を目指せば良いのか？　JSLint に合格するには何をすれば良いのか？

何を目指せば良いのかの指針がここに書いてある。
http://www.jslint.com/lint.html （これの翻訳が "JavaScript: The Good Parts" の付録 C にある。）

エラーメッセージ

もう一度エラーメッセージを見てみる。いくつか代表的なものをピックアップ。

・グローバル変数

Problem at line 2 character 12: 'document' was used before it was defined.

すべての変数は使われる前に定義されていないと、JSLint ではエラーとみなされる。 ブラウザで HTML に対して JavaScript を使用する時には "document" プロパティは当然、変数としては 宣言しないのでエラーになります。
オプションの "Assume a browser" にチェックを入れておくとブラウザであることが仮定されて、 document などのグローバルプロパティは宣言済みとみなされエラーとならなくなります。


・var

Problem at line 23 character 10: Move 'var' declarations to the top of the function.

変数宣言を関数の先頭で行いなさいということ。

for (var i=0; i<max; i++) {

といった var の使い方もダメです。
（でも、"JavaScriptパターン" の中で上記のような書き方をしているところを見つけてしまいました。フフッ。 "JavaScript パターン" では全てのコードが JSLint をパスしているはずなのに。）


・インデント

Problem at line 16 character 5: Expected 'callback' at column 9, not column 5.

インデントした文の開始が 5 ではなく 9 列目からにしなさいということ。 自分のコードの中で一つこのエラーの理由がよくわからないところがあるのですが、インデントの指針がどこにも書いていないし、ソフトの品質とは関係ない問題なので、オプション "Tolerate messy white space" で チェックしない様にします。（少し後ろめたいですが・・・。）

Warning!

JSLint のページの最初に、

Warning!
JSLint will hurt your feelings.

とあるように、些細な体裁の問題でたくさんのエラーが出るのでちょっと嫌になります。 でも、JavaScript を公開する前にはやっぱり一度はチェックするようにしようと思います。

なぜなら、

1. JSLint ではブラウザのデバッグツールで見つからなかったエラーも見つかることがある。
2. JSLint は些細な体裁も指摘してくれるので JavaScript 初心者でも、パッと見は恥ずかしくないものに直せる。

からです。

コンパイラは悪くない

インデントの問題に蓋をしてしまいましたが、自分のコードをよくよく見るとインデントにスペースとタブが混在していました。
タブはスペース 4 つと計算されるようです。
本来は同じレベルのインデントになるはずの文で、一方はスペースとタブでもう一方はタブのみとなっていて、 それでインデントを合わせなさいというような警告になっていたのでした。
（最近 Emacs の設定でインデントのタブをスペースに置き換えたので、そのためにスペースとタブが混在してしまったのかもしれません。）

ついつい、コンパイラの方を疑ってしまいました。
達人プログラマー への道は遠いなぁ。

達人プログラマー―システム開発の職人から名匠への道

タイピングアプリ 「Type Fu」

タイピングを正確にしたいと思っていたところに、タイピングアプリの紹介記事を目にしたので、 これを使って練習しています。（Chrome の拡張機能です。）

きちんとタイピングできない人や改めてタイピングを勉強したい人へ～無料でタッチタイプが練習できる「Type Fu」

1 回の練習が 10 秒〜 20 秒程度で終わるので疲れないのがいいです。
10 秒を何回も夢中になってやっているうちに、ほんの少しずつ問題のレベルが上がっていっていつの間にか身に付いている、といった感じで、問題もイイ具合の問題です。

JavaScript 本：「JavaScript パターン」と「JavaScript: The Good Parts」

JavaScript 本を２冊読んだ。

JavaScript パターン

JavaScript を安全に（= 間違いにくく）使うためのパターンを解説した本。
パターンと言っているのはデザインパターンだけでなく関数の使い方、オブジェクトの使い方などのベストプラクティス的な方法全般を言っていて、JavaScript 独特の「書き方」を説明している。

解説には分かりやすいコードがたくさん使われていて、そこから JavaScript の流儀に触れられる点でも良かった。

新しく JavaScript を学び始めたが、文法はよく知っている言語のアナロジーで理解できるが、 書いてみるとJavaScript らしくならない。この本を読んでやっと JavaScript の世界へ一歩踏み込めた感じがする。
個人的には以下の章が特に JavaScript らしさを知る上で役立った。

3章 リテラルとコンストラクタ、 　
4章 関数、 　
5章 オブジェクト作成のパターン、 　
8章 DOM とブラウザのパターン

JavaScript: The Good Parts

 JavaScript は美しい言語だが醜い部分もある。美しい部分だけを取り出したサブセットを使うことによって JavaScript を美しいままに保とう、といったコンセプトで本書は書かれている。
不要なものは学ばなくてもいいしそれはいい考えだ！、と思って真っ先に読んだ JavaScript 本でした。
ですが、挫折しました。横着してはいけません。やっぱり先に入門書を読むことは必要でした。

今回は、入門書とJavaScript パターンを読んでからのリベンジです。
選び出した「Good parts」を系統的に説明していて、ひと通り文法を理解している人が改めて読み直すと新しい発見があるといった類の本だと思います。

醜い危険な書き方を避けて、美しい安全な書き方を選ぶというのは、実は「JavaScript パターン」と 目的は同じで、内容的にも重複している部分もあります。両著者ともYahoo! のエンジニアということもあるのでしょうか。

両書を読んで

タイトルからは別々の内容を想像しますが、コンセプトはほとんど同じで、また、両者はまるで一人の人が書いているのかと思うほど、哲学が似ています。
「パターン」の方はアンチパターンを示してからベストプラクティスへ導くようなストーリー性の説明に対して、「Good Parts」の方は選り抜きの「良いパーツ」一つ一つに着目して説明されています。
どちらかと言うと「Good Parts」の方がより上級向きといった印象でした。

Emacs の動画

Emacs の動画に刺激を受けたのでまとめておく。

• Writing PPT with org-mode and beamer in Emacs
• Emacs Power: Can your editor do THIS!
• Emacs with HTML, Zencoding and YASnippet

Emacs の解説。（実はこういうので英会話のリスニングを勉強すると身に付くのではないか。）

• Emacs: Introductory Tutorial
• Emacs in 10 minutes!
• Hack Emacs - Working with Windows and Frames
• Hack Emacs - Hacking the Mode Line (live)
• Hack Emacs - Org Mode In Depth: Managing Structure
• RT 1 - emacs keyboard introduction
• RT 2 - emacs part 2 - more advanced emacs
• RT 3 - emacs part 3 - org-mode and babel
• Emacs Yasnippet with elisp (Parenthetically Awesome)

人がエディタを使っているのを見るのは面白いし、ちょっとした癖なんかも、使い方改善のヒントになる。
高速タイピングに憧れていたが、ちょっと考えが変わって、これからは、速くなくてもいいので、

1. 正確なタイピング
2. snippet や補完を使い込む

ということで効率化を目指すようにしよう。