« 2008年6月 | トップページ | 2008年8月 »

2008年7月24日 (木)

正規化は正しくない、かもしれない

「ノーマライゼーションはノーマルじゃない」の方が語呂が良いですね。

Never, never should you normalize a database out of some vague sense of duty to the ghosts of Boyce-Codd. Normalization is not magical fairy dust you sprinkle over your database to cure all ills; it often creates as many problems as it solves.

Maybe Normalizing Isn't Normal (Coding Horror)

データベースの正規化は、データベースの非正規化と同じくらいには、問題を引き起こすので、無分別に行なうべきではない、という論旨のようです。データーベースの正規化は、クエリのパフォーマンスを低下させ、理解しやすさを損ね、データベースを使いにくくすると。

私も同感です。何であれ、設計というのは、形而上学的に正しい解を求める過程ではなく、目的に手段を適合させる過程であると思います。データベース設計においても、ユーザが何を求めているのか、ユーザにどのような価値を提供しようとしているのかを、よくよく考えて行なうべきでしょう。自動的に解が見つかることはないでしょうね。

以下に、コメント欄を含めた、まとめがあります。

The Mother of All Database Normalization Debates on Coding Horror (High Scalability)

いくつか気に入ったものを意訳してみます:

Normalization is about optimizing large numbers of small CrUD operations, and retrieving small sets of data in order to support those crud operations.

...

Denormalization is about optimizing retrieval of large sets of data. Choosing an efficient database design is about understanding which of those operations is more important. (RevMike)

正規化は、大量の小さな挿入・更新・削除操作を行なう場合に使う。非正規化は、巨大なデータを取り出す場合に使う。データベース設計を効果的に行なうには、どういった操作が重要なのかを理解しなくてはならない。

Is my Site OLTP? If the answer is yes then Normalize. Is my site OLAP? If the answer is yes then De-Normalize! (WeAreJimbo)

OLTPなら正規化、OLAPなら非正規化が答えだ。

Be careful not to confuse a denormalised database with a non-normalised database. The former exists because a previously normailsed database needed to be 'optimised' in some way. The latter exists because it was 'designed' that way from scratch. The difference is subtle, but important. (Bob)

非正規化(denormalised database)と、無正規形(non-normalised database)を混同しないように。前者は既に正規化されたデータベースを「最適化」する。後者は初めからそのように「デザイン」される。違いは微妙だが、重要だ。

| | コメント (0) | トラックバック (0)

2008年7月22日 (火)

検証と証明

もし我々の考えている定理が、すべての数について真であることを示すかわりに、たとえば 6 なる数について真だということだけを示したいとすれば、段々になって流れている三段論法の滝のうちから最初の五つだけを証明すれば十分である。 ... もっと大きい数についてならば、もっとたくさんとらなければならない。しかしその数がどんなに大きくても、いつでも我々はいつかはそれに到達し得るから、それで分析的検証が可能である。

しかしながら、こうしてどこまで行っても、我々は決してすべての数に適用をみるような一般的な定理までにのぼることはできまい。 ... 形式論理だけに頼っている分析論者の忍耐によっては、いつまでたっても満たすことのできない深淵をとび越さなければならない。

ポアンカレ著, 河野伊三郎訳, 『科学と仮説』, 岩波文庫, 1959, p32-33

結局のところ、計算機プログラムを計算機上でいくら実行し、その結果が正しいことを 検証 したところで、そのプログラムが正しいことの 証明 とはならないでしょうね。現実の計算機は、有限のリソースによって制約されますから、計算機プログラムの取りうる状態は有限であるとはいえるのでしょうが、しばしば、全てを検証するには一万年あっても足りないというような大きさであったりします。

チューリング・マシンのような、概念上の計算機は、無限のリソースを持っているわけですが、計算機プログラムも概念的には、無限の状態を取りうるものであると、少なくとも、アルゴリズムの設計段階では考えるものでしょう。この段階で計算機プログラムの取りうる無限の状態に対して、計算機プログラムが正しいことを証明できなければ、計算機プログラムの正しさを保証するチャンスはないのかもしれませんね。

概念上、計算機プログラムの正しさを証明することができたからといって、現実の計算機プログラムの正しさまで保証されるわけではないわけですが。概念上、正しくない計算機プログラムは、現実にも正しくない、ということはいえますね。

