ときどきの雑記帖 2012

最新ページへのリンク
目次ページへのリンク

一つ前へ 2012年9月(下旬)
一つ後へ 2012年10月(中旬)

ホームへ

2012年10月10日

■_

会社の話。 つーても(会社の)業績がどうとか(自分の)仕事がどうとかいう話ではなく(省略されました)

■_

■_

「バーンダウンチャート」という声が聞こえたので調べた。

2012年10月09日

■_

イブニング。「レッド」の展開が

■_ エビデンス

■_ 1 と 9 との中間の値は?

というはなし。 What number is halfway between 1 and 9? | Hacker News What number is halfway between 1 and 9? Is it 5 — or 3? - MIT News Office

What number is halfway between 1 and 9? Is it 5 — or 3? - MIT News Office

Ask adults from the industrialized world what number is halfway between 1 and 9, and most will
say 5. But pose the same question to small children, or people living in some traditional
societies, and they're likely to answer 3.

Cognitive scientists theorize that that's because it's actually more natural for humans to think
logarithmically than linearly: 3^0 is 1, and 3^2 is 9, so logarithmically, the number halfway
between them is 3^1, or 3. Neural circuits seem to bear out that theory. For instance,
psychological experiments suggest that multiplying the intensity of some sensory stimuli causes a
linear increase in perceived intensity.

以下略

言われりゃあ「ああそうか」なんだけど、 全然思いつかなかった○| ̄|_ >指数

■_

■_

試験問題らしく。 きちんと説明かけるかちと不安である(こればっか)

Software development final exam: Part 1

Software development final exam: Part 1

This is part 1 of my software development final exam. If you haven't read that introductory blog
post, please go read it now.

Algorithms and Data Structures

    Is O(2^n) equal to O(3^n)? Why?
    O(2^n) と O(3^n) は等しいか? またそれはなぜか?

    What is the expected run-time of quicksort? What is the worst-case run-time?
    クイックソートの予想される実行時間とは?
    最悪のケースでの実行時間は?

    What is the difference between a binary tree [EDIT: that should be binary search tree] and a B-tree? When and why does this difference matter?
    二進木とB木の違いとは何か?
    その違いが重要になるのはどういったときでそれはなぜか?

    Name the heap operations used by heapsort and the asymptotic running time of each.

    Describe an algorithm that determines if a graph is bipartite.
    あるグラフが bipartite であるかどうかを判定するアルゴリズムを説明せよ

2012年10月08日

■_

いえね。エディオン秋葉原店(以前の石丸電気本店)でNexus 7 扱ってると聞いたので、 しばらくあそこで買ってないしちょうど良いかなあと思ったんですよ。はい。 入って即売り切れてしまったそうですが(そのあと再入荷があったとかは調べてません)。

特撮博物館 館長庵野秀明 特撮博物館 ミニチュアで見る昭和平成の技 行ってきました。 7月中に行くつもりだったのに最終日にようやくとかどうしてこうなった。

まあそれはさておき。 開館が10時ということなので、その30分くらい前に現地に着けばそれなりの時間に入館できるだろう チケット購入でも時間がかかってるという話も聞いているのでコンビニで買っていこう と思っていたのですが、家を出て駅までの途中にあるローソンで買おうとしたところ ローソンでの扱いは昨日の23:59までだった! (実はセブンイレブンでは最終日でも買えたらしい 【海外CM・映像アーカイブ】Galliano's TVC Review!: 特撮博物館をほぼ並ばずに見る方法) いきなりいやな予感に包まれたのですが、 買えないものはしかたがないので地下鉄で最寄り駅の清澄白河へ。

駅からちょっと歩きましたが(案内では8分とか)会場へ。 この時点で見込み通りほぼ9:30くらい。 チケット持ちの列がすでにかなり長くなってましたw チケット購入列に並び、ここで10分くらいかかってようやくチケット購入。 改めて入場待ち列へ。 どのくらい待つのかなあと思っていたのですが、 入館できたのは10時ちょい過ぎでした(開館時間を早めて入場させていたようです)。 中の話はまあ他の方が色々書いてますので省略します。

ちょっとだけ、誰かと一緒に行けば良かったなあと思ったのはこの辺り(東京タワーをバックに一枚とか)w

成田亨さんの書かれた記事(の文章)が成田亨コーナーの一角にあったのですが 重い内容だったなあ。って詳しく中身書いて良いのかな。 元は雑誌掲載の記事だと思うんですが。

■_

リーダブルコード読書会 #1 - %!zt! <diary> (2012-09-29)

ド読書会 #1 - %!zt! <diary> (2012-09-29)

    良い名前が難しい
        サンプル集があればいいのに
        例にあった filter とか
        連番になってるクラス名とかひどい
            昔の名残? 識別子が6文字までだった頃とか
    6.7 (「名前付き引数」コメント) は変数に代入して渡すのでこういうコメントはしたことがないという話
    (p.78 話には出さなかったが、ナイーブソリューションの意味が分からなくて調べたが、やっぱり意味が分からなかった)
    p.85 ヨーダ記法
        良いと思うのに (cuzic)
        __FILE__ == $0 (znz)
            $0 == __FILE__ (yuya)
            気にしない派 (kmdsbng)
    「}」 と else の間の改行を最近は入れるようになった (cuzic)
        コピペしやすい
        さっき CRuby はそうだという話があった。
    return 1個だけという話があるのはなぜか
        70s-80s に入り口と出口を1つにするというのがあった。
        今の関数のようなものがなくて入り口も出口もバラバラな時代があった(らしい)。 (cuzic)
        今は気にしなくて良いのでは。

興味を持ったところをちょいちょいと。 retrun は一つ云々ってのは構造化定理を曲解した連中が強要したとか云う話を聞いた覚えが (要出典)。あと、function があっても値を返す return 文がなかった Pascal 辺りの影響な気も(要出典)。

ナイーブソリューションはカタカナ書きにしてるからわからなくて、 英語の意味そのままで考えれば分かるんじゃなかろか。 naïveの意味 - 英和辞典 Weblio辞書 の、たぶんこの辺。 〈考えなど〉単純な,甘い,素朴な.

良い名前のサンプルはあるといいかな。 そいやコミケで悪いサンプル(でもなかったか)を集めた同人誌を見た覚えがw

■_ 今日の信頼度成長曲線

【信頼度成長曲線again】前段階で後のカーブが予測できるのか: ソフトウェア開発品質・生産性ななめ読み

信頼度成長曲線で、曲線の立ち上がりの形がS字であるとか指数型であるとか、使用するモデルの形によって
変わり、これが後の累積バグ予測値にも影響していくのであるが、これは現実のプロジェクトに適用するに
当たって正しいことであると考えて良いのであろうか。

理論上は正しいであろう。

しかし、現実のプロジェクトにおいては、曲線の立ち上がり時のテストケースの実施順番次第では、実はカー
ブの形が変わるということはないだろうか。

(略)

「自組織のテスト傾向に合ったカーブを選ぶ」とよく言われる。
しかし、実測データ、特にテスト開始時のバグ立ち上がり時にカーブがフィットすることが本当に正しい将来
予測をするのに必要なのであろうか。

