お引っ越ししました
旧はてダ http://d.hatena.ne.jp/tad0/ から、このはてブロに引っ越してきました。
これからもいつ書くか分かりませんが、どうぞよろしくお願いします。
Ruby Summer of Code近況報告
※この記事は、私の英語版ブログのエントリをベースに和訳しています。
自分のRuby Summer of Codeプロジェクト、 Decimal はうまく行ってる感じです。
中間評価のためにいくつかの目標を設定しましたが、すべてがほぼ終わりました。
ただ注意していただきたいのは、この夏の作業が最新のtarball/gemに反映されていないことです(ごめんなさい…)。最新機能を試される方は、プロジェクトのsubversionレポジトリのtrunkからcheckoutをお願いします。(間もなく行う次のリリースには反映されます)
設定していた目標を順番に挙げてみます。
Webページの作成
まず最初に、シンプルなWebページを作りました。
単純過ぎかもしれません…が、必要な情報は載せたつもりです。少なくとも以前の(殺伐とした)ものよりは、良くなりました :)
以下のような情報が載っています。
数学関数の実装
最近の作業の中では、一番分かりやすい部分だと思います。
計24個の数学関数をDecimal::Math.function()として実装しました。もちろんテストケース付きです。ほとんどの関数はBigDecimalに欠けていたもので、::Math.function()としてFloat用にだけ存在していたものです。
acos(x, n)acosh(x, n)asin(x, n)asinh(x, n)atan(x, n)atan2(y, x, n)atanh(x, n)cbrt(x, n)cos(x, n)cosh(x, n)erf(x, n)erfc(x, n)exp(x, n)frexp10(x)(frexpのマネ)hypot(x, y, n)ldexp10(x)(ldexpのマネ)log(x, n)とlog(x, arbitrary_base, n)log10(x, n)log2(x, n)sin(x, n)sinh(x, n)sqrt(x, n)tan(x, n)tanh(x, n)
上記に加え、pi(n) と e(n) もあります。
xとyには、DecimalかIntegerが指定できます。またnには(多くの場合、正の)Integerを「スケール」(scale)として指定します。これは「小数点以下n桁」という意味です。
以下がその使用例です。
簡単でしょ? ;)
全関数がテストを通っており、ほとんど仕様も固まっているので、それほど大きなつまづきもなく使えると思います。チェックしてみてください! (ドキュメントは間もなく追記予定です。)
ただ残念ながら、gammaとlgammaという二つの関数だけが未実装です。これが、まだリリースができていない理由です。
最新のRubyへの対応
DecimalはRuby 1.9.1と1.9.2devに対応しました。Ruby 1.9.1でBignumの実装が改良されたので、Decimalを1.9.xと一緒に使えば性能も上がります。 (Decimalは内部的に、BignumのAPI群に依存しています)
もちろんRuby 1.8.xでもDecimalは使えますが、上記の理由から1.9系を推奨します。
既知のバグの修正
SEGVを起こしたり、誤った値を返したりするような、既知の致命的なバグは直しました。他にもバグや未確定の仕様はありますが、いじってみるためには十分安定していると思います。特にBigDecimalとスピードを比べてみてください。新しいだけあって、だいたい全部速いですよ。
次のリリースは……このあとすぐ!
残りの数学関数が実装・テスト完了次第、現状を「Decimal 0.1.0」としてtarballとgemでリリースする予定です。
もしDecimalの最新情報を手に入れたいという危篤な方は、日本語でおkなdecimal-talk-jaメーリングリストか、ここのフィードを見ていただければ幸いです。(英語ブログの方を優先して更新しますが、随時こちらにもportします。)
というわけで、次のリリースまでチャンネルはそのまま!
ArrayとHashの非対称性
同じところ
両者とも、[]メソッドによる存在しないキーへの参照に対しては、nilを値として返す。
[1][1] #=> nil {a: 1}[:b] #=> nil
またそのようなケースが望ましくなく、存在しないキーを渡した時に例外を上げたい場合には、fetchメソッドが使える。
[1].fetch(1) #=> (IndexError) {a: 1}.fetch(:b) #=> (KeyError)
違うところ
Hashならば生成時に、[]メソッドによる存在しないキーへの参照に対し、nil以外の値をデフォルト値として指定することができる。
Hash.new(:void)[:b] #=> :void
一方、Arrayはそれが単純にできない。nil以外の値を返したければ、fetchメソッドの第二引数にそれを毎回指定しなければならない。
{a: 1}.fetch(:b, :void) #=> :void
fetchメソッドに関しては、Hashも同様に第二引数を指定可能だ。Hash.newでデフォルト値を指定しても、fetchに第二引数を設定すれば、後者が優先される。
Hash.new(:void).fetch(:b, :anothervoid) #=> :anothervoid
思うところ
何でArrayでデフォルト値の設定ができないのだろう?
Hash同様、fetchの第二引数を指定する方法はあるが、毎回指定するのでは「デフォルト値」= 「怠惰なケース」のとしての旨味が薄くなる。要は、すっきりしない。
具体的なケース挙げて、Array.newでデフォルト値を指定できるよう、仕様変更を引き出す人を所望します。
未踏アナウンスktkr
ついったログ見てたら需要がありそうなので、mixiからport。
25日夜九時ごろ。登録していたIPAメールマガジンに、ようやく「未踏」の文字が載りました。「未踏ソフトウェア創造事業」あらため、「未踏IT人材発掘・育成事業」です。
IPA 独立行政法人 情報処理推進機構：未踏／セキュリティ・キャンプ
何で遅れたのよ! もう今年度は始まってるのよ!!
元々自分の知る限りでは、少なくとも昨年8月の時点で「見直し」の方向が明示されていました。(経済産業省のPDF)
8ページ目から:
「未踏ソフトウェア創造事業」…については見直しを行う…「スーパークリエータ発掘・支援事業」…に名称を変更
この時点で、名称や内容を変えた上での存続は決まっていたことになりますね。
続いてクリスマスイブに出た文書でも「行政改革」(gyoukaku.go.jp)の一環としての廃止が明記されています。(PDF)
…未踏ソフトウェア創造事業につき、平成19年度で廃止するものとする
んなわけで、特に後者がソースと見られるウワサを聞いた人にとっては「未踏なくなるってよ!」という話も真実味を帯びていたのかもしれません。が、名前はさらに変わったものの、8月の文書どおり存続ということになったようです。
というのがおそらく、アナウンスが遅れた経緯。
どこが変わったって言うのよ! 全然分かんないわ!!
さて、肝心の中身です。
なんだかんだ「見直し」とか言ってても、正式名称以外は俺が思った以上に変わってなかった。
- 略称は「未踏」を堅持
- 本チャンとユースの二本立て
- 期間も上期・下期の二本立て
ぶっちゃけ要項見ても、一番何が変わったか分からん。
……と思っていたら、ユースを狙う大学生・院生に耳寄り(i.e. 残念)なニュースが! (ユースの要領PDF)
２００８年４月１日現在、２５歳未満の個人又は個人からなるグループであること
ヒャー。ちゃ〜ん。対象年齢下がってるよ〜。ここは門が狭くなったわけね。
まぁ前の名称の時から「目的は人材発掘」って言ってたわけで、名前とともにユースの目的もそれに合わせたのはそんな悪いことじゃない気もする。
まぁ「下限はありません」なので、幼稚園児の娘・息子を代表者にパパが支援して稼いじゃえばいいと思うよ俺。
そして俺が一番気になってたんが金額。上記の通り、政府の文書からは「合理化の一環として見直し」という空気が芳しく漂ってたので。
実際、要項のPDFをざっと見てみたらこんな感じ↓。
- 本体: プロジェクトあたりの上限700万、人件費は時給4000円に固定
- ユース: プロジェクトあたりの上限300万、人件費時給2000円固定
- 共にプロジェクト管理組織費用は50万に固定
昨年度とそれ以前を詳しく知らんけど、上限額だけ見る限りは変わり映えしないような。固定とかが新しいんだろうか。
いずれにせよ、審査が厳格寄りになる可能性は避けられないのかもしれない。
結局いつなのよ! 優柔不断もいい加減にして!!
しかしそれにしても、スケジュールがgdgd。アナウンスがここまで延びたから、開発期間は
- 上期: 7月中旬〜3月上旬
- 下期: 12月中旬〜8月上旬
らしいよ。センセー、どこの国のこよみを基準にした「上下」なんですか〜 (?_?)/
まぁいいや。とりあえず上期お申し込みの〆切は
- 本体が 5/30
- ユースが 6/16
らしいですよ。応募しる > 興味持った全員!!
俺としては別件があるから応募しずらいんですよねぇ。ユース出す気マンマンだったのに……でも年齢制限も近づくし、悩みどころ。
そう、分かったわ……でもオチがないじゃない!
まぁつくば民的に注目すべきは
- 本チャンPM全体に占める 2 / 9 が本学教授 (二郎ちゃん + 加藤先生)
という一点でしょう。 筑波大シェア = 22.2% (笑)
新装書籍部にて
新装された書籍部に、そいつは居た。
id:kakutani++。
着想から13年、Googleから5倍早いGNUリンカの新実装が登場
面白かったので言及してみる。ちなみにまだググってない。
gold: Google Releases New and Improved GCC Linker | Google Open Source Blog
Googleの中の人であるIan Lance Taylor氏が、GNUリンカを一から書き直した新実装「gold」をリリースした。既にbinutilsのHEADでは、configure時に「--enable-gold」を指定することで(従来のGNU ldに代わって)利用できるそうだ。
goldの売りは一点、高速性。氏によると、でかいC++アプリのリンクは五倍程度高速になるのを確認済らしい。またgold自体もC++で書かれていて、5万行しかないらしい。これってかなり小さいですよね?
ただし現在、goldが使える環境はELF+x86/x64のみだそうだ。その点まだ未熟だが、当然Google社内での利用を経たリリースらしいので、ある程度の安定性は期待できるだろう。「すべてのフリーなプラットフォームでデフォルトのリンカにしたい」とのことなので、将来的にはELFやx86以外の環境へのport、ひいてはGNU ldの完全な置き換えも期待できる。
g++(C++)のコンパイルがgcc(C)に比べて有意に遅いのはよく知られた事実だと思う。例えば先日、自分はフリーのGUI(だけじゃないけど)ツールキットのQtをコンパイルしたけれど、Pentium4 2.4GHzのマシンでは「ほぼ一晩」かかった。厳密にフェアな比較ではないにせよ、似たようなライブラリであるGTK+とそれが依存するライブラリ群すべてのビルドが「2時間以内」に終わったことを考えると、やはり速度の開きを感じてしまう。(GTK+、Glib、Pangoなどなど...はすべてCで書かれている)
もちろんgoldはCにも用いられるであろうが、C++使用時の方がリンク時のコストが高いんだろうと邪推する。ビルドの全行程の中でリンクがどれだけの割合を占めるかは分からないが、速くて困る人はいない(暇つぶしのゲーム時間が少なくなること以外は)。MoziilaもKDEもOOoも、大きな福音と受け止めるだろう。
にしても感心してしまうのがその歳月のスケール。1992年にパッチを投げ始め、93年には一からの書き直しを議論し始めている。2006年に手をつけ始めるまで、構想13年。そして今年のリリース。
その継続された努力と情熱にはほんとに頭が下がりますです。今日からおいそれとすぐ実行できる長さの話ではないけれど、見習いたいものです。
