ページランクを正しく求める方法では、反復計算の初期値によらずただ一つのページランク（固有ベクトル）に収束するのだから、「頂点の削除」を扱わないのならば、
・元々あった頂点 ⇒ 値を変更しない
・新たに追加された頂点 ⇒ 初期値0 (id=0の頂点のみ初期値1)
で計算すれば、べき乗法で、ページランクの総和が1になるやり方でも、正しくページランクが求まるはず。
ただし、総和が1になるやり方では、ランダムジャンプの遷移によるページランクの値が
(1-c)/n となり、このnの値が変わるので、計算が収束した頂点も結局計算しなおす必要が生じるかもしれない。
そもそも、どこにもリンクしていないページの存在を正しく扱うと、そのページからは必ずランダムジャンプを行うように扱う必要が生じるため、
そのような頂点が発生すると、計算が収束した頂点のページランクにも影響が生じるので結局計算しなおす必要があるのかも？
(どこにもリンクしていない頂点が少ない(and,or)ページランクが小さい場合であれば、それによるページランクへの影響は多くの場合スレッショルド未満かもしれないが)
収束判定 (総和が1の場合) : abs(PR_new-PR_old)/PR_old < threashold (where threashold = 0.001)
Adaptive PageRankでのやり方
(20110228 Mon.)
Incremental PageRankについて、前回の全体ミーティングで、前のスライドのスケールのやり方では各ページのページランクの総和を取っても 1 にならない、と雁瀬君から指摘を受けましたが、その後、雁瀬君との議論により、総和が 1 になるようなスケールの仕方（というか、直接的にはスケールしなくて良い方法）を見つけました。
まず、本来のページランクでは総和が 1 になるようになっていますが、ここでは総和が n (頂点数) となるように全体を拡大します。
ΣVi = n
また、グラフの構造の変化として、辺の追加と削除、頂点の追加のみを扱い、「頂点の削除」は扱わないものとします。
Incremental PageRankの計算で扱う頂点は以下の三種類に分けられます。
（計算時の分け方 Vul, Vb, Vur, Vcr とは異なる）
(1) 元からあった頂点で、スケールのみでよい (Vul, Vb)
(2) 元からあった頂点で、再計算が必要
(3) 追加された頂点で、再計算が必要
このうち、(1)と(2)はすでにページランクが割り当てられていて、その総和は(1)と(2)の頂点数と一致します。
頂点が追加されたので、その数だけ全体のページランクの総和も増える必要があります。そこで、(3)の頂点の初期ページランクとして1 を設定します。
ここで、(1)(2)(3)に対してページランク計算を実行すれば、その総和は
このうち、(1)の部分はページランク計算の際に値が変わらない（はずな）ので、ページランク計算の際には(2)(3)にページランク遷移を送るだけでよい(Vb)ので、処理を簡略化できます。
本来必要だったスケール処理部分は、PageRankの値を常に「頂点数」倍にした値で計算することによって省略されます。