いろいろ資料読んでいて気になることの一つがこれですね。 曲線を描画(というか成長曲線を近似)するのに ゴンペルツやらロジスティックやらレイリーやら指数やら超指数やら 色々あって、一番合うのを選べとかなにそれ。と。 昨日ちょっと書いた統合モデルなんてのもありますが、 それはそれで以下略

Making Software ―エビデンスが変えるソフトウェア開発
Making Software ―エビデンスが変えるソフトウェア開発
の内容を絡めて書こうと思ったけど時間的余裕ががが (書き写すのが面倒らしい)。

■_

みずしまさんの誕生日が近いそうです

wishlist 見てたらこれが気になった。 いやまあ Isabell は使ったこともないんですけど。 Amazon.co.jp: Isabelle/Hol: A Proof Assistant for Higher-Order Logic (Lecture Notes in Computer Science): Tobias Nipkow,Lawrence C. Paulson,Markus Wenzel: 洋書

■_

■_

ソフトウェア開発で見積もりのための定量化はできないんじゃない? - うさぎ組

2012年10月07日

■_

Nexus 7 あちこちで届いた買った見たの報告が。

■_

星野之宣を語れ Part15 

278 名無しんぼ@お腹いっぱい [sage] 2012/10/07(日) 11:51:24.56 ID:UMH7gAC80 Be:
    「星を継ぐもの」4巻、メッセージカード?が挟まれてるのに今きづいた。
    初版特典か? 

279 名無しんぼ@お腹いっぱい [sage] 2012/10/07(日) 13:09:38.96 ID:8ByVgcVg0 Be:
    >>278
    最近流行のペーパーでしょ。
    俺はわざわざ紀伊國屋で買ったよ。 

9/28発売予定『星を継ぐもの』4巻をお買い上げの方に星野之宣先生描き下ろし紀伊國屋書店限定ペーパーを差し上げます! | 本の「今」がわかる 紀伊國屋書店

ということで、 まだ4巻を買っていなかったこともあったので 紀伊國屋新宿本店に行って買ってきた(ここんところ南店しか行ってなかった)。 が、コミック売り場は「別館」じゃねーか。 しばらく迷ったよ!w

■_ ぽちっとな

関数型プログラミング言語Haskell Part19

919 デフォルトの名無しさん [sage] 2012/09/30(日) 22:36:58.00 ID: Be:
    「ストラウストラップのプログラミング入門」的な本がHaskell(関数型)にも欲しいよな。 

920 デフォルトの名無しさん [sage] 2012/10/02(火) 21:41:35.30 ID: Be:
    関数型言語で例示してるアルゴリズム本がほしい 

921 デフォルトの名無しさん [sage] 2012/10/02(火) 22:11:02.00 ID: Be:
    >>920
    「Pearls of Functional Algorithm Design」
    すばらしい 

925 デフォルトの名無しさん [sage] 2012/10/04(木) 22:04:48.83 ID: Be:
    >>920
    そのものズバリの
    "Algorithms: A Functional Programming Approach"
    はどうですか? 

