はてなブックマーク

例のアレです。今年は五月頃にソニーリーダーを失くしてしまう、しかも突っ込んでいた論文のバックアップを取っていなかったという悲劇のおかげで、ちょっとアレがアレしてるんですけど…バックアップは大事ですね！ Sound Predictive Race Detection in Polynomial Time race なんて大嫌いだーってなってる頃に読んだ論文です。今も変わらず嫌いですけど…とりあえず id:shinichiro_h さんがもう書いているのでアウトソーシング。 …だけだとあまりにも酷いので、えーっと何が面白いかというか嬉しいかというと。兎に角 race というのは、race のないコードを書くのも一定大変なんですが、あるコードに race がないことを保障することができない、というのが何より辛いわけです。いくら race detector を利用して race が見つけられたとし

追記：四月からしばらくのお仕事が決まりました。ありがとうございました。 あけましておめでとうございます。今年もよろしくお願いします。新年一発目で求人エントリ書くことになるとは… まず最初に注意書きです。かなり面倒な人間の、かなり面倒な求職なので、そういう人間を抱えたくない、抱える余裕がない、という方には読んで頂かなくてもいいと思います。技術的に面白いエントリでもありません。ではちゃきちゃきと始めます。 経緯 一月現在、頸肩腕症候群を患っており、仕事を休職し療養しています。頸肩腕症候群については、別のブログになりますが、こちらのブログエントリを参照してください。 追記：あまり参照してもらえてなさそうなので二度いいますが参照してください。 現状、生活は傷病手当でなんとかできています。とはいえ、傷病手当は無限に貰えるわけではなく、期限が決まっています。ボクの場合、それが三月までです。現在所属して

型レの話書くの忘れてた…まあいいか。 値を何かしらでラップするみたいなことは、まれによくあります。 trait Nanka { type Rep[T] } trait Add extends Nanka { def add(lhs: Rep[Int], rhs: Rep[Int]) def add(lhs: Rep[Int], rhs: Rep[Double]) ... } でまあこういうのはコンパイルエラーになる。add メソッドはどれも type erasure された結果、同じシグネチャを持つメソッドになってしまうからですね。全部 Java が悪い。まあ type erasure のおかげで higher order type param とか実現できたりもするしそれはそれで…いやそれはおいといて。 前こういうのに遭遇したときは、仕方がないので implicit parameter

OUnit という単体テストフレームワークを使ってみます。XXXUnit と「大体あってる」二項関係をもつらしいです。 open OUnit let _ = run_test_tt_main ("test" >:: fun () -> assert_bool "should succeed" true) assert_bool は (@?) としても定義されています。 open OUnit let _ = run_test_tt_main ("test" >:: fun () -> "should succeed" @? true) 比較します。 open OUnit let _ = run_test_tt_main ("test" >:: fun () -> assert_equal 0 0) まあ普通ですね。"let (@=) = assert_equal" とかしておくといいかもしれ

旧聞になりますが「大学生の４人に１人「平均」分からず　数学基本調査、論理力欠如明確に」より引用。 「偶数に奇数を足すと必ず奇数になる」ことを数式と文章で説明する中２レベルの問題 ということらしいので coq を使って自分が中二レベルあることを証明してみましょう！ まずは奇数とは、偶数とは何なのかを帰納的に定義してやりましょう。 Inductive even : nat -> Prop := | even_O : even 0 | even_S : forall n, odd n -> even (S n) with odd : nat -> Prop := | odd_S : forall n, even n -> odd (S n). 見たままですね。証明したい定理はこんな感じじゃないでしょうか。 Theorem odd_plus_l : forall n m, odd n -> eve

#scala にあって他の関数型言語には見られない機能として、PartialFuncttionがあるが、良いものだと思う(命名は良くない。CheckableFunctionとか他の名前が良かった気がする)。おかげでcollectみたいなメソッドが定義できるし、他にも応用が利く。 という @kmizu さんの発言があったので Haskell でもやっときます。 {-# LANGUAGE TypeOperators #-} import Data.Maybe type Open a = a -> a fix :: (a -> a) -> a fix f = f (fix f) close :: Open a -> a close = fix type (a :->: b) = Open (a -> Maybe b) undef :: a :->: b undef f a = Nothing a

