2010年4月25日日曜日

【Haskell】正格フラグの使い方


Haskellのデータ構造は一般的にlazyである。それによって、評価されたときにエラーやプログラム停止をもたらすような要素をデータ構造に含めることができる。lazyなデータ構造によってHaskellの表現を高めることができ、Haskellのプログラミングの重要な側面となっている。

内部的には、lazyなデータオブジェクトは、thunkと呼ばれる構造でラップされており、内部にエラーが含まれていても影響がない。たとえば、("a", ⊥)というタプルを保持することができる(⊥は未定義な値を表す)。一方、ほとんどのプログラミング言語は正格で、値が評価されてからデータ構造に入れられる。

ところが、thunkにはオーバーヘッドが大きいというデメリットがある。構築と評価に時間が必要だったり、heapにthunkのためのメモリが必要になる。

Haskellでは、このオーバーヘッドを避けるために、正格評価させるフィールドに正格フラグをつけることができる。正格フラグを付けた方が良いケースとしては、実行中の特定のタイミングで評価されるべきものや、評価がシンプルで決してエラーとならないもの、部分的な未定義値が意味をもたないものがある。

正格フラグの例としては、複素数ライブラリのComplex型があげられる。
data RealFloat a => Complex a = !a +: !a
実部と虚部に正格フラグが付けられており、これらのフィールドには評価後の値が保持される。

正格フラグはデータコンストラクタでのみ使うことができる。逆に、関数の引数に対して正格処理をさせるようなフラグはないが、関数評価に!$演算子を使うことで同等のことを実現できる。

正格フラグを使うときの注意点としては、使用しないデータがメモリに残ってリークしがちな点がある。また、lazinessはHaskellの根本的な性質であり、正格フラグによってその性質を曲げることで、無限ループの発見が難しくなったり、予期せぬ結果をもたらす可能性はある。たとえば、循環定義がある場合には注意が必要である。



2010年4月18日日曜日

【書評】ソフトウェア企業の競争戦略


ソフトウェア企業の競争戦略(原題:The Business of Software)は、MIT(マサチューセッツ工科大学)スローン経営大学院教授のマイケル A.クスマノによる著書である。

著者はもともと70年代後半から、特に自動車の設計と製造に関する、日本の製造管理と品質管理の技術を研究していた。日本の製造業が急成長し、日米の貿易摩擦が顕在化し始めた時期である。

そんな中、著者は自動車の次に日本が挑戦するのはコンピュータ・ソフトウェアだろうと考え、日本企業が大規模な商業用ソフトウェア・システムをどのように構築しているか、すでに日本人が確立しているハードウェアのスキルに高度化されたソフトウェア・スキルをいかに追加しようとしているか、を研究し始めた。

研究を進めるうち、著者は、ソフトウェアが戦略と管理の面で特別な問題をはらむ独特のビジネスであると認識するに至る。85年のことだという。

本書は、著者の20年近くにわたるソフトウェア業界の研究、数十ものソフトウェア企業や組織へのコンサルタントとしてのかかわり合い、さらには1997年から続けられているMITでの「ソフトウェア・ビジネス」クラスでの教育経験から得られた観察をまとめたものである。

第1章には本書の概要を記してある。ソフトウェア・ビジネスが他のビジネスと異なっている点、技術としてのソフトウェア、日本企業からマイクロソフトに至る研究、欧米企業と日本企業の重要な違いについてまとめ、また、ソフトウェア・ビジネスの典型的な事例として、仏ビジネスオブジェクツと米i2テクノロジーズの2社を紹介している。

第2章では、ソフトウェア企業のとるべき戦略について述べている。製品企業なのかサービス企業なのか、ターゲットは個人か法人か、マスかニッチか、水平的か垂直的か、メインストリームを狙うのかキャズムを回避するのか、マーケットリーダーかフォロワーか補完製品メーカーか、会社にどのような特徴を持たせたいのか、といった問いが投げかけられている。

第3章は、ソフトウェアビジネスの歴史である。過去を研究する事で進むべき方向についての示唆を得られるとしている。1950年代にはハードウェアを販売する事が主目的でソフトウェアは付属品であった。独立したソフトウェア製品のビジネスが登場するのは60年代である。70年代に新しいプラットフォーム「PC」が出現する。「ワールド・ワイド・ウェブ(WWW)」という次のプラットフォームが90年代に現れる。この歴史を踏まえて、第4章以下で、次のビジネスチャンスがどこにあるのかを問うていく。

第4章では、ソフトウェア開発のベスト・プラクティスと銘打って、ソフトウェア開発を最適管理するにはどのようにしたら良いか考察している。ソフト開発で繰り返し発生している問題と、多くのソフトウェア・ファクトリーを通して試みられている技術の構造化、およびソフトウェア工学分野での取り組みについて紹介しつつ、それが誤った考え方を導くことになったと指摘し、重要になってくるのは繰り返しのプロセスを生み出そうというSEIの概念や、頻繁な同期と周期的な安定化だと結論づけている。

