プロジェクトの見積もりは、単純に作業期間を積み上げたものより、長くなりがちの証明

昨日の講義は、たぶんこういう意味だよな・・・

いま、Ａ，Ｂ，Ｃ，Ｄというプロセスがあったとして

Ａ：平均４日の正規分布
Ｂ：平均３日の正規分布
Ｃ：平均２日の正規分布
Ｄ：平均３日の正規分布

に従ったと仮定したとき、

もし、Ａ→Ｂ→Ｃ→Ｄと、順番に仕事をするなら、期待値は
４＋３＋２＋３＝１２日
となる。この意味は、何百回もやったら、だいたい１２日くらいになり、
　１２日よりも速く終わる回数と
　１２日より遅く終わる回数が
同じくらいになるという意味だと言うことに、注目しておこう。

---

もし、ここでＢとＣが並行でできるとしよう。
パス１：Ａ→Ｂ→Ｄは、４＋３＋３＝１０日
パス２：Ａ→Ｃ→Ｄは、４＋２＋３＝９日
となるので、パス１のほうがクリティカルパスとなり、
１０日かかる・・・といいたいところだが、そうはならない。

たとえば、これを１００回行ったとしたら、
パス１が、１０日より多くなるのが５０回、
パス１が、１０日より少ないのが、５０回ということになる。

ここで、パス１が１０日より少なかった回について考えよう。
たとえば、パス１が９日だったとする。
このとき（たしかに標準偏差にもよるが）、パス２が１１日になることもありえるだろう。
この場合、パス２がクリティカルパスとなり、かかった日数は１１日になる。

つまり、１０日を越えるのは、

パス１が１０日をこえる５０％と、
パス１が１０日以下で、パス２が１０日をこえるＸ％（かりにＸ＝１０％としますか）の、
５０＋１０＝６０％となる。

ということは、１０日以下の日は、１００－６０＝４０％となり、
１０日より長引くほうに傾く

---

このことより、
作業を並行に行うことができる場合、

プロジェクトの見積もりは、
単純に作業期間を積み上げたときの、
クリティカルパスの期間としたものより、
長くなりがちといえる。

ビッグデータって、クラウドより、テラデータ使ったほうがいいような気がしてきた・・・

　ビッグデータっていうと、ソリューションとして、クラウドを使ったり、Hadoopにもって行きたがる、企業とか、開発者がいるけど、どーなんでしょうね？
　クラウドにおいてしまうと、通信や処理スピードが意外と遅いとかいうことないのかな・・

　むしろ、テラデータとかでデータウェアハウスを自社で構築しちゃったほうが、いいんじゃないかなあ。外部と通信しなくて済む分。
　ほんとうにビッグデータが発生する企業において、億の金が必要ということが重要なことなんじゃなくって、その投資をして、見合うだけのリターンがあるかどうかが重要なんじゃないかな。たとえば、１００億儲かるなら、１０億だしてもいいけど、１銭も儲からないならフリーソフトでもやりたくないみたいな・・


　そういう観点でみると、ここの話は、おもしろいかも・・・

「20年以上ビッグデータに取り組んできた」--DWH専業の意地を見せるテラデータの底力（後編）
http://japan.zdnet.com/cio/analysis/35005947/

Rでお絵かき その１ グラフおえかき

　統計のフリーソフトＲを使って、グラフを作成させ、それをファイルに書き出すことを考える。

　こうすれば、あとは、

Java から R の機能を呼び出し (Rserve を使用)
http://www.db.is.kyushu-u.ac.jp/rinkou/r/rserve.html

を使えば、Javaのプログラムから、統計処理をしたグラフなんかをじゃんじゃん出せることになる。

　とくに、Javaで、ＴｅＸファイルを書き出し、それをＰＤＦかなんかにすれば、統計処理した結果を、うるわしい帳票で出力できそうだ・・・

と、野望は大きいのだが、今日はその第一歩、グラフのお絵かきをする。

---

■今日の課題

　こんなグラフを書き出します。

つまり、sinカーブを０から１８０度（pi）まで書いて、
そこに１０個、ランダムに点を打ちます。

---

■plotすると・・・

つまり、sinカーブを０から１８０度（pi）まで書いて、
（その間に１０００個の点を配置して、plotのとき、type="l"にしてつなぐ）
単純にプロットしてみましょう。

delta<- 1000 
en.x<-seq(0,pi,length=delta) 
en.y<-sin(seq(0,pi,length=delta)) 
plot(en.x,en.y,type="l",xlim=c(0,pi),ylim=c(0,1))
polygon(c(en.x,rev(en.x)),c(rep(0,delta),rev(en.y)),col="green") 

この結果が、下の通り。

なんか、浮いちゃって、かっこ悪い。

---

■軸をひく

そこで、ビシッと軸につくように、

１．plotのときに軸を書かない
２．axisで軸を引く
　　　→横軸は、３で止まり、piまでひかれないので、線を引きなおしている
３．segmentsで線を引く

っていうことをしたのが、こんな感じ

delta<- 1000 
en.x<-seq(0,pi,length=delta) 
en.y<-sin(seq(0,pi,length=delta)) 
plot(en.x,en.y,type="l",xlim=c(0,pi),ylim=c(0,1))
polygon(c(en.x,rev(en.x)),c(rep(0,delta),rev(en.y)),col="green") 


axis(1,pos=0,at=seq(0,pi,by=0.6),adj=0,col=1) 

segments(0,0,pi,0) 

axis(2,pos=0,at=seq(0,1,by=0.2),adj=0,las=2,col=1) 

segments(0,1,pi,1) 

segments(pi,0,pi,1) 

polygon(c(en.x,rev(en.x)),c(rep(0,delta),rev(en.y)),col="green") 

---

■乱数を発生させて、図に載せる

一様乱数を発生させるのは、runif(n,0,pi)でいい。（nは個数。今回は0～piまで）
で、問題は、これを図に載せるために、
par(new=T)
をしている。これを書かないと、乱数だけ別のグラフになってしまう。

この乱数部分は、こんなかんじ。

n<-10 

data <- cbind(runif(n,0,pi),runif(n)) 

par(new=T) 

plot(data,xlim=c(0,pi),ylim=c(0,1),pch=20,axes=F,ann=F,col="blue")  

---

今回はここまで。