計算機プログラムの正しさというのは、それが、現実に計算機上で実行される前には既に決まっていて、 その後、いくら計算機上で実行し検証したところで保証できないものである といえるのではないでしょうかね。

| | コメント (0) | トラックバック (0)

フローチャート不要論

を主張する人の、フローチャートの定義がいまいちよくわからなかったりしますが。

フローチャートというのは、状態遷移図の一種ですよね。この場合、プログラムカウンタ、あるいは、それを抽象化したものが状態変数になっていて、現在実行中のプログラムの「位置」が代わるごとに、状態が遷移していく様子を図式化したものだと思います。

フローチャートというのは、バッチ入力のコンピュータ・プログラムを記述するために、状態遷移図を「カスタマイズ」したのでしょうね。プローチャートと一言にいっても、実際には色々な形式があるようですが、基本的には、バッチ型の単純な逐次実行で行なわれる処理を記述するものだと思います。

フローチャートというのが、オンラインが主流の現在では、時代おくれなのは確かでしょうね。結局、イベント駆動型の非同期処理やら、並列処理やらを記述する必要性が出てきて、再び「ただの」状態遷移図へとかえったとみるべきかと。

とはいえ、バッチ的な処理がなくなったわけでもありませんので、そうした場合には、フローチャートは使いますけどね。フローチャート的な状態遷移図といったほうが良いかもしれませんけど。一種類のボックスと線しかなかったりしますから。

入力データチェックのシーケンスを書くことが、一番多いですかね。 x < a なら、 エラーXXX で、そうでなければ、 y < b をチェックして、等と延々と連なっているような処理。こうした処理では、チェックの順番が意味を持つことは多いですから、フローチャートですと表現しやすいですね。

ちなみに、状態遷移図といいますか、状態マシン/オートマトンは、近年、なかなか面白い展開を見せていて、モデル検査という分野に発展しているようです。2つ以上の異なるプロセスを表現したオートマトンを、「掛け合わせ」て、ひとつの巨大なオートマトンを作り、この全ての状態遷移をチェックすることで、デッドロック等の並列処理のバグを見つけ出そうというもの。2007年の ACM チューリング賞は、この分野の研究者が受賞していますね。


SPINモデル検査―検証モデリング技法 Book SPINモデル検査―検証モデリング技法

著者:中島 震
販売元:近代科学社
Amazon.co.jpで詳細を確認する


| | コメント (6) | トラックバック (0)

2008年7月19日 (土)

トヨタ主任技術者の過労死報道

InfoQ より。ここでこの話題を見るのが、ちょっと意外だったので、目に留まったのですが。

Last month the Japanese labor board ruled that the death of the Chief Engineer on the Camry Hybrid project was 'karoshi' (death by over work). In his last few months he worked more than 80 hrs of overtime a month. He died of a heart attack only day before he was due to fly to the Detroit Auto Show.

Death of Hybrid Camry Chief Engineer is Ruled Overwork (InfoQ)

ソフトウエア開発でも、トヨタ生産方式を範とした、リーン開発というものがあり、それに関連しての議論がなされているようです(曰く、「主任技術者にあまりにも多くの責任を負わせているのでは」等々)。

それはともかくとしまして、元記事のリンク先の報道に、次のような文があります。

The man, whose name has been withheld at the request of his family, died in January 2006 of ischaemia - a shortage of blood to the heart - at his home in Toyota, central Japan, where the carmaker has its headquarters.

Senior Toyota engineer died of overwork (guardian.co.uk)

「遺族の意向により(亡くなった方の)名前を伏せる」という表現がありますね。こういう表現は、日本の報道では見たことがないように思いまして、何か新鮮に感じました。

日本のマスコミというのは、市民側ではなく、権力側にいる存在なのでしょうね。

| | コメント (0) | トラックバック (0)

2008年7月18日 (金)

信じること、疑うこと

表面だけしかみない観察者にとっては、科学の真理は疑いの余地のないものである。科学上の論理は誤ることはないし、学者がときおり思いちがいをすることがあっても、それは論理の規則を見そこなったためである。

【略】

少しでも反省したものは、仮説の占める領分が、どんなに広いかということに気がついた。数学者は仮説なしではすまされないし、実験科学者はなおさらだということがわかった。そこで、はたしてこれらのすべての構築が極めて堅固なものであるかどうかが疑われ、わずかの微風にあっても打ち倒されてしまうと信ずるようになった。こういうふうに懐疑的になるのは、これもまた表面的な考えである。すべてを疑うか、すべてを信ずるかは、二つとも都合の良い解決法である、どちらでも我々は反省しないですむからである。