第5章は、ソフトウェア起業家精神についてである。製品開発の視点にとどまらず、とりわけ戦略とビジネスモデルにまで視点を広げ、ソフトウェアのスタートアップ企業を成功裏に設立するために本書の内容がどう当てはまるかを考察している。

第6章は、スタートアップ10社のケーススタディである。筆者が取締役、顧問、コンサルタントとして知るところとなったスタートアップ企業10社について、成功企業、失敗企業、現段階ではまだ何ともいえない企業の3つに分類して述べている。

最後に第7章で、ソフトウェアのスタートアップ企業にとって「理想的」もしくは「ベストの」モデルは何かを一般化することは考慮すべき変数があまりにも多く難しいとしつつも、少なくとも法人向けソフトウェア企業の場合、ビジネスモデルの判断基準は製品企業、サービス企業、ハイブリッド企業のどれを目指すのかという1つに帰結できると結んでいる。

ソフトウェア開発に関する本は、開発手法やプロジェクト管理についてのものはそれこそ掃いて捨てるほどあるのだが、ビジネスという視点から論じているものは驚くほど少ない(大きめの本屋でコンピュータ関連の棚を見てみればわかるだろう)。ソフトウェア企業の競争戦略は、ソフトウェアをビジネスの面から論じた数少ない本であり、かつ、内容としても非常に優れた良書である。



■その他、本に関係するエントリ

研究開発を着実に利益に結びつける方法
CUDAの入門本
最近読んでいるマーケティング本
コンピュータ将棋のいま

-

引き続き、粒子ベース剛体シミュレーション

引き続き、粒子ベース剛体シミュレーションです。

重力を追加し4つのキューブが落下するシーンを計算しました。

■Δt=0.0033sec


さらに、タイムステップによる挙動の違いを見るために、Δtを変えていくつか計算しました。先ほどの動画はΔt=0.0033secです。

■Δt=0.0017sec


■Δt=0.0008sec


■Δt=0.0004sec


■Δt=0.0002sec


これらを見比べると、タイムステップを変えるだけでキューブの挙動が変化しています。タイムステップを変えていき、Δt=0.0004secとΔt=0.0002secまで小さくすると、だいぶ挙動の違いがなくなってきています。


■剛体シミュレーションに関するエントリ

粒子ベース剛体シミュレーション(プレビュー)
粒子ベース多体衝突シミュレーション


■流体シミュレーションに関するエントリ

粒子法のプログラム第1回(概要)
粒子法のプログラム第2回(プログラムの大枠)
粒子法のプログラム第3回(データ構造)
粒子法のプログラム第4回(密度と圧力の計算)
粒子法のプログラム第5回(力の計算)
粒子法のプログラム第6回(境界条件と粒子位置の更新)
粒子法のプログラム最終回(粒子の出力)
【粒子法】粒子を流体としてレンダリング
3次元の粒子法シミュレーション
粒子法のシーンを2倍のサイズにしてみたが…
粒子法のシーンを2倍のサイズにしてみた
SPHによる巻き波のシミュレーション2
Haskell、OCamlでSPH法
このあとやりたいこと
-

2010年4月15日木曜日

粒子ベース多体衝突シミュレーション

いま、粒子ベースのアプローチで多体衝突シミュレーションを実装しています。



剛体を粒子の集まりとして表現することで、衝突判定と応力の計算を行います。

この方法の強みは、ポリゴンベースのアプローチに比べて、アルゴリズムが単純なことと、複雑な形の物体について効率良くシミュレーションできることです。

上のムービーでは立方体の衝突をシミュレーションし、立方体を表現するために使っている粒子をそのままレンダリングしています。

■関連する記事
粒子法のプログラム第1回(概要)
粒子法のプログラム第2回(プログラムの大枠)
粒子法のプログラム第3回(データ構造)
粒子法のプログラム第4回(密度と圧力の計算)
粒子法のプログラム第5回(力の計算)
粒子法のプログラム第6回(境界条件と粒子位置の更新)
粒子法のプログラム最終回(粒子の出力)
【粒子法】粒子を流体としてレンダリング
3次元の粒子法シミュレーション
粒子法のシーンを2倍のサイズにしてみたが…
粒子法のシーンを2倍のサイズにしてみた
SPHによる巻き波のシミュレーション2
-

2010年4月13日火曜日

このブログのアクセス傾向

このブログは粒子法関連のキーワードではいってくる人が多いんだけど、春休みシーズンや年末年始はアクセスが減る傾向がある。

きっと学生さんが見にくることが多いんだろう。

2010年4月4日日曜日

理想的なベッドの選び方


ここのところ数ヶ月、どうも疲れが抜けない。寝ても疲れて、どんどん消耗する困った状態になっている。原因が分からず、運動してみたり仕事の負荷を下げてみているのだが、いっこうに良くならない。

そこで、もう原因として残っているのはベッドだなと思い、ベッドを変えてみることにした。