追記：これの完全版みたいなのが comfrk vol3 に載ってます。「今夜はお前と俺でマルチパラダイムだからな」とかいうのです。 あまりにもアウトプットしなさすぎなので適当に何か書きます。 フィボナッチ関数を scala で object-oriented な感じで書いてみます。 class Fib { def fib(n : Int) : Int = if (n <= 1) 1 else fib(n - 1) + fib(n - 2) } 簡単ですね。しかし、簡単すぎます。というわけで、お決まりのメモ化を「Fib クラスに手を加えず」に行ってましょう。 class FibMemo extends Fib { import collection.mutable.Map private val table : Map[Int, Int] = Map() override def fib(n

追記：3.0 より Bitmap はネイティブヒープを利用しなくなりました。キャッシュは 3.1 以降なら LruCache を使えば大体問題ないと思います。 手が痛いので、簡単に。 一年以上前の記事ですが、CacheオブジェクトにはSoftReferenceをとか、最近だと、WeakHashMap なるものがあるのねなどのページで、Bitmap を SoftReference で管理しよう！みたいなのが紹介されていますが、 それなりにヒープを消耗する場合は Bitmap の開放を GC に任せてはいけません。 そんなわけですから、面倒ですが recycle メソッドをちゃんと呼んであげましょう。ドキュメントに "normally need not be called" とありますが、これは「ヒープによほど余裕があるなら呼ぶ必要はない」と読み替えてください。実際そうです。 そもそも Bit

関手というのがどうもよくわからず。 ということなので、釣り記事を書こうと思います。 Haskell とか使ってる人って、これぐらい全部わかってるイメージがありますし、矢張り釣り針は大きいほうがいいので、C++ で説明してみようと思います。C++ の関数型表記だとちょっとイマイチなので C++0x を使います。 ガンガン嘘をつくので突っ込んでください。 関手というのは、めちゃくちゃ簡単にいうと「圏をとり圏を返す関数」です。あっ、みなさんが大好きな圏がしょっぱなから出てきましたね！モナドなう〜。 でも圏、カテゴリってなんだろう？ 圏というのは、一言でいうと「対象とその射からなる構造」です*1。 対象、射って何だろう？ということなんですけど… 突然ですが bool ってご存知ですか？勿論そりゃご存知でしょうけれども、少し説明してみます。 C++ には bool という型があって、この型の値として

これは C++ advent calendar の参加記事です。 真面目な C++0x の紹介や入門は 25 日もあれば誰かが書いてくれると思うので、C++0x について何も知らなくてもすぐに分かる、ちょっとだけ幸せになれるかもしれない極めて些細な tips を書きます。後に変態記事ばかり続かないといいんですが :-) 条件を満たす要素が含まれているかどうかを知る こんなコードを書いたことはないでしょうか？ if (c.end() != std::find_if(c.begin(), c.end(), equal_by_xxx())) // ugly! 終端のイテレータとの比較を毎回書かされるのは、正直うんざりですね。C++0x ならこう書けます。 if (std::any_of(c.begin(), c.end(), equal_by_xxx())) 古い API とのやりとりに STL

HIMA' に参加してきました。今回のお題は「gitとdarcsの使い方」。 darcs のパッチ理論の話とか聞けるかなーと思っていたのですが、聞けなかったのでちょっと残念でした。そもそもパッチ理論の話出来る人っているのかなっていう… とりあえず恐らく利用者が多いであろう git ユーザー向けに darcs の特徴とか。 バージョン管理というよりパッチ管理。 歴史（コミットが形成する DAG）は存在しない。あるのは積み重なったパッチだけ。 パッチ間の依存関係を考慮したシステム。依存関係さえ問題なく解決されていれば、昔のパッチを削除しようが何しようが関係なし…ヒエー ブランチはない。ブランチが欲しければリポジトリを作る。 インデックスはない。 author と committer の区別はない。あるのはパッチの作成者だけ。 パッチに名前がある。基本的にパッチは名前で指定。 こんなもんですかね

メタプログラミング ruby を読みました。よくまとまっていて、いい本だなあと思いました。 個人的にはあんまり ruby で実行時にメソッドやクラス、モジュールを操作することはメタじゃないと思っているんですが…それはうさつのとして…折角なのでメタっぽい話を一つ。 オブジェクトのメソッドを一時的に別の物にすり替えたい、という時があります。 例えば ActiveRecord の ActiveRecord::Base#inspect は、実装に ActiveRecord::Base#attribute_for_inspect を利用しているのですが、この attribute_for_inspect は、50 文字より長い文字列を省略してしまいます。irb を使っている時等は、だらだらとひたすらに長い文字列が出ても困るのでありがたいのですが、それでは困ることも当然あります。 テストなんかのことを考

http://togetter.com/li/42968 全体的に違和感があったので、少し書きます。 yreeen: ファクトリなら機能追加を見越してバージョン番号を渡すように引き数作っとけばいいし。pimplの方が優れている部分が正直思い浮かばないんだけど何かあるんですか教えてえりゅい人！ pimpl でも抽象クラスとファクトリを利用することはできます。 // header ///////////////////// class c { public: c(params); void f(); private: class c_impl; shared_ptr<c_impl> pimpl_; }; // source ///////////////////// class c::c_impl { public: ~c_impl(){} virtual void f_impl() = 0;