ポアンカレ著, 河野伊三郎訳, 『科学と仮説』, 岩波文庫, 1959

統計データの場合、真偽といいますか、妥当性はもっと微妙になるわけですけど。

調査会社出身の私が、WEB上の数字について一言 (Out of Order)

このソースで統計を語るのは (文系大学的IT系の悲哀)

「出典が営利企業だから」というのと、「統計でウソをつく法」の一般論だけで、妥当性を否定してしまうのは、あまりに「表面的」ではないですかね。具体的にデータのどこがおかしいかを指摘できなければ、反証とはならないでしょう。

すくなくとも、以下の主張は、データから語りうる範囲で、妥当なところだと、私は感じましたけどね。

見ていただいたらとおり、 日本IT業界が、日本他業種に比べ労働条件が劇的に悪いという統計は、あまり見つけることが出来ません。 むしろあったら教えてください。

この状況では、 IT業界の人が「僕たちの仕事は泥に塗れている!」などといっていては、他業種でがんばっている人たちに恥ずかしすぎて顔向けできません。

「日本IT業界」は比較的泥ではない事を統計的に検証 (西岡Blog)

平均賃金 (あるいは収入でも資産でも) というのは、確かに「統計でウソをつく法」の類で、必ず出てくる例ではありますけどね。

というようなわけで、平均賃金の数字を見たら、まず、質問することである ― 平均の種類は? その数字に含まれている人は?

ダレル・ハフ著, 高木秀玄訳, 『統計でウソをつく法』, 講談社ブルーバックス, 1968, p.22

まあ、サラリーマンの収入なんてのは、だいたい業種と企業規模で決まってくるわけでして、そんなに大きな変動はないでしょう。経営者なら、大きく変動するでしょうけど。情報サービス産業で、30〜35歳の平均年収が、400万〜500万円程度、というのは、妥当なところではないですかね。情報サービス産業内での賃金状況は以下にあります。

2007年版 情報サービス産業基本統計調査 「概要編」 (社団法人情報サービス産業協会)

おそらく、水準的には、小売業よりは高いが、製造業よりは若干低い、といったところでしょう。

| | コメント (0) | トラックバック (0)

2008年7月11日 (金)

診療報酬削減で保険者は黒字

国庫負担 4兆961億円 を含めての「黒字」ではあるわけですが。

調査では、保険者全体の経常収支差が4192億円の黒字であることが明らかになった。組合健康保険は2372億円、政府管掌健康保険も1117億円の黒字で、国民健康保険は323億円の赤字だった。

保険者黒字は医療費抑制の結果 - 日医 (医療介護CBニュース)

”「中医協・医療経済実態調査(保険者調査) -平成19年6月実施- 」について (社団法人日本医師会)]”1 という資料に、平成18年度の保険者決算が載っています。よく知られているとおり、国庫負担はじめ税金の大部分は、国民健康保険に投入されていますね。

しかし、

政管健保も1,117億円の黒字であり、積立金が4,983億円ある。「肩代わり」してもらう必要があったのだろうか。

としながら、結論として、

平成20年度当初予算における政管健保の国庫負担「肩代わり」案のようなことは、今後も前向きに検討されるべきとの考えを示した。

というのは、何か一貫していない感じですね。診療報酬の削減ではなく、保険者側の財政調整で、医療費抑制に対処してもらいたい、ということの婉曲表現でしょうが。確かに、保険者全体で 4192億円 の黒字が出ているのなら、例の 2200億円 の「医療費削減目標」は、保険者側の財政調整だけで達成できそうですよね。

「肩代わり」に関しては、同じ被用者保険ということで、政管健保にしたのか、あるいは、市区町村単位に組合がある国保より、社会保険庁が一元管理している政管健保の方が事務処理が簡単だから、といったところでしょうか。国庫負担が減らせれば、何でも良いということなのでしょう。


1. http://dl.med.or.jp/dl-med/teireikaiken/20080709_4.pdf

| | コメント (0) | トラックバック (0)

Celestia スクリプト ― カメラの位置と方向 (Part 2)

簡単に解説をします。

座標系 "Ecliptical (Follow)"

”Celestia .CEL Scripting Guide"1 に説明があります。

