だいぶ以前に、円周率を3にして子供に計算させるという話がありました(しかも「3であると教える」と誤解されて謂れのない批判を受けました)。誤差がたかだか5%で、演算が3倍高速になる場合に高速なほうを採用する場合が、大人の算数ではしばしばあります。それを子供にも教えるというのは、教育も進歩したなぁと思います。未開の頃からDNAは大して変わっていないのに、人類が教養レベルを上げてきた背景には、こういう教育の進歩が大きいと思います。

誤差5%というのは1Mを1000*1000とするか1024*1024とするかの違いと同じくらいで、大人はよく意図してこれらを混同して使いますよね。あくどい話。

3D Now!という命令セットは今となってはありふれていますが、当時整数演算しかできなかったMMXに対して浮動小数点演算ができるようにした命令セットで、この命令セットは基本的に1クロックで実行されることになっていました。しかし一部の演算(割り算だったっけ？)は同じ精度で演算するのに1クロックでは実現できず、精度を高める命令というのを追加で実行すると補間されて精度を保証できるようになるという話がありました。これも似た話ですね。

強力FW陣と言われた川崎が得点できないのは、最後のところ、シュートやラストパスの精度の問題だと思います。速度を重視しすぎてしまい、誤差が得点の閾値を越えてしまったのです。最適化によりシュートに至る時間が短くなり、たくさんシュートを打つことができますが、そのために精度が犠牲になっている。根本的な原因は3番を欠番にしてシーズンを計算しはじめてしまったことなのかもしれないなぁと思った瞬間にこの駄文を書きはじめてしまいました。意味不明ですね。

雨、尋常ではない寒さの中での試合。

内容はかなり良くなっていますが結果に結びつきませんでした。チャンスもたくさん作りシュートも打ってるんですが。

前半の攻勢もそうですが、後半開始直後から川崎が攻めまくり、千葉はクリアボールを拾われ続けており、「こいつら、つなぐ気ないな…」と思っていたところ、キャプテンマークをつけた下村がドリブルで持ち上がって、パス2本で崩されて先制点を献上(下村トミーいい選手ですね)。それからも攻め込むものの、また少ないパス数でゴールまでもっていかれた。左サイドのスペースはうまくケアしたけど、そこから右サイドに振られ、井川がしてやられました。

スタッツを見たら、シュート21本は川崎にはよくあることかもしれませんが、CK20本というのはちょっと見た記憶がない値。キッカーも大橋なのに、なんでこれで点が入らないんでしょうかねぇ。相手GKの立石は確かに当たってたけど。

神戸から帰ってきました。さすがにこういう試合を見るとヘコみます。

まあヴェルディ戦よりは幾分マシになってましたね。川崎はグラウンダーのパスをつないでゴールに向かっていくのを基本スタイルにしていると思っているので、ヴェルディ戦のサッカーよりは川崎らしかったと思います。崩しはまだまだで、シュート数は多かったけど決定機はあまりなかった。チャンスが生じてないのに無理して打ちすぎ。よほどのチャンスでしか打たない我那覇を使ったのは正解だと思ったんですけどね。シュートばかりでリズムが単調になってしまうので。

点をたくさん取られたのは守備の問題。FC東京戦の後半に神戸が数多くのチャンスを作り出した、その形がそのまま川崎相手に通用して大量点を生み出していました。FC東京は途中で修正して対応できてたんだけど、川崎にはできなかった。岡田主審が取った最初のファウル(確か大久保がちょっとした接触でFKをゲット、そのFKからゴールネットを揺らされるがオフサイドの判定)の影響でガツガツいけなくなったというのはあったかもね。関塚監督はどう修正していくのか…

4410.tvって昨年すでになくなってたんですね。今日出場するということで見に行ったら、web.archive.orgに行く羽目に…それにしても、よく覚えてたな俺。

中継を全く見られず、映像を見ることができませんでした。スカパー！は昨年一瞬だけテレ朝チャンネルに入ってすぐに解約していたんで。

結果だけ見ると鹿島が大勝、ガンバもいつか等々力で見たような引き分けと、悪くない結果です。1位上がりだけなんで、下位に負けないこと、ライバルになりそうなところとの直接対決を制することが重要で、1戦目は負けなければよいという試合でした。問題になりそうなのは鹿島が中国の北京国安との2試合、ガンバはメルボルンとチョンナム(川崎とも対戦したクラブ)との4試合か。印象としては、各クラブの実力が拮抗しているガンバのグループのほうがやりやすいんじゃないかと思いますね。

ところで、スカパー！の登録を確認しようとしたら、何度やってもログインできない。IDとパスワードはプログラムに覚えさせているので、合っているはず。しかしできないものはできない。しょうがないのでパスワードを再発行してもらおうとしたがメールアドレスが違うとか言われてそれもダメ。詰んだか、詰んでしまったのか…

ジュニーニョが帰化って。冗談かと思ってましたが、フッキのときと違って肯定するような続報も出てきているし、これはそろそろ踊らないといけないですね。もう遅いくらいで。

それだけ日本を気に入ってくれたというのは喜ばしい。