いま使っているベッドは、折りたたみできる簡易的なもので、その上に布団を敷いて寝ている。以前にもベッドが原因ではないかと疑って床にマットと布団を敷いて寝てみたのだが、そのときは特に改善がみられなかったので、ベッドが原因ではないだろうと思っていた。

とはいえ、寝て起きるときが一番しんどかったり、腰や背中が痛かったりと、症状としては寝疲れなので、思い切ってベッドを変えてみる。

ベッドの選び方


ベッドは、主にベッドフレームとマットレスからなっている。このうち、寝心地に元も影響があるのはマットレスなので、マットレスに絞って調べてみた。

マットレスを決めるポイント


マットレスを決める要素としては、
・スプリング
・枠材の有無
・詰め物の層
・生地
・一層か二層か
といった点があげられる。

これらのうち、寝たときの姿勢に最も影響するのがスプリングである。スプリングについては、最も重要な要素なので下方で詳述する。

その他の要素として、枠材というのは、スプリングの外側、マットレスの周囲に沿って構造材を入れるかで、これはマットの耐久性に関係する。スプリングだけ では寝返り時の横ズレでスプリングがへたりやすくなるため、周囲に構造材を埋めることでスプリングの耐久性を増すことができる。

詰め物の層とは、スプリングの上に層状に入れられたもので、これは通気性や表面の感触に関係する。マットによっては表面と裏面で材質を変えて、片方は通気性に優れた夏用、もう片方は保温性に優れた冬用、といった機能を持たせているものもある。

生地はマットの一番外側の布地で、これは純粋に肌触りや視覚的な効果に関係する。キングストンなど値段の高いメーカのマットは、このあたりで差別化を図っている。とはいえ、寝たときの姿勢をサポートするというマットレス本来の機能という点では影響しないところでもある。

最後に一層か二層かというのは、マットレスのスプリング層と詰め物層の間にしきりをいれることで、詰め物層で柔らかく体をつつみ、スプリング層でしっかり支える、というもの。二層の方が質が高く、その分高価になる。

スプリングについて


さて、これらのポイントのうち最も重要な要素がスプリングだというのは前で書いた。それでは、スプリングにはどのような種類があるのかというと、大きく2種類あり、
  • ボンネルコイル
  • ポケットコイル
となっている。

ボンネルコイルというのは昔からあるスプリングの種類で、1本のワイヤをいくつものコイルに巻いて敷き詰めた形になっている。特徴としては、体を面で支え、横ズレに強く、通気性が良い。フィーリングとしては堅い印象。ポケットコイルよりも価格は安く、半値になることも。

一方、ポケットコイルというのは、独立したコイルを布で包み、それをマットの中にたくさん敷き詰めた構造となっている。体を点で支えるのが特徴で、より体 全体を包み込む柔らかいフィーリングとなる。ただ、横ズレに弱く、スプリングを布で包むため通気性が悪くなりがちで、値段としては、製造に手間がかかるのでボンネルコイ ルに比べ高価になりやすい。とはいえ、体全体を包み込まれる感じはとても優れている。

どちらのマットを選ぶのが良いか?


どちらのマットが良いかは、体格や体重にもよるので人それぞれだが、販売員の方の話では、ポケットコイルを好む人が7割だそうだ。

ベッドを販売しているお店に行けば実際に横になって寝心地を試すことができるので、一度行ってみると良いだろう。


■最近のエントリ
subversionでテキストがバイナリに誤認識されてしまう場合
WiMAXを契約したのでそのまとめ
Haskell(GHC)をMac OSX 10.6 Snow Leopardにインストールする方法
Silverlightとトロイの木馬
ghciのコマンドまとめ
-

subversionでテキストがバイナリに誤認識されてしまう場合には


subversionに日本語のUTF-8ファイルを追加したときに、テイストファイルであるにも関わらずバイナリと誤認識されてしまうことがあります。バイナリと認識されてしまうと、svn diffで差分を表示することができずに困ります。

バイナリと認識されてしまっていることは、svn addしたときに(bin)と表示されるのでわかります。また、次のようにしても調べられます。
$ svn propget svn:mime-type hoge.tex
application/octet-stream
これはmime-typeがapplication/octet-streamになってしまっていることを表しています。

バイナリと誤認識されたファイルをテキストとして再認識させるには、mime-typeをtext/で始まる文字列にすれば大丈夫です。あるいは単にmime-typeを消すだけでもOK。
$ svn propset svn:mime-type text/x-tex hoge.txt
$ または svn propdel svn:mime-type hoge.txt
$ svn commit -m ''
さらに文字コードを指定したい場合は svn:mime-type 'text/plain; charset=euc-jp' などとすればよいです。

■最近のエントリ
WiMAXを契約したのでそのまとめ
Haskell(GHC)をMac OSX 10.6 Snow Leopardにインストールする方法
Silverlightとトロイの木馬
ghciのコマンドまとめ
MacBookPro用インナーケースまとめ
-