The X axis points away from the Sun in the direction of the Julian 2000.0 vernal equinox. The Y axis is normal to the ecliptic with positive Y north. The Z axis completes the right-handed coordinate system.

”Celestia's Coordinate Systems”, p.12

すなわち :

  • X軸は春分点の方向
  • Y軸は黄道面の法線で、北の方向が正
  • Z軸は右手系をなすように定める

XZ 平面が黄道面になる黄道座標みたいですね。

位置

”Celx Objects and Methods”2 によりますと :

  newposition (x, y, z)
      Creates a new position object, from numbers or from URL-style Base64-
      encoded values.
        x, y, z: The components of the new position. Either as numbers (unit
                 is microlightyears), or as x, y, z string-values taken from
                 a cel-style URL.

ここで、”microlightyears” とはいかなる単位なのかといいますと、以下のようにあります。

MLY used as a DISTANCE:
   One MLY = 9,466,411.842 km. Define a constant of this value (ie. KM_PER_MLY
   = 9466411.842) and use it in your scripts where you need to convert from/
   to km/MLY.

方向

同じく、以下のようにあります。

 newrotation (axis, w) -OR- (w, x, y, z)
      Creates new rotation object (i.e. a quaternion).
           axis: Vector describing the axis of this rotation.
              w: The angle of this rotation (for details check out
                 quaternions).
      Or ...
        w,x,y,z: Number values for this quaternion.

ベクトル・角度(ラジアン)か、もしくは、 四元数(しげんすう、quaternion;クオータニオン) で回転/方向を指定するようです。 方向を指定する (setorientation) 場合、ゼロ度は Z 軸の反対方向、 XZ 平面に平行となるようです。

以下のスクリプトを実行して、結果を確かめます。 X 軸上に太陽の光が当たっていること、 Z軸上では角度がゼロとなること、などに着目していただければ。

-- test02.celx

KM_PER_MLY = 9466411.842

myearth = celestia:find("Earth")
celestia:select(myearth)
distance = myearth:radius() * 10.0 / KM_PER_MLY

myobserver = celestia:getobserver()
myframe = celestia:newframe("ecliptic", myearth)
myobserver:setframe(myframe)
myobserver:follow(myearth)

deftim = celestia:gettime()
defort = myobserver:getorientation()
defpos = myobserver:getposition()

celestia:print("test02", 3)
wait(3)

-- 春分
celestia:settime(celestia:tojulianday(2008, 3, 20, 0, 0, 0.0))

-- x軸上にカメラ移動
mypos = celestia:newposition(
  distance,
  0.0,
  0.0)
myobserver:gotolocation(mypos, 3)
wait(3)

celestia:print("shot 1", 3)
wait(3)

-- 地球中心方向へカメラ向き設定
myrot = celestia:newrotation(celestia:newvector(0.0, 1.0, 0.0), math.pi * -0.5)
myobserver:setorientation(myrot)
wait(1)

celestia:print("shot 2", 3)
wait(3)

-- z軸上にカメラ移動
mypos = celestia:newposition(
  0.0,
  0.0,
  distance)
myobserver:gotolocation(mypos, 3)
wait(3)

celestia:print("shot 3", 3)
wait(3)

-- 地球中心方向へカメラ向き設定
myrot = celestia:newrotation(celestia:newvector(0.0, 1.0, 0.0), 0.0)
myobserver:setorientation(myrot)
wait(1)

celestia:print("shot 4", 3)
wait(3)

-- y軸上にカメラ移動
mypos = celestia:newposition(
  0.0,
  distance,
  0.0)
myobserver:gotolocation(mypos, 3)
wait(3)

celestia:print("shot 5", 3)
wait(3)

-- 地球中心方向へカメラ向き設定
myrot = celestia:newrotation(celestia:newvector(1.0, 0.0, 0.0), math.pi * 0.5)
myobserver:setorientation(myrot)
wait(1)

celestia:print("shot 6", 3)
wait(3)

-- 元に戻す
celestia:settime(deftim)
myobserver:setorientation(defort)
myobserver:setposition(defpos)

celestia:print("fin", 1)
wait(1)

実行結果は以下のとおりです。

Test0200

Test0201

Test0202

Test0203

Test0204

Test0205

Test0206

| | コメント (0) | トラックバック (0)

2008年7月 9日 (水)

Celestia スクリプト ― カメラの位置と方向 (Part 1)