川崎からPKを取ることで知られる西村主審が裁いた試合。今回は引っ張って引っ張って、終了間際のPKでした。そのシーンはよく見えませんでしたが。

とはいえシーズンの最初の試合ですから、試合は結果よりも内容に注目すべきでしょう。川崎は風を意識しすぎたのか、フィジカル系FW2人を意識しすぎたのか、とにかくハイボールを前線に送り、ひたすら競らせるという、あまり面白みのない試合を展開。それなりに効果的な攻撃ではあったと思いますが、相手を研究してきたヴェルディのほうが持ち味を出せていました。まあ代表組が合流して時間がなかったんでしょう。今日は谷口が良かったかな。

混雑していてイベントを回る隙はなかった。買うつもりだったグッズも、タオマフくらいしか買えなかったよ…今度ガラガラのアズネロに行って買おう。川崎市民の歌は運営にリードされる必要はないんじゃないかな。新曲がいくつか発表されたが、試合中は歌う機会がなかった。神戸では歌いたいね。試合前のまったり時間に久木野の歌の原曲が流れたのは気がついたけど、他の歌も流れてたのかな。

味スタに行ってきました。朝ニュースをチェックしたら佐原が怪我でベンチを外れたという情報を見てだいぶ萎えましたが、それでもでかけました。 新横浜という手も考えたんですけどね、帰り道に勝ち誇る赤い人に囲まれるという不快を思って避けたんです。今思えば新横浜が正解だったような気もしますが。

それで、味スタ。新田義貞像を横目に分倍河原で乗り換えて行ったんですけど、準特急に乗り、慣れていそうなガスサポ2組と同じ車両に乗ってついて行ったら調布まで行き過ぎてしまいました。ガスサポですら間違ってしまう京王線、どうにかならないですかね。アナウンスを信じるべきでした。以前にアナウンスに逆らってガスサポについて行ったら飛田給に止まる電車だったこともあったんだけど。

神戸サポはでかいビッグフラッグを持ち込んで席に展示。いやー、なかなかの大きさでした。

試合。得点は同じような位置からのセットプレーから押し込んだもの。今野と栗原だったかな。

東京は5番の長友が気になりましたね。前半は石川直の出来にかなり依存していた気がする。あとカボレへの期待感は半端じゃないな。♪かぼれかーぼれそうかーぼれ、すきになっちゃうかぼれ

いつも忘れるし、わかりにくいのでメモしておこう。いつもタブだから…とTab Mix Plusの設定とかを探してしまうんだよな。

1. Add Bookmark Here 2を入れる
2. Add Bookmark Here 2の設定で「[タブですべて開く]の位置」を「非表示」にする
3. ついでに「[ここにブックマークを追加]の位置」も「非表示」にするとブックマークがすっきりする

これで日常生活の危険がぐっと減ります。

boostは噂の通り、熱いですね。ほんとにこれがC++か？ と思えるほど。STLを初めて見た時もかなりの衝撃でしたが、boostはその上を行ってます。C++さんはまた遠くに行ってしまったんだね…

そういえばSTLのbitsetはコンパイル時に長さを決めるので扱いづらいなぁという印象を受けたことがあったなぁと思ってboostのbitsetを見てみると、boostには実行時に長さを変えることができるdynamic_bitsetがありました。がんばるなぁ。

試しにboost.pythonを使ってPythonから使えるモジュールにしてみました。

Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bitset
>>> b=bitset.bitset(12)
>>> b
bitset("000000000000")
>>> len(b)
12
>>> dir(b)
['__and__', '__class__', '__delattr__', '__dict__', '__doc__', '__eq__', '__ge__',
 '__getattribute__', '__getitem__', '__gt__', '__hash__', '__iand__', '__ilshift__',
 '__init__', '__instance_size__', '__invert__', '__ior__', '__irshift__', '__isub__',
 '__ixor__', '__le__', '__len__', '__lshift__', '__lt__', '__module__', '__ne__',
 '__new__', '__nonzero__', '__or__', '__reduce__', '__reduce_ex__', '__repr__',
 '__rshift__', '__setattr__', '__setitem__', '__str__', '__sub__', '__weakref__',
 '__xor__', 'any', 'clear', 'count', 'find_first', 'find_next', 'flip',
 'is_proper_subset_of', 'is_subset_of', 'none', 'num_blocks',
 'push_back', 'reset', 'resize', 'swap', 'to_ulong']
>>> b[4]=1
>>> print b
000000010000
>>> b
bitset("000000010000")
>>> b.flip()
>>> b
bitset("111111101111")
>>> b.flip()
>>> b
bitset("000000010000")
>>> b.flip(2)
>>> b
bitset("000000010100")
>>> b[4:9]
bitset("00001")
>>> b[-1]
False
>>> b[:5]
bitset("10100")

普通にto_string()を使ってるのに、バイトオーダの影響か、後ろから表示されてますね。boostもboost.pythonもまだよくわからない部分が多いですが、使えなくもないと思います。b1&b2,b1|b2,b1^b2とか~b1といった演算、あとシフトと引き算、大小比較もboostのものをそのまま使ってやってます。