939 デフォルトの名無しさん [sage] 2012/10/05(金) 13:22:20.43 ID: Be:
    >>925
    これ絶版ですかね (´・ω・`) 

940 デフォルトの名無しさん [sage] 2012/10/06(土) 17:24:41.89 ID: Be:
    >>939
    Amazon UK でまだ売ってる。

    本体は38.99ポンド

    通常発送(遅い方)の場合、
    Amazon UK の設定するレートなら6196円で買える。
    ポンドで買う(カード会社がレート設定する)なら46.97ポンド。 

941 デフォルトの名無しさん [sage] 2012/10/06(土) 23:21:50.32 ID: Be:
    >>925
    読んだこと無いけど米密林では評判悪いね 

942 デフォルトの名無しさん [sage] 2012/10/07(日) 00:48:41.09 ID: Be:
    「Algorithms: A Functional Programming Approach」はアルゴリズムというよりは、
    どちらかというとアルゴリズムを最適化するテクニックを多く学べる感じだ。

    第3章からが本番。
    関数の簡約の様子が詳しく書かれている。
    所々、おまけでヒープの変化の様子を描いた図もある。
    Burstall-Darlington 変換の考え方が学べる。

    第4章のListの節はなかなか面白かった。
    細かな最適化の話なんだが、関数合成時の中間データを省くテクニックや、
    計算速度的には余計な結合演算(++)を取り除いたりするテクニックが学べる。
    (後者はちょっと目から鱗だった)
    あとはTreeやArrayの節でも同じように細かなテクニックが述べられている。

    第5章はスタックやヒープなどのデータ構造を表現する方法が学べる。
    ここは、個人的にはたいして面白くなかったな。
    手続き型言語でよくあるデータ構造を関数型でいかに表現するかという事で、
    まぁ実装方法は予想の範囲を超てなく、驚きがなかったから。
    ただ、分かりやすくはあった。

    第6章はソーティングの話だが、クイックソートよりも
    マージソートやヒープソートの方が関数型では適している事が分かる。
    各アルゴリズムの比較で、効率の計算が出てくるが、ちょっと難しいな。
    なぜその計算になるのかの説明がちょっと簡略気味だ。
    ただ、ここでも簡約の様子が図入りで載っているのは理解に助かった。

    第7章からは、ちょっと飽きてきて、さらっと斜め読みしかしてない。 

943 デフォルトの名無しさん [sage] 2012/10/07(日) 00:51:30.99 ID: Be:
    一方「Pearls of Functional Algorithm Design」の方は、
    各章毎に最初に「**がしたい」という課題が提示され、
    その問題を解決するアルゴリズムをチープなものからハイレベルなものへと
    徐々に進化させながら解説する本だ。

    各章で、たいていは最初に "specification" と言って、
    その問題の解を導く関数が持つべき性質が Haskell の文法で示される。
    で、その specification を素直に満たす関数をまず作り、
    そして、どこがなぜ非効率なのかを解説しながら少しずつ改良させていくわけだ。

    ちになみに、タイトルには無いが、こちらも Haskell の本だよ。 

945 デフォルトの名無しさん [sage] 2012/10/07(日) 07:18:23.78 ID: Be:
    >>942,943
    くわしい解説ありがとう! 

946 デフォルトの名無しさん [sage] 2012/10/07(日) 08:45:25.66 ID: Be:
    へーどっちも結構面白そうだな
    おらなんだか欲しくなってきたぞ 


946 じゃないけど、気になったので925の本を買ってみた。 co.uk でも .com でも買えたけど co.ukのが安かったのでそっちで。

あと「こんな本も買ってます」などで出てきたこの辺がなんか気になった Functional Architecture: An Approach for Effective Execution of Functional Programming Languages: Amazon.co.uk: Hong Shen: Books An Introduction to Functional Programming Through Lambda Calculus: Amazon.co.uk: Greg Michaelson: Books

■_

ゲームの進化について - レジデント初期研修用資料 Twitter / snapwith: @Shingi てっか弾幕の作り方にそういうのは昔か ... Twitter / snapwith: 昔のゲームは何よりコンピューティングリソースが足りな ...

■_ 西島カーブ

(信頼度成長曲線に関係して)「西島カーブ」というものがあるというタレコミが。 んで 松田次博 間違いだらけのネットワーク作り - 戦艦大和とプロジェクト管理:ITpro

松田次博 間違いだらけのネットワーク作り - 戦艦大和とプロジェクト管理:ITpro

大和の生産管理、つまりプロジェクト管理がいかに優れていたかは、同じ設計図から建造されたにもかかわ
らず、大和の工数が武蔵の2分の1に過ぎなかったことに表れている。工期も計画より半年早く終わらせた。
ドンブリ勘定で予算は超過し、スケジュールは遅れるのが当たり前だった親方日の丸の艦船建造の常識を覆
すプロジェクトだったのだ。

 それを実現したのがプロジェクト・マネージャーである船殻(船体)主任、西島技術大佐だった。西島大
佐は生産効率を上げるために調達する部品・材料の標準化や船体をいくつかの区画に分割して建造するブロ
ック工法など、様々な工夫や新技術を導入した。それらにもましてプロジェクト管理の成果を高めた最大の
武器は、「西島カーブ」と呼ばれるグラフによる工数管理の“見える化”だ。

(略)

 西島大佐は3万枚もの設計図を調べさせ、大和に使われるリベット(鉄板を接合する鋲(びょう))の予定
総数が609万72本(実際は615万3030本)、溶接の全長が34万7564メートル(実際は34万3422メートル)、水
圧試験の区画数は1682という数値を得た。この3種類の数字をもとに各工場別、各職区別に工数予定曲線であ
る「西島カーブ」を作成した。このグラフ上に毎週ごとの実績値をプロットすると、予定との乖離(かいり)
がはっきりする。実績が予定から外れれば何らかの問題が起こっているということであり、技師はすぐその
原因を調べて対処でき、関連する部門間で相互の日程をどう調整すれば影響を最小限に出来るか検討できる。

なるほど確かに印象としては同じような雰囲気がありますね。 Amazon.co.jp: 戦艦大和誕生〈上〉西島技術大佐の大仕事: 前間 孝則: 本 この本、出た当時買おうかどうしようか悩んだけど上下巻だということもあって 断念したんじゃなかったかなあ。文庫になってたのも知らなかったけどすでに絶版ぽい Amazon.co.jp: 戦艦大和誕生〈上〉西島技術大佐の未公開記録 (講談社プラスアルファ文庫): 前間 孝則: 本

とはいうもののあまり詳しい情報がないですねえ… 祖父・海軍そして大和 大和を生みし者達 八 - 酔漢のくだまき 戦艦大和の技術を、戦後生かしたというのは本当ですか?? - Yahoo!知恵袋 つれづれなる技術屋日記: 「戦艦大和誕生」 「戦艦大和誕生」を読んで: so-on 軍事板初心者質問スレまとめ(FAQ) - 大和型

【世界の軍関係者から見た大和】 - 2ちゃんねるキャッシュ

335:名無し三等兵:2010/05/19(水) 12:57:28 ID:???downup
    大和はアメリカの真似した工学を用いて工期を短縮したけど、同手法は武蔵には用いられなかった。
    軍内のこういう縦割りセクト主義も、他の悲惨な問題の一因だろうな。 

351:名無し三等兵:2010/05/19(水) 18:01:04 ID:???downup
    >>333
    もうそういう運用面とか、艦の性能と関係ない材料でしか大和を叩けなくなってるよなw
    身内を騙したと言うよりは当時の国民が空気読んだって感じだし。



    >>335
    >>大和はアメリカの真似した工学を用いて工期を短縮

    これは具体的に何の事を言ってるの? 

352:名無し三等兵:2010/05/19(水) 18:52:49 ID:???downup
    西島カーブとかのコト言ってるだろうけど、あの工程管理手法はアメリカとかのとは違う
    ちょっとイレギュラーなもので当時としても完成してるわけではないから三菱長崎を責め
    るのはちょっとって気がする

    あと三菱の製造費用が呉より明らかに大きいのは船台建造とか建造中の各種改正工事とか
    いろいろあるから評価難しいよ。 
E2000056.html

        >テイラーとか、それに近い考え方は、戦中の日本にも応用されていたは
        >ずですが、

        これは、豊川海軍工廠が日本能率協会の指導を受けていた云々って話
        のことかなあと思うのですが、それ以外の海軍工廠や民間企業に積極
        的に導入されていた考えかといわれたら、ちょっと「?」というのが
        私の見るところです。ちなみに、私は専門が経営工学(さらに細かく
        言えばオペレーションズリサーチが専攻領域)ですが、上記の話はあ
        くまでも趣味の本から得たものです(^^;)。
        今泉 淳

        生産管理では戦艦大和の艤装等を担当した、西島大佐(大佐じゃなかったかも)がやっていたようです。
        彼はあの巨艦の建造の効率を上げるため、工数と完成度などをグラフにして「西島カーブ」といわれる
        効率曲線をもとに船殻の組立から艤装にいたるまで、「○○が出来てないから、これの組立が出来ない。」
        という状態を極力なくすように心がけて監督したそうです。ちなみに造船の老舗三菱長崎造船所謹製の
        武蔵とくらべ、工程数、組立に要した費用の差が大問題になったそうです。(もちろん大和のほうが少
        ない)他にも彼は巡洋艦等の部品の共用化に努め、補修、修理のために取っておく部品の無駄を減らす
        よう努めたそうです。戦後、彼の生産管理の手法(西島カーブ)はコンピュータでの管理を行う際の基
        本データになったとか。
        kazu

        >「○○が出来てないから、これの組立が出来ない。」

        ORが専門が表看板で、実は私の専門の裏看板(?表裏一体だからどっちが表
        とか裏とかないけど)は生産管理だったりしますが、特に西島さんの名前が
        生産管理の歴史的経緯において登場するという記憶は無いので、今度留意
        しておきます。まあ、私の生産管理って、基本的には確立された方法論に
        対してなので、日本のその手の歴史を追いかけたことはないというのも事
        実ですが。

        ちなみに、上記の引用部分に対して最も有名なOR的手法としては、PERT(
        Program Evaluation and Review Technique)というのがあります。これは、
        作業工程をネットワーク表現し、始点から終点までの最長経路と長さをみ
        つけて、最もネックになる工程をみつけるというものです。コストがから
        むと、CPM(Critical Path Method)というのもあります。

        私は「生産管理史」についてはあまり詳しくないのでこの程度しか書けま
        せんが、西島さんのやっていたことは、もうちょっと抽象的な意味で体系
        化されて、さらにもうちょっと早く定着したら、非常に良い方法論の確立
        につながったのではないかなあと思います。

        今泉 淳

        私はこの分野は門外漢ですが、日本におけるテイラーシステムの導入は意外と早期に見られます。
        テイラーの提唱した科学的管理について、その著書が翻訳出版されたのは1911年、テイラー
        システムの日本初の採用工場は新潟鉄工蒲田工場で1915年のこと。また農商務省が能率化を設
        置して啓蒙活動を開始したのは1920年。その後呉工廠、三菱電機神戸工場、芝浦製作所等での
        テーラーシステムの完全実施が見られたとのことです。戦時中の日本能率協会はこうした戦前から
        の流れの中で広く活動しており、豊川の25mm機銃の飛躍的生産拡大の他、中島飛行機等でも生
        産拡大に貢献しているようですね。
        BUN

        追記。じゃあ、テイラーシステムって一言で何だ?と言われると、んん、と困るんだな。上記の件
        間違ってたらごめんなさい。。
        BUN

        そういう意味じゃ、先駆的に技術導入していたところはあったのかも
        しれませんね(豊川海軍工廠だけって私の知識がある意味で誤り。そう
        いえば中島飛行機で云々ってのは聞いたことあるような気がするこ
        とを思い出した)。

        でも、それが「当たり前」までは至ってなかったのは多分それほど嘘で
        は無いと思うのですよ。それからテーラーの著書というのは「科学的管
        理法」だと思いますが、こいつは未だに訳書が買えます。で、テーラー
        の後の管理技法の発達があって、米国はその流れに乗っているのだと思
        うのですが、日本がそれに追随できたのか、それともテーラーイズムの
        段階で留まっていたのか、それが問題のような気がします。「科学的管
        理法(テーラーの方法)」は1920年代までで、それ以後はインダストリア
        ル・エンジニアリング(IE)の時代なわけです。

        テーラーの科学的管理方法ってのは、私の認識する限り、個々の作業と
        か家業に対する、時間研究(time study)を基礎とする方法論が中心だと
        思ってます(こいつの実習というのを随分やらされたなあ)。要するに、
        テーラーの方法以降の管理手法の発達とそれへの追随度合いの問題かな
        あとも思います(まあ、先進なのは米国なのですが)。

        ってことで、テーラーシステムの件は間違っていても、なくても大丈
        夫ですよ。私も、何かのついでに調べられればと思いますので、留意
        しておきます。私も勉強になりました。> BUNさん

        あ、そういえば、私の出身学科(工業経営学科=経営工学)って、創設が
        昭和15年だったと思うから、その当時日本でもその手の学問の必然性
        が高まりつつあったのかもしれないですね。ということで、その当時
        の先端管理技術やその導入度合いに関しては、折に触れて留意してみ
        たいと思います。
        今泉 淳

        「家業」→「課業」です。

        今泉 淳

        生産管理史などに西島氏の名前がでていないのは当然です。彼は生産管理などを重視し広げようと
        しましたが、広げることは失敗しました。戦時急造型の商船なども彼は早期に多数、安く作れるよ
        う努力しています。そして敗戦後、多くの造船会社から誘いを受けましたがそれをすべて断って、
        広島の実家に引退しました。戦時中の日本のやりかたについて、批判はおろか一切口を開かなかっ
        たそうです。
        kazu

        ↑ようするに自分の仕事場では出来た(行った)、けど日本全体に広めることは出来なかったということです。
        kazu

        上記の件、記述してある文献を入手しました。まだざっとしか目を通し
        ておりませんもののそれなりの感想はあります。が、なかなか興味深い
        話なので、学術的側面からも考察するために文献調査などもしてみよう
        かと思います。
        今泉 淳

ううむ。 彼の生産管理の手法(西島カーブ)はコンピュータでの管理を行う際の基本データになったとか。 だとかこれはこれで面白そうだけど深追いするのも危なそうだなあ 科学的管理法 - Wikipedia

■_

2012年10月06日

■_

あ。日経 Linux 買うの忘れた(しばらく買うつもりらしい)

■_ precisely wrong

信頼度成長曲線から派生した脇道的話題。

オブリガート ~感謝されるテストエンジニアになる~: 「WACATE 2010 夏」参加レポート(その3)――いよいよ成果発表!

 この説明のあと、野中さんはこのようなことをおっしゃいました。

 「どんな議論がなされているかを知る必要はあるけど、論文の内容を鵜呑みにしてはならない。メトリクス
   にのめり込みすぎてはならない」

 ここで野中さんは、経済学者ケインズの言葉を紹介しました。

「正確に誤るよりも、漠然と正しくありたい」

 現場のデータには誤差があります。それを手法に当てはめると、ときには「数学的におかしい」結果が出る
  こともあるでしょう。

 このとき手法にこだわりすぎると、「数学的におかしい」というだけで、有益な情報を切り捨ててしまう
こともありえます。「正確に誤る」とはそういうことです。そうなっては本末転倒もいいところで、本来や
りたいことを見失う恐れがあります。漠然とでも構わないので、役に立ちそうなことを見つけることが大切
だと、野中さんは締めくくりました。

「正確に誤る」ってどゆこと? としばらく悩んでしまったわけで。 野中さんをはじめ、いろんな方が自分なりの解釈を開陳されているようですが どうも納得いかないw

原文はI'd rather be vaguely right than precisely wrong. というらしく、precisely wrong. ならまあそういう訳にもなろう気はするんですが、 その、precisely wrong とはいったい何なのよ。と。 I'd rather be vaguely right than precisely wrong. - Google 検索 狙ったところには行くんだけどそれが的外れ。ということかしらん。

第57回「組織的に取り組むソフトウェア品質マネジメント 」|Prowise Business Forum in Tokyo||日立ソリューションズ Twitter / MakotoNonaka: @MasaoApril @dan_rachi "I'd ... Open ブログ: ◆ 気候シミュレーションの意義 漠然と正しく 陳満咲杜の『為替の真実』。 : Espresso Diary@信州松本 3DBM’s N » Thinking

The Persistent Struggle: Wilkins Micawber and Charles Ponzi are two versions of Homo Economicus. Vaguely right, or precisely wrong?

■_ 第二月曜日を求める

GNU coreutilsのdateコマンドの不思議 - jarp, dateで第2月曜日 - jarp, calの結果からawkで第2月曜日 - jarp, にいんすぱいあされて。

(get-date).getdatetimeformats()

2012/10/06
12/10/06
12/10/6
2012/10/6
12/10/06 (土)
12/10/6 (土)
2012/10/06 (土)
2012-10-06
2012年10月6日
2012年10月06日
2012年10月6日 土曜日
2012年10月06日 土曜日
2012年10月6日 20:29
2012年10月6日 20:29
2012年10月6日 午後 8:29
2012年10月6日 午後 08:29
2012年10月06日 20:29
2012年10月06日 20:29
2012年10月06日 午後 8:29
2012年10月06日 午後 08:29
2012年10月6日 土曜日 20:29
2012年10月6日 土曜日 20:29
2012年10月6日 土曜日 午後 8:29
2012年10月6日 土曜日 午後 08:29
2012年10月06日 土曜日 20:29
2012年10月06日 土曜日 20:29
2012年10月06日 土曜日 午後 8:29
2012年10月06日 土曜日 午後 08:29
2012年10月6日 20:29:51
2012年10月6日 20:29:51
2012年10月6日 午後 8:29:51
2012年10月6日 午後 08:29:51
2012年10月06日 20:29:51
2012年10月06日 20:29:51
2012年10月06日 午後 8:29:51
2012年10月06日 午後 08:29:51
2012年10月6日 土曜日 20:29:51
2012年10月6日 土曜日 20:29:51
2012年10月6日 土曜日 午後 8:29:51
2012年10月6日 土曜日 午後 08:29:51
2012年10月06日 土曜日 20:29:51
2012年10月06日 土曜日 20:29:51
2012年10月06日 土曜日 午後 8:29:51
2012年10月06日 土曜日 午後 08:29:51
2012/10/06 20:29
2012/10/06 20:29
2012/10/06 午後 8:29
2012/10/06 午後 08:29
12/10/06 20:29
12/10/06 20:29
12/10/06 午後 8:29
12/10/06 午後 08:29
12/10/6 20:29
12/10/6 20:29
12/10/6 午後 8:29
12/10/6 午後 08:29
2012/10/6 20:29
2012/10/6 20:29
2012/10/6 午後 8:29
2012/10/6 午後 08:29
12/10/06 (土) 20:29
12/10/06 (土) 20:29
12/10/06 (土) 午後 8:29
12/10/06 (土) 午後 08:29
12/10/6 (土) 20:29
12/10/6 (土) 20:29
12/10/6 (土) 午後 8:29
12/10/6 (土) 午後 08:29
2012/10/06 (土) 20:29
2012/10/06 (土) 20:29
2012/10/06 (土) 午後 8:29
2012/10/06 (土) 午後 08:29
2012-10-06 20:29
2012-10-06 20:29
2012-10-06 午後 8:29
2012-10-06 午後 08:29
2012/10/06 20:29:51
2012/10/06 20:29:51
2012/10/06 午後 8:29:51
2012/10/06 午後 08:29:51
12/10/06 20:29:51
12/10/06 20:29:51
12/10/06 午後 8:29:51
12/10/06 午後 08:29:51
12/10/6 20:29:51
12/10/6 20:29:51
12/10/6 午後 8:29:51
12/10/6 午後 08:29:51
2012/10/6 20:29:51
2012/10/6 20:29:51
2012/10/6 午後 8:29:51
2012/10/6 午後 08:29:51
12/10/06 (土) 20:29:51
12/10/06 (土) 20:29:51
12/10/06 (土) 午後 8:29:51
12/10/06 (土) 午後 08:29:51
12/10/6 (土) 20:29:51
12/10/6 (土) 20:29:51
12/10/6 (土) 午後 8:29:51
12/10/6 (土) 午後 08:29:51
2012/10/06 (土) 20:29:51
2012/10/06 (土) 20:29:51
2012/10/06 (土) 午後 8:29:51
2012/10/06 (土) 午後 08:29:51
2012-10-06 20:29:51
2012-10-06 20:29:51
2012-10-06 午後 8:29:51
2012-10-06 午後 08:29:51
10月6日
10月6日
2012-10-06T20:29:51.5216000+09:00
2012-10-06T20:29:51.5216000+09:00
Sat, 06 Oct 2012 20:29:51 GMT
Sat, 06 Oct 2012 20:29:51 GMT
2012-10-06T20:29:51
20:29
20:29
午後 8:29
午後 08:29
20:29:51
20:29:51
午後 8:29:51
午後 08:29:51
2012-10-06 20:29:51Z
2012年10月6日 11:29:51
2012年10月6日 11:29:51
2012年10月6日 午前 11:29:51
2012年10月6日 午前 11:29:51
2012年10月06日 11:29:51
2012年10月06日 11:29:51
2012年10月06日 午前 11:29:51
2012年10月06日 午前 11:29:51
2012年10月6日 土曜日 11:29:51
2012年10月6日 土曜日 11:29:51
2012年10月6日 土曜日 午前 11:29:51
2012年10月6日 土曜日 午前 11:29:51
2012年10月06日 土曜日 11:29:51
2012年10月06日 土曜日 11:29:51
2012年10月06日 土曜日 午前 11:29:51
2012年10月06日 土曜日 午前 11:29:51
2012年10月
2012年10月

なんかフォーマットがたくさんあった。 えいやでこの表示順を index 番号とみなしてみると

PS >l;(get-date).getdatetimeformats()[6]
2012/10/06 (土)

お、それっぽい。 んが、やっぱり書式指定する手段はあるらしくこんなかんじ。 One-Liner: GetDateTimeFormats - Lessons Learned - Site Home - MSDN Blogs Formatting dates in different cultures - Shay Levy 標準の日付と時刻の書式指定文字列

PS > (get-date).toString('yyyy/MM/dd ddd')
2012/10/06 土

そしてこうなった。

PS > foreach ($d in 8..14) {$x = get-date -day $d; if ($x.dayofweek -eq 1) {$x.tostring('yyyy/MM/dd ddd')}}
2012/10/08 月

いやまあ年、月、曜日はいらないっちゃいらないんだけど。

ここまでやって飽きたので、年、月、曜日を指定できるようにとかはやらない。

■_ めも

いけね。論文 DL した URL どこだ

  新統合モデル

  dy/dt = β/γ N (y/N)^η {1-(y/N)^γ}

  N     ソフトウェアに含まれる総欠陥数
  y     時刻 t までの累積検出欠陥数
  β     欠陥検出速度
  ηとγ それぞれある時点までに検出した総欠陥数に対する比率を表すパラメータ
  

論文読んでもよくわからんし。

■_

■_

リージョン選択して、awk にパイプ経由で食わせて…と思ったが、 区切りが空白と改行どちらもありうるのをどうにかしないととっとと

2012年10月05日

■_

夕食後暫く何もできなかった。 そのため今日の日記は書きたかったことがほとんどまともに書けていなかったりする。

■_

Do You Really Want to be Doing This When You're 50? Do You Really Want to be Doing this When You're 50? : programming The Codist Yes I Still Want To Be Doing This at 56 Yes I Still Want To Be Doing This at 56 : programming

■_

■_ 「Model」と「Curve」

ソフトウェア信頼性の基礎という本がありまして。
ソフトウェア信頼性の基礎 -モデリングアプローチ-
ソフトウェア信頼性の基礎 -モデリングアプローチ-

5.4 統計的データ解析モデル

日本では従来より、ソフトウェアの品質・信頼性評価のために、ソフトウェア開発のテスト工程に
おいて発見された総フォールト数がS字形成成長曲線(図5.5参照)を示すとして、テスト工程に
おける不確定要因を考慮しない決定論的方法がとられてきた。これは、ハザードレートモデルや
NHPPモデルが、その不確定要因をハザードレートや計数過程により把握するのに対して、
S字形成長曲線を示すフォールト発見データに直接傾向曲線をあてはめて統計解析を行うものである。

代表的な傾向曲線としては、需要傾向、経済成長、将来の人口などの予測に用いられている
ロジスティック(logistic)曲線やゴンペルツ(Gompertz)曲線がよく採用されている[47,48]。
各曲線の収束値をソフトウェア内に潜在する総フォールト数として、これを回帰分析により
推定することが主目的となる。

  

ここで言及されているのがこれ。 [47] 菅野文友 ソフトウェア・エンジニアリング 日科技連出版社 1979 [48] 三觜武 ソフトウェアの品質評価法 日科技連出版社 1981 これより前にこの種の曲線の使用実績があるかどうかはまだわかりませんが、 結構遡れそうな気はします。

で、ちょっと気になったのは

信頼度成長曲線 - Wikipedia

信頼度成長曲線(しんらいどせいちょうきょくせん 英:Software Reliability Growth Curve)とは、
横軸に日付、テスト時間、またはテストケース数、縦軸に累積バグ発見数をとったグラフ。S字の成
長曲線を描くことが多い。

プロジェクトの進捗状態の確認などに用いる。

決定論的モデルとして、最小二乗法でゴンペルツ曲線やロジスティック曲線に近似したり、確率モデ
ルとして、非同次ポアソン過程モデルなどで表したりすることにより、現在の状況から今後の予想を
立て、テスト進捗管理、バグ収束率の予測、残バグ数の予測などに用いることもある。

日本語版Wikipediaにはこのように「信頼度成長曲線」の項目がありますが、 英語版にはありませんし、ソフトウェアの信頼性についての英文の論文やら見てても 「Software Reliability Growth Curve」ってほとんど見かけないのですよね。 あっても日本語論文の英訳だったりとか。 じゃあ向こうにはそういう考え方がないのかというと、 そうではなく、 「Software Reliability Growth Model」で検索すると結構見つかります。 software reliability growth model - Google 検索 じゃあこの、curve と model の違いはどこから来たのか? というのはまだわかりません。

■_

Reliability Growth Models Criticized

■_ 「統合モデル」

これは、過去の類似プロジェクトなどのデータも要らず、 コード規模等から潜在バグ数の推測をあらかじめ行う必要もないって代物らしいのですが 正直よくわからない。

信頼度成長曲線作成ツール | FAQ | ソフト工学センター・構造計画研究所

1 	: 	ソフトウェア信頼度成長曲線モデルにはどのようなものがありますか?
従来の
 ・ゴンペルツ曲線
 ・ロジスティック曲線
 ・指数型モデル
 ・修正指数型モデル
 ・遅延S字型モデル
 ・習熟S字型モデル
などのほか、東海大学古山恒夫教授考案の統合モデルがあります。


2 	: 	SRGMで採用している信頼度成長曲線モデルは?
統合モデルを採用しています。


3 	: 	統合モデルと従来型モデル(ゴンベルツ曲線・指数型モデルなど)との相違点は?
信頼度成長曲線を描く場合、ゴンベルツ曲線や指数型モデルなど従来型モデルはパラメータを与えた上で描画しますが、統合モデルはバグ発生の状況(バグの出方)からパラメータを自動計算します。従ってパラメータ決めに悩む必要がなくなります。
バグ発生の状況(バグの出方)は多様であり、従来型モデルで様々なバグ発生パターンに対応することには無理があります。一方統合モデルはバグの発生状況からパラメータを自動計算しており、バグの発生パターンにより従来型の何れかのモデルと近似します。従って統合モデルは従来型モデルを包含したモデルとも言えます。

CiNii Articles 著者検索 - 古山 恒夫 CiNii 論文 -  ソフトウェア信頼度成長曲線に関する統合モデルと有効性の検証 CiNii 論文 -  ソフトウェア信頼度成長モデルにおける新しい統合モデルの厳密解と有効性の検証(一般セッション(1)) CiNii 論文 -  ソフトウェア信頼度成長モデルにおける統合モデルの曲線の形状について(開発プロセス(一般セッション))

■_

調べていくと色々ありそうだなあ

2012年10月04日

■_

今回のカレチもありがちっちゃーありがちだけど好きな話ではある。

■_

プログラムは「芸術品」ではないし、 プログラミングも「アート」(カタカナ書きにしてるとこポイント) だとか「ゲージュツ」などと呼ばれるようなものではない。 と思ってます。 じゃあなに? と問われて明確な答えを持ってるわけでもないんですけどね。 「工業製品」とも違うよねえ。

などということを、こういうものを読みながら考えてたりするわけです。 情報処理推進機構:ソフトウェアエンジニアリング

で、そういった考えごとはまた Inemuri nezumi diary(06-04[長年日記]) Inemuri nezumi diary(03-08[長年日記]) で書かれているような方向にもいったりするわけです (いけがみさん暫く見かけてないなあ)。

コード書かずになにやってんでしょーねアタクシ。

■_

なんやら YAPC::Asia なる文字列が

YAPC::Asia 2012 | 6guts

YAPC::Asia 2012
Posted on October 3, 2012

Three years ago I paid a visit to Japan to attend YAPC::Asia. It was also my first time in Japan,
and so in addition to a very enjoyable and well attended Perl conference, I got to enjoy the
incredible Japanese cities, the beautiful nature, great food (and this is coming from somebody who
can't eat fish and seafood – yes, there are still plenty of nice things to eat) and some of the
most polite and pleasant people I've come across anywhere. I'm still a bit mystified what made me
leave coming back again a whole three years – but it goes without saying that I'm very glad I did.
Japan is as awesome as I remembered. :-)

Naturally, Perl 6 has come a long way since I was last here. Last time, I talked about Perl 6 at
the level of interesting snippets of code that you could run that solved small problems. These
days, with the language having a growing ecosystem of modules and compilers capable of running
them, it felt natural to focus on that. Thus, my talk was Exploring Perl 6 Through Its Modules.
(ry

あー、あのセッションの人だったのかー。

I paid a visit to Japan to attend YAPC::Asia. こういう言い回しあるのねえ。>paid a visit to ~

■_

■_

Inemuri nezumi diary(06-04[長年日記])

川村氏の資料では「信頼度成長曲線」の出典を明らかにしておられないので、独自の定義なのか、それとも
既存の定義なのか、私にはわかりません(たとえば、Gompertz functionに似た図がスライドに現れますが、
もしも Gompertz 曲線であると主張するならば、当然、(経験に頼らない)根拠が必要です)。しかし、少な
くともそのような概念を最初に言い出したのは、私が知る限り Donald Ervin Knuth の TeX の開発に伴うバ
グとその修正の歴史を曲線にし、どのようにバグが減少していったかを述べた The errors of \TeX -
Revised 28 November 1988だと思われる(が、川村氏の導いた結論と Knuth 先生の結論はもちろん違う)。

なんか半ば偶然にこの辺の話に関わる発見(は大げさ)があったので それについて書く。たぶん。

2012年10月03日

■_

特撮博物館あと数日しかない(3連休は混むよねえ…)

■_

CORDIC でしたとさ CORDIC - Wikipedia, the free encyclopedia CORDIC

■_

http://www.jasst.jp/archives/jasst10e/pdf/D4.pdf のはなし。 データの出所が判明しました。 なんのことはないスライド二枚目で紹介されている本でした。 これね 演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法
演習で学ぶソフトウエアメトリクスの基礎 ソフトウエアの測定と見積もりの正しい作法 んで原著はこちら。なんかえらく値段が違うな Software Measurement and Estimation: A Practical Approach (Quantitative Software Engineering Series)
Software Measurement and Estimation: A Practical Approach (Quantitative Software Engineering Series)

さて、スライド69枚目のデータはこうなってます。


   週        1      2      3      4      5      6      7      8      9
欠陥発見数  20     41     48     52     62     59     52     44     33

K        510.1  446.9  478.9  516.4  511.1  505.0  494.8  494.5  463.2
K の平均 495.6
 標準偏差 σ=29.3
  

が。 このデータの元らしい(というか翻訳者の一人があの先生だったりした) 本を見ると微妙に数字が違う。 Software Measurement and Estimation: A Practical Approach - Linda M. Laird, M. Carol Brennan - Google ブックス

Week         1      2      3      4      5      6      7      8      9
Defects     20     33     48     60     62     59     52     44     33
found

K        510.1  446.9  478.9  516.4  511.1  505.0  494.8  494.5  463.2
Mean     491.2 ← K の平均
SD       22.37972 ← 標準偏差

K の値は、下のものでないとつじつまが合いません (2週目と4週目に食い違い)。t(2) が41のとき K_2 は 446.9にはならないし、 t(4) が52 のときK_4は 516.4にはなりません。

その K の値なんですが 68枚目のデータの数字をそのまま使っちゃってるみたいなんですね。 こっちは原著と同じでした。


     週      1    2    3    4    5    6    7    8    9
欠陥発見数  20   41   48   52   62   59   52   44   33
  Week       1    2    3    4    5    6    7    8    9
Defects     20   41   48   52   62   59   52   44   33
found
  

R でごにょごにょしてみるとこう。

> D<-matrix(c(1:9, 20,41,48,52,62,59,52,44,33), nrow=9)
> D
      [,1] [,2]
 [1,]    1   20
 [2,]    2   41
 [3,]    3   48
 [4,]    4   52
 [5,]    5   62
 [6,]    6   59
 [7,]    7   52
 [8,]    8   44
 [9,]    9   33
> A<-apply(D,1, function(x) 25/x[1]*exp(x[1]**2/50)*x[2])
> A
[1] 510.1007 555.1846 478.8869 447.5665 511.1036 505.0482 494.8276 494.5380 463.1999 ←2番目と4番目が違う
> mean(A)
[1] 495.6062 ← スライドと同じ平均値
> sd(A)
[1] 31.08105 ← 不偏分散 スライドとは違う
> sqrt(sum((A-mean(A))**2)/NROW(A))
[1] 29.3035 ← 標本分散 スライドと同じ
> sqrt(sum((A-mean(A))**2)/(NROW(A)-1))
[1] 31.08105
> D[2,2]
[1] 41
> D[2,2]=33
> D[4,2]
[1] 52
> D[4,2]=60
> D
      [,1] [,2]
 [1,]    1   20
 [2,]    2   33 ←ここと
 [3,]    3   48
 [4,]    4   60 ←ここを「正しい」値にしてみる
 [5,]    5   62
 [6,]    6   59
 [7,]    7   52
 [8,]    8   44
 [9,]    9   33
> B<-apply(D,1, function(x) 25/x[1]*exp(x[1]**2/50)*x[2])
> B
[1] 510.1007 446.8559 478.8869 516.4229 511.1036 505.0482 494.8276 494.5380 463.1999
> mean(B)
[1] 491.2204
> sd(B) ← 不偏分散 
[1] 23.73727
> sqrt(sum((B-mean(B))**2)/NROW(B))
[1] 22.37972 ← 原著と同じ
> sqrt(sum((B-mean(B))**2)/(NROW(B)-1))
[1] 23.73727 ← sd(B)と同一結果

K の平均 495.6 標準偏差 σ=29.3510.1 446.9 478.9 516.4 511.1 505.0 494.8 494.5 463.2 の食い違いは単なる転記ミスなんでしょか。

それから、 スライドでやってる(説明している)ことと 原著の記述にも食い違いがあります。 実際のセッションでは口頭の説明で何かあったかもしれませんが、

Software Measurement and Estimation: A Practical Approach - Linda M. Laird, M. Carol Brennan - Google ブックス

7.4.1.1 Rayleigh Models
The equations for the basic Rayleigh curves, where t is time, c is constant, and K is the total
number of defects (e.g., area under the curve), are

  f(t) = K * 2(t/c^2)e^-(t/c)^2 and F(t) = K(1 - e^-(t/c)2)

Interestingly, c = √tm, where tm is the time t at which f(t) is maximum. Therefor,

     F(t) = K [1 - e^-(1/2tm^2)^t2]

     f(t) = K [(1/tm)2te^-(1/2tm^2)t^2]

The ratio of defects that should appear by time tm is defined as F(tm)/K, which is
[1 - exp(-0.5)] or ~.4. Therefor, ~40% of the defects should appear by time tm.

There are multiple ways to use these equations to predict arrival rates and total
number of defects. There are many commercially avaialble tools that will do
these calculations in a statistically valid manner. A few simple methods which
you can calculate yourself and that can get you started are demonstrated next.

Method 1: Predicing the Distributions -- An extremely Easy Method
Give that you have defect arrival data, and the curve has achieved its maximum at time
tm (e.g., the inflection point), you can calculate f(t), assuming the Rayleigh distribution.
The simplest method is to use the patter that ~40% of the total defects
have appeared by tm. This is a crude calculation but it is a place start.

For example, assume you have the following data for arrival rates for defects:

Week      1    2    3    4    5    6    7    8    9
Defects  20   41   48   52   62   59   52   44   33
found

tm is week 5. Since ~40% of the defects appear by tm, and the sum from week 1
through week 5 of defects is 223, then the simple calculation for the total number
of defects is 223 * (100/40) = ~557.

You can determin f(t) once you have K and tm.

Continuing the example and substituing in K = 557 and tm = 5,

     f(t) = 557(t/25)e^(-t^2/50) = 22.3te^(-t2/50)
     F(t) = 557(1 - e^-(t^2/50)

Method 2:
Predicting the Distributions -- A Littele More Complex Method
You can solve f(t) by using tm and one or more data points to solve for K and f(t). The
simplest way is to tale just one data point; the easist point to use is f(1) = 20.
Substituting in tm = 5, we have

     20 = K(1/25)e^-1/50
      K = 20 * 25 * e^1/50
      K = 510
So

    f(t) = 510(t/25)e^-t^2/50 = 20.4te^-t2/50
    F(t) = 510(1 - e^-t^2/50)

We know that at least three points are needed to estimate these parameters using
nonlinear regression analysis, and that further statistical tests (such as standard
error of estimate and proportion of variance) are necessary for these parameters to
be considered statistically valid. In the case where high precision is important, use
a statistical package or one of the reliability tools to calculate the curve of best fit.

As an interim and easier step, we can calculate K for all values of f(t), assuming
tm = 5 and then calculate the mean and standard deviation. That is,
K = [25f(t)e^-t^2/50]/t. These calculations are easily performed with a spreadsheet.
The mean of for K is 491 with standard deviation of 22.3.


Week         1      2      3      4      5      6      7      8      9
Defects     20     33     48     60     62     59     52     44     33
found

K        510.1  446.9  478.9  516.4  511.1  505.0  494.8  494.5  463.2
Mean     491.2
SD       22.37972

Note that these calculations are sensitive to tm and although they are not completely
vaild in a statistical sence, they give the statistically challenged parctitioner a
relatively easy method for calculating the defect detection distribution functions,
with some initinal contorl limits. Considering the precision of the typical data, they
are reasonable. Figure 7.8 is a graph that shows f(t) for K = 510, 491, 557. All
there curves are close to the actual data and very similar to each other. From an
"eyeball" perspective, K = 491 looks the best, as we would expect.

Method 3: Predicting the Arrival Rates Given Total Number of Defetcts and Schedule
Once you predict the total number of defects expected over the life of
a project, you can use the Rayleigh curves to predict the number of defects expected
during any time period by using the equations below. Your can also compare projected
defects with actual defects found to detemine project performance.

T_d is the total duraion of the project, at which time 95% of all defects have been
foudn. K is the total number of faults expected for the lifetime of the delivery.

Then the number of defects for each time period t is

  f(t) = (6K/(T_d^2))te-3(t/T_d)^2 [2]

For example, you know that past, similar project have had a defect density of
10.53 defect per KLOC and you have predicted that this project will be 100
KLOC. You also have a reasonable expectation, based on process improvements,
that you expect to have 5% fewer defects.  Therefore, you project that the total
number of defects for this project will be 10.53 * 100 * 0.95 = 1000.

Given a total duration of the project of 26 weeks, and a total expected number of
faults of 1000, then the expected distribution of faults would be as depicted in
Figure 7.9.

Based on the distribution in your data from prior projects, you can add in control
limits. You may want to use 2 SD, which will give you a 95% confidence range of
performance.

2) The 95% number here is used as a reasonable target for delivery. The equations are
derived from F(T_d)/K = 0.95 Another percentage would result in slightly different
constants in the equations.

If you do not have data from piror projects, you can still project overall defect
densities in a number of ways, as discussed later in this chapeter, and use the same
technique to project arrival rates.

The Rayleigh model is used in a number of tools, which you can find on the
Internet. Some of the more notable ones are:

・SPSS (SPSS Corporation)
・SAS (SAS Corporation)
・SLIM (Quantinative Software Management Corporation)
・STEER (IBM Corporation)

  

原著から例の意味のよくわからん平均や標準偏差を求めてどうこうしてますが Note that these calculations are sensitive to tm and although they are not completely vaild in a statistical sence, と注意書きが。

しかし原著のこれも 一つ目と二つめのテーブルで値が違うのまずいんじゃあ? 手法だけ変えて…って話だよねえ Figure 7.8 is a graph that shows f(t) for K = 510, 491, 557. All there curves are close to the actual data and very similar to each other. のように比較しているわけだし。

なんというかマサカリ投げつける気も失せてきた…

■_

2012年10月02日

■_

「ソフトウェア工学」で云々。 書こうと思ったがまとまらないのでボツ。

たぶん明日またレイリー分布ネタ(というかあの先生ネタ)書きます。

■_

X68000 float.x float2.x codec

ソフトウェアで↑な数値演算するのに、単純にマクローリン展開(テイラー展開)やら するよりも高速な手法ってのがあって、それはX68000の数値演算ドライバの float.2.xで使われて云々てのを書こうと思ったんだけど 肝心な手法の名前を思い出せない○| ̄|_ codec だったと思うんだけどなあ。 ビデオエンコーディングやらのコデックばっかりひっかかりやがる

■_

いいなあ。

■_

■_

げしょ。

2012年10月01日

■_

やるきがまったくございません(会社でなんかあったらしい)

■_

自分が慣れてないせいもあるんだろうけど、 kindle であっち行きこっち行きという読み方がちょっとしづらいのが不満 (一度目次に戻って…とか。ブックマーク活用すりゃあいいんだろか)

Gauche > Archives > 2012/09/29
2012/09/29 04:53:21 UTC shiro

そういえば、同じ文書の複数箇所を同時に参照したい、っていうのは本に限らずものすごく良くあることで、
私はEmacsでも頻繁に複数バッファで同じファイルの複数箇所を見るってことをやるんだけど、
なんかそういう機能が使いやすいエディタやドキュメントビューワってあまり無い印象が。知らないだけかなあ。

2012/09/29 08:42:10 UTC とおる。

そうですよね。タブを切り替えて複数の PDF を同時に開ける iPad アプリはあるんですけど。PDF の場合、
それを実現するのが「しおり」なんだと思うんですが、使い勝手のいいインターフェイスがないんですよね。

■_ ぼのぼの名言集

名言集とな

【いぢめる?】ぼのぼの【いぢめないよぉ】

521 □□□□(ネーム無し) [] 2012/08/24(金) 20:26:45.64 ID: Be:
    発売日は未定だが、『ぼのぼの名言集』が出るらしい。オレも買おうかなwwwww
    http://www.bonobono.jp/archives/2012/08/24/ 

522 □□□□(ネーム無し) [sage] 2012/08/24(金) 23:51:05.29 ID: Be:
    >>521
    ぼのぼのの名言って話の中で活きる物であって
    そこだけ抜粋しても伝わらなさそうなのが多いような
    多分買うけどww 

523 □□□□(ネーム無し) [sage] 2012/08/25(土) 09:23:31.60 ID: Be:
    >ぼのぼのの名言って話の中で活きる物であって
    >そこだけ抜粋しても伝わらなさそうなのが多いような

    それは名言ではない。一部分だけ切り取って見てみても
    様々な含蓄を感じられるのが名言。 

ぼのねっと

死神ラッコ編のアレとかアレとかきぼー。 アライグマのオヤジの「青い空もキライなら~」はどの辺だっけ。

■_

■_

リスト作るのも面倒(ry

■_ ダイ・ハード

Why I think Rust is the "language of the future" for systems programming | Hacker News

「die-hard C guy」という言い回しがちょっと気に入ったというそれだけの話です :)

Why I think Rust is the "language of the future" for systems programming | Hacker News

I'm a die-hard C guy. My motto for years has been "you can pry pointers and address spaces
from my cold, dead hands."

Of the new languages I've seen lately, Rust is my favorite. I love how it gives me better ways to
express things I actually want to say without imposing GC on me.

But even so, I can't see myself actually using it for much, because writing in a language other
than C means buying in to that language's runtime. Buying into one language's runtime means that
your code won't play nice with other languages' runtimes.

If I write a library in Rust, how can I expose my types and algorithms to Ruby, Python, Lua, etc?
How will Rust Tasks play with Python threads? What if I use a Rust Pipe to send a Python value
between tasks? How do I keep Rust from doing a GC pass while I'm holding the Python GIL? etc. etc.

Programming Languages by their nature want to be at the center of your world. If you buy into their
abstractions, everything works nicely. But if you try to mash two of them together in a single
process, you start to suffer from the fact that their abstractions overlap and don't interoperate
at all.

If you're only writing an application (ie. not a library) and never want to embed other languages
into your application, then this might be ok. But I'm more interested in writing shared functionality
that is useful across languages. Why should the whole stack of parsers, crypto, compression, etc.
have to be written separately in each language? Life is too short to do some great work that is only
usable by one language community -- computing is so big and changes so much that one-language-only 
functionality is at best limiting your market and at worst dooming your code to obsolescence when
the next big language comes around.

So as much as I instinctively like Rust, I think I'll be sticking with C.

My motto for years has been "you can pry pointers and address spaces from my cold, dead hands." の、you can から後の文の意味が良く取れない。 from my cold, dead hands とかナニ?


一つ前へ 2012年9月(下旬)
一つ後へ 2012年10月(中旬)

ホームへ


リンクはご自由にどうぞ

メールの宛先はこちらkbk AT kt DOT rim DOT or DOT jp