Excelの機能の1つに「ピボットテーブル(Pivot table)」がある。これは、表形式のデータを変形して理解しやすくする手法の1つ。ピボットテーブルは、1991年に発売されたLotus Development社の表計算Improvに最初に搭載された。当時はピボットテーブルとは呼ばれておらず、のちに同様の機能を実現したアプリケーションBrio Technology社の「DataPivot」という製品や、その特許が他社にライセンスされたことなどから「Pivot」の名がついたようだ。Excelは、1994年のExcel Ver.5.0で「Pivot table」と呼ばれる機能を搭載した。

ピボットテーブルとは、縦に並ぶ列を横方向に並び替えることで、複数の列からなる複雑な表を見やすい形に変形する(図01)。Pivotという単語には「軸による回転」という意味があり、列が縦から横に並ぶところを回転と表現したのだと思われる。ピボットテーブルの多くの解説では、「売上を月別、地域別にする」などビジネスに関連した例が使われてピンと来ないが、どんな分野のデータ処理にも利用できる。

    図01: ピボットテーブルとは、縦に並んだ3列以上のデータを列と行に対応させて、値列を集計して配置していく。これで見ると、Windows 7のSDKにあったファイルの多くがそのまま残っていることがわかる。なお、ピボットテーブルは列をどれか1つ指定して「並べ替え」が可能

筆者は、WindowsのSDKの変遷を調べているとき、ピボットテーブルを使って、そのインクルードファイル(ヘッダファイル)とフォルダーの変化をWindowsのバージョンごとに調べた。ヘッダーファイルには定数定義や関数プロトタイプなどがありAPI変更に伴いファイルは更新される。つまり、ヘッダーファイル(.hファイル)の変化を調べていけば、WindowsのAPIの変遷を知ることができる。

たとえば、フォルダ構成(写真01)だが、Windows 7までは、Includeフォルダの直下にほぼすべてのヘッダファイルがあった。しかし、Windows 8では、デスクトップアプリ用(um。unmanaged)とUWP用(winrt)、および共用(shared)の3つにフォルダーが分かれた。その後Windows 10では、それぞれにサブディレクトリが追加されつつファイルが増えていく。Windows 10 Ver.1709(RS4)では、その総数は3000を越えた。

    写真01: Windows 7から最新のプレビュー版CanaryチャンネルまでのWindows用SDKヘッダファイルを格納するIncludeのサブフォルダの変遷。Windows 7ではベタにほとんどのヘッダファイルが置かれていたが、Windows 8でストアアプリ(winrt)、デスクトップアプリ(um)でフォルダを分離、その後、Windows 10から段階的にディレクトリが増えた。ピボットテーブルの作成では、元データのビルド番号を「列」に、サブフォルダ相対パスを「行」に、ファイル名の個数を「値」に指定

元データはWindows SDK(Windows Kit)のIncludeファイルで、最近のSDKでは、対応Windowsバージョンに応じて10.0.22000.0(Windowsバージョンとビルド番号の組合せ)のようなフォルダ名になっている。ここから、ビルド番号(フォルダ名から生成)、サブフォルダ相対パス、ファイル名、ファイルサイズをPowerShellで取り出してCSVファイルを作りExcelで処理した(写真02)。

    写真02: PowerShellで作成したCSVファイルをテーブルとして読み込んだもの。データは、ビルド番号(Build。親フォルダから生成)、サブフォルダ相対パス(Pdir)、ヘッダーファイル名(Name)、ファイルサイズ(Length)からなる

Excelでピボットテーブルを作るのには、大きく2つ方法がある。1つは、Excelのリボンの「挿入」タブにある「ピボットテーブル」を使って対話的に行なう方法、もう1つは、PowerQueryでCSVファイルを読み込んで「列のピボット」(変換タブ)を使う方法である。

Excel自体を使う方法は簡単で、ピボットテーブルという特別な形式のテーブルになるのだが、手動操作なので複数のピボットテーブルを作るのが面倒になる。逆にPowerQueryを使う方法は、操作が記録されるため、異なるデータファイルから同じピボットテーブルを作るのは簡単だが、PowerQueryに慣れている必要があり初心者には、少しハードルが高い。また、生成されるのはテーブルである。今回は、他人にみせるわけでもないし、何回も作成しないのでExcelのピボットテーブルで作成した。

ピボットテーブルを作ったとき、条件付き書式を使うと、データが変化したときに色を付けるといったことが可能になり表が見やすくなる。同じデータから個々のヘッダファイルのファイルサイズをピボットテーブルで、Windowsバージョンごとに集計したもの(写真03)では、条件付き書式で、右隣と一致しないセルに背景色を指定した。

    写真03: 同様に各ヘッダファイルのファイルサイズを集計した。色が付いているのが前バージョンから変化したところ。Windows 7にあったヘッダファイルは大半が現在も残っているが、段々とファイルサイズが大きくなっている。数字はサブフォルダ内のファイルの数を示す。元データのビルド番号を「列」に、ファイル名を「行」に、ファイルサイズの合計(重複がないので、サイズそのもの)を値にしている

今回のタイトルネタは、マルチプロセス間での排他制御を扱った「Dining Philosophers Problem」が元ネタ。哲学者が丸テーブルに座り、食事をするのだが、食事に必要な2本のフォークは、隣と共用になっているため、隣合う哲学者が同時に食事をすることはできない。場合によっては、全員がずっと食事できない状態(デッドロック)に陥ることもある。さて、どうすればいいのかという問題である。これは、1965年にダイクストラが“Cooperating sequential processes”として提案した問題が元になっている。A.C.Eホーアが著書“Communicating Sequential Processes”(1985,Prentice Hal)で「Dining Philosophers Problem」と名付けて定式化した。

ダイクストラは、自分の書いた文書にEWD番号を付けていた。“EWD”は自身のイニシャル(Edsger Wybe Dijkstra)である。この「Dining Philosophers Problem」の元になった文書は、EWD 123として知られている。ピボットテーブルのオリジナルがImprovで、開発はLotus社、同社は表計算1-2-3で有名である。それがEWD番号と奇妙に一致したのが気になった。もちろん、Dinning Tableからの連想が最初だったのだが。