天文シミュレータ Celestia では、スクリプトを使ってカメラを移動させることができます。使えるスクリプトが2種類ありまして:

  • CELスクリプト (.cel)
  • CELXスクリプト (.celx)

前者のCELスクリプトというのは、コマンドを逐次に並べるような形になっており、プログラミングの機能はないようです。ただ、書いたコマンドが順に実行されるだけです。

後者のCELXスクリプトの方は、 Lua 言語エンジンが使われていて、変数、制御文、関数など、一通りのプログラミング機能が使えます。

CELXスクリプトで、カメラの位置と方向の設定を実験してみました。

-- test01.celx

KM_PER_MLY = 9466411.842

myearth = celestia:find("Earth")
celestia:select(myearth)
distance = myearth:radius() * 10.0 / KM_PER_MLY

myobserver = celestia:getobserver()
myframe = celestia:newframe("ecliptic", myearth)
myobserver:setframe(myframe)
myobserver:follow(myearth)
defort = myobserver:getorientation()
defpos = myobserver:getposition()

-- カメラ移動
mypos = celestia:newposition(
  distance,
  0.0,
  0.0)
myobserver:gotolocation(mypos, 3)
wait(3)
celestia:print("shot 1", 3)
wait(3)

-- カメラ向き設定
myrot = celestia:newrotation(celestia:newvector(0.0, 1.0, 0.0), math.pi * -0.5)
myobserver:setorientation(myrot)
wait(1)
celestia:print("shot 2", 3)
wait(3)

-- 元に戻す
myobserver:setorientation(defort)
myobserver:setposition(defpos)

celestia:print("fin", 1)
wait(1)

結果は以下のようになります。

Test0100

Test0101_2

Test0102_2

| | コメント (0) | トラックバック (0)

2008年7月 8日 (火)

小姑の国

正直、「居酒屋タクシー」の時点で、既に果てしなくどうでもいい話だと思っていましたが。

土日通勤定期券問題など ( BI@K accelerated: hatena annex, bewaad.com )

マイレージの話から、通勤定期の話にまで、話が発展しているようで。いや、ネタならいいんですけどね。典型的な 自転車置き場の議論 ですわな。

しかし、この話の恐ろしいところは、実際に「居酒屋タクシー」問題で官僚が処分されてしまったことでしょう。

なんといいますか......

大東亜戦争下で、日本軍が、玉砕だの特攻だのと、無意味に犠牲を増やしていたのは、やはり、日本国内の世論をはばかってのことであったのでしょうね。軍はやるべきことはやっている、これだけの犠牲を払っている、と民衆に対して、エクスキューズする必要があったのでしょう。

何か、そうした、血に飢えた民衆と、それに迎合する政府、といった図式の一端を見たような気持ちです。まあ、官僚の方々にしてみれば、「今さら」なのかもしれませんが。

| | コメント (0) | トラックバック (0)

2008年7月 2日 (水)

「量刑」の問題

行為の良し悪しをいえば、悪いに決まっているわけでして、残るは「罪」と「罰」のバランスの問題でしょうね。

「教員、大聖堂に落書きで解任の危機」−−。イタリア・フィレンツェの大聖堂に落書きをした日本人が、日本国内で停学や務めていた野球部監督の解任など厳しい処分を受けていることに対し、イタリアでは「わが国ではあり得ない厳罰」との驚きが広がっている。

イタリアの新聞各紙は1日、1面でカラー写真などを使い一斉に報道。メッサジェロ紙は「集団責任を重んじる日本社会の『げんこつ』はあまりに硬く、若い学生も容赦しなかった」と報じる。

落書き:伊紙「あり得ない」 日本の厳罰処分に 毎日jp(毎日新聞)

私は次のように感じましたけどね。

  • イタリア : 文化遺産より人間が大事。
  • 日本 : 人間より文化遺産が大事。

「人間を粗末にする国」ニッポンの面目躍如ですな。

Country Year Males Females
ITALY 02 11.4 3.1
JAPAN 04 35.6 12.8

Suicide rates per 100,000 by country, year and sex (WHO) より抜粋)。

10万人当たり自殺者数は、イタリアより日本が 3〜4倍多いみたいですね。この辺が、両国の「文化の差」というやつですかね。

| | コメント (0) | トラックバック (0)

« 2008年6月 | トップページ | 2008年8月 »