まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:analytics

IBM Bluemix を通じて提供されているコグニティブサービス(認識型人工知能)API の1つに Tradeoff Analytics があります:
2015051800


この API を理解するにはデモサイトを参照していただくのがいいと思います:
http://tradeoff-analytics-demo.mybluemix.net/

このデモサイトでは「一覧の中で、自分にあったスマホはどれか?」という命題を、その人が重要視するスペックポイントを明確にした上で候補を上げていく、というものです。

スマホはメモリは多い方がいいし、バッテリーは多い方がいいけど、そうすると重量が重くなります。でも重量は気にする人もいればいない人もいます。また価格は安い方がいいに決まっていますが、メモリやバッテリー、重量などの要素と比べて重要度が高いのか低いのか、は人によって異なってきます。 全てを満たすパーフェクトなスマホはそうそう出てこないでしょうから、結局はどの要素を重要視するかでトレードオフを考えることになると思いますが、どの要素を重要視した場合はどのような結果になるか、を判断してくれる、そんな API です。

例えば上記デモサイトを開くと、デフォルトでは以下の様な表が表示されます:
2015051801


一番上の列がヘッダで、2行目からがスマホの候補リストになっています。表の3列目以降がスペックになっていて、3列目は価格(小さい方がいい)、4列目はRAMメモリ量(多い方がいい)、5列目はスクリーンサイズ(意見が別れるところですが、ここでは大きい方がいい)、6列目はカメラの画素数(多い方がいい)、7列目はメモリ量(多い方がいい)、8列目はバッテリー容量(多い方がいい)、そして9列目は重量(少ない方がいい)となっています。このうちデフォルト状態では価格、スクリーンサイズ、重量の色が緑になっていて、今はこの3点を重要視する人にとってのトレードオフを解析する指定になっています。

もしもこれら以外の点を重要視したい場合は表右下の "View/Edit JSON" と書かれた箇所をクリックして JSON の内容を変更します。例えば「スクリーンサイズは気にしないけど、バッテリー容量は重要!」という場合は以下のように値を変更します。 まずスクリーンサイズは今回意識しなくていいので、JSON 内の columns の中で "key" 値が "screen_size" になっている項目の "is_objective" 値を true から false に変更します。この "is_objective" の値が true のものはトレードオフの考慮に含めて、false のものは含めない、という指定です。なお "goal" 値が "MAX" のものは「(メモリ量など)大きい方がいい」という値、"MIN" のものは「(価格など)小さい方がいい」という値だという指定です:
{
  "key": "screen_size",
  "full_name": "Screen size (inch)",
  "type": "NUMERIC",
  "is_objective": false,
  "goal": "MAX"
},

続いてバッテリー容量はトレードオフに新たに含めたいので、同様にして "key" 値が "battery" になっている項目の "is_objective" 値を false から true に変更します:
{
  "key": "battery",
  "full_name": "Battery (mAh)",
  "type": "NUMERIC",
  "is_objective": true,
  "goal": "MAX"
},

この状態で編集エリア右下の "Back to table" をクリックすると、価格とバッテリー容量と重量の3点が重要視指定された状態の表が表示されるはずです。なお、これら以外でも JSON を変更することで候補スマホの名称や各数値を変更することもできます。全て JSON フォーマットで指定されていることを確認しておいてください:
2015051802


重要視する項目が決まったら、画面右下の "Analyze Sample Data" と書かれたボタンをクリックして、トレードオフを計算します:
2015051803


すると画面下に以下のようなグラフが表示されて、指定した3項目でのトレードオフを考えた結果が表示されます。各スマホアイテムがそれぞれの要素を意識した時にどの位置にあるのか、ということが視覚化されています:
2015051804


例えば、ここでバッテリー項目の下限のスライダーを 1000 から 1500 近くまで移動させると、「バッテリー容量が指定値(1500)以下のものは考慮しない」という指定をしたことになり、画面上部付近にあったいくつかのバッテリー容量の少ないスマホが画面から消えます。これで更に絞込みやすくなります:
2015051805


・・・と、なんとなく「トレードオフ解析」の意味がお分かりいただけたでしょうか? IBM Bluemix で用意されているのは、このような解析を行うための(与えられた条件から、上記の結果グラフを書くための)API が用意されている、という点が特徴です。つまり上記デモサイトのようなことを皆さんの作るアプリケーションの中でも実現できるようになる、ということです。

実際にこの API を利用するには、IBM Bluemix で上記の Tradeoff Analytics サービスをランタイムアプリケーションにバインドして資格情報を確認し、利用のための username と password を取得しておく必要があります
2015051801


ここまで準備できれば API そのものは単純です。取得した username と password を使って Basic 認証を行い、https://gateway.watsonplatform.net/tradeoff-analytics-beta/api/v1/dilemmas に対して、解析させたい JSON(上記の Edit JSON をクリックして編集したもの)をポストするだけです。

成功すると、以下の様な JSON が結果として返ってきます:
{
  "problem": {
    "columns" : [ {
      "key" : "price",
      "format" : "",
        :
        (ポストした JSON の内容)
        :
  },
  "resolution" : {
    "solutions" : [ {
      :
      :
    } ],
    "map" : [ {
      "nodes" : [ {
        "coordinates" : { "x":0.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":1.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":2.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":3.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":4.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":5.0, "y":0.0 },
        "solution_refs" : []
      }, {
        "coordinates" : { "x":6.0, "y":0.0 },
        "solution_refs" : [ "5" ]
      }, 
        :
        :
      } ],
      "anchors" : [ {
        "name" : "price",
        "position" : { "x":0.0, "y":0.0 }
      }, {
        "name" : "battery",
        "position" : { "x":4.5, "y":7.8 }
      }, {
        "name" : "weight",
        "position" : { "x":9.0, "y":0.0 }
      } ],
        :
        :
    }
  }
}

結果の JSON の細かい内容は以下のリファレンスを参照していただきたいのですが、大きく3つの箇所を参照することになります。 1つ目は "problem" で、この中にポストした JSON がそのまま記述されているはずです。つまり「この問題に対する実行結果である」ことを示しています。

2つ目は "resolutions" の中の "map" で、ここに散布図を書いた時の各点の座標(x,y)が示されており、またその座標位置に相当するアイテムがあった場合は "solutions_refs" という配列値で示されます。例えば上の例ですと ( 6.0, 0.0 ) の位置に "key" 値が "5" に相当するアイテムがある、ということになります。

最後の3つ目は "resolutions" の中の "anchors" で、これが指定した各トレードオフ要素(この例では価格とバッテリー容量と重量)が散布図上のどの位置にあるかを示しています。


後はこの結果を受け取った側でどのように見せるか、という問題になります。チャート描画の API を使ってもいいし、Canvas を使って自分で記述してもいいと思います。ここから先は開発者やデザイナーの腕の見せ所と言えます。そういう意味ではここのデモサイトはなかなか良くできてますよね。


というわけで、これまでにこのブログで紹介してきたコグニティブサービスとは少し(特に実行方法の面で)毛色が違うサービスと言えます。API 実行時に指定フォーマットの JSON を作る必要があるのが少し面倒ですが、トレードオフを意識する要素と、それらの値は大きい方が嬉しいのか小さい方が嬉しいのかの情報、そしてアイテムの一覧を JSON にしてポストすれば結果が返ってくる、というものです。REST API そのものはシンプルなのでエクセルのような表計算からも実行できると思っています(エクセルだと逆に結果の視覚化が難しいかも・・)。


なお、ここで紹介した Watson Tradeoff Analytics API について、詳しくは API リファレンスを参照してください:
http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/apis/#!/tradeoff-analytics
 

最近は少子化の影響で事情が少し違うかもしれませんが、自分が中高生だった頃の1クラスはおよそ40~45人でした。そしてクラスには「班」という制度?があり、クラスの中をいくつかのグループに分けて活動することが多くありました。自分の場合は1つの班に5~7人が割り当てられていたと記憶しています。

班は便利です。例えば掃除などのローテーションを行う単位になったり、ちょっとしたグループディスカッションを行う場合のグループになったりします。 これをあらかじめ決めておくことでグループ分けの時間が必要なくなるので先生としても便利だったと思っています。

が、1つわからなかったのが「何故1クラスは40人前後なのか?」、そして「何故1つの班は5~7人程度で構成するのか?」でした。ずっと疑問に思っていたわけではなく、まあそういうものだったんだろう、、という程度に考えていましたが、改めて考えると統一する理由はあまりないと思ってます。 ましてや1クラスの人数は(学校によって担任の負担が変わらないように、とかの理由で)わからなくもないけど、班の人数を決める必要性がどこにあるのか、別に3人でも4人でもいいと思うし、3人の班や7人の班が混在していてもいいのでは?? と考えていました。例えば仲のいい5人組とかがいて、その中にもう1人入っていくのはお互い嫌な気分とかにならないのかな・・・と。それでも班の人数を固定する理由があるのか・・・という感じでした。

ところが、これは統計を勉強するようになって気付きました。「理想を言えば1クラスは42~3人、1班は6~7人がいい」のです。適当な数字ではなかった、ということです。


この秘密の鍵は「正規分布」「標準偏差」にあります。

「正規分布」は「平均値に近いほどそのサンプル数が多くなるような連続した確率の分布」のことです。わかりやすく言えばテストの得点が横軸、その点を取った人の人数が縦軸になるようなグラフを書いた時にこんな感じになるような分布のことです(この例だと平均点は50点あたりで一番多く、そこから離れるにしたがって人数が減っていくような分布):
Standard_tscore

学力テストなどでは、例えば全国模試など充分な数の受験生がいるような試験ではその結果は正規分布になります。精度が少し荒くはなりますが、1つの学校内での模擬試験などでも正規分布として考えることが多いです。

そして「標準偏差」。受験ではよく聞く「偏差値」というキーワードを耳にすると思いますが、「標準偏差」は偏差値と大きな関わりがあります。「標準偏差」は「バラつき度合い」を示すものです。要はグラフの形は上記のようになるけど、平均点付近にかなり固まっているのか、あるいは0点から100点までそれなりにバラついているのか、という数値の指標になるものです。標準偏差そのものはエクセルを使って簡単に(STDEV関数で)求めることが出来ます。

で、日本の受験で用いられる学力偏差値では標準偏差1を偏差値10とみなし、以下のような関係が成立します:
 ・平均点を偏差値50とする
 ・平均点よりも標準偏差1つぶん多い点数を偏差値60とする
 ・平均点よりも標準偏差2つぶん多い点数を偏差値70とする
   :
 ・平均点よりも標準偏差1つぶん少ない点数を偏差値40とする
 ・平均点よりも標準偏差2つぶん少ない点数を偏差値30とする
   :

要は、各個人の得点が平均点と比べて標準偏差いくつ分離れているのか?を数値化したものが偏差値なのです。

そして成績の分布が正規分布だった場合、偏差値にはおおまかに以下の関係が成立します:
 ・偏差値60以上は全体の15.6%(6~7人に一人
 ・偏差値70以上は全体の2.275%(43~4人に一人
 ・偏差値80以上は全体の0.135%(約740人に一人)
   :
 ・偏差値40以下は全体の15.6%(6~7人に一人
 ・偏差値30以下は全体の2.275%(43~4人に一人
 ・偏差値20以下は全体の0.135%(約740人に一人)
   :

言い方を変えると、
 ・偏差値60以上は班に一人、
 ・偏差値70以上はクラスに一人、
 ・偏差値40以下は班に一人、
 ・偏差値30以下はクラスに一人、
   :
言えるようにするには、1クラスを43~4人、1班を6~7人で構成するのが理想、という表現もできることになります。

さすがに1学年で740人というマンモス校は珍しいと思いますが、2つの学校の同学年を足すとこのくらいになることはあると思います。その場合は「偏差値80以上と、偏差値20以下は2つの学校で一人ずつ」とも言えますね。


これが本当にクラス編成、班分けの理由かどうかはわかりませんし、試験結果は必ずしも正規分布にならないこともあります。でも6~7人のグループや40数名のグループが集められることがあったら、それは統計目的でグルーピングされている可能性もある、のかも。 少なくとも、上記のような統計との関係はあるので。



 

2014 年も終わりが近づいてきました。

このたび拙作マンホールマップにおける2014年分の利用実態調査を行ったので、そのレポートを2回に分けて発表させていただきます。初回はアクセス解析結果より世の中の「マンホーラー」の実態を浮き彫りにしよう、というのが目的です。いちおうビッグデータ解析です。 

なお、データは全て Google Analytics から取り出したものです。グーグル先生、こんな便利なツールを無料で提供いただき、いつも大変お世話になっております。 m(__)m


また、以下のデータには利用者の年齢や性別、趣味、言語といった情報が含まれていますが、これらはグーグルのプロフィール予測に基づくものです。グーグルに正しい情報を入力している人の場合はその正確なデータが使われますが、グーグルに情報を入力していない人の場合は、ウェブページの閲覧履歴から、これらのデータを予測しており、その予測データが使われています。

あなたがグーグルからどんな人だと思われているのか、興味がある人はこちらのサイト(https://www.google.com/settings/ads/onweb/?hl=ja)を見てください。


では実態調査の発表です。まずは「2014 年マンホールマップの年齢別利用率」です:
2014121901

あら、意外と(?)若い。この結果を見る前は 35-44 歳がダントツの印象を持っていたのですが、結果は 25-34 歳の層が全体の3分の1のアクセスを占めての1位。そして更に若い 18-24 歳の層が2位となりました。マンホーラーの未来は明るいです!

次は「マンホールマップ利用者の性別」
2014121902

わずかに男性の方が上回っていますが、女性率なんと 45.85 %!これなら合コンが成立する割合です(笑)。「マンホール女子」が 2015 年の流行語大賞ダークホースに踊りでたと言っても過言ではないでしょう。


そして「マンホールマップ利用者の興味分野」、つまり利用者の趣味です。これはまあ普通に「旅行」関係でしょう、と思っていたら・・・
2014121903

1位は「ウォーキング」と考えればまあ分かる。3位も「サイクリング」なので自転車で探しまわる人がいるのでしょう。4位の「フード」は食べ歩きとセットなんですかね。大本命と思われた「旅行」は5位。 

そしてこれらに割って入ったのが2位の「コンピュータ」。いや、たしかに周囲に関係者が多いのは実感として分かっていました。分かってましたが、「マンホール」と「コンピュータ」の意外な結びつきが明らかになりました。本当にビッグデータ解析っぽくなってきましたよ(笑)。


ここから下はより一般的なウェブ統計情報です。

まずは「新規ユーザーと既存ユーザーのアクセス比率」です:
2014121904

新規ユーザーの方が10ポイントほど上回っており、常に新しいユーザーの開拓に成功していることが分かります。自画自賛!

次は利用者の言語。これはブラウザに設定された優先言語を見ているのだと思います。つまり日本人がアメリカから日本語環境でアクセスした場合は「日本語」としてカウントされ、アメリカ人が日本に来て、アメリカ設定でアクセスした場合は「米語」としてカウントされる、ということです。 さて日本語が高いのはわかるとして、その次に高いのは・・・
2014121905

英語(米語)でした。アメリカ人も日本のマンホールに興味を持っている、と考えていいんでしょうかね。


次はアクセス元の国別です。こちらも上記の結果からアメリカかな、と思っていたら・・・
2014121906

2位おそロシア! 3位フランス! 以下、英国、インド、ニュージーランド(!?)と続いて、アメリカ7位。これは意外でした。

これらの結果だけから推測すると、アメリカ人がロシアやフランスに渡った際にマンホールマップを見ている可能性が高い、ということになります。本当か? (^^;


次は日本国内の市区町村別アクセス元ランキング。こちらの結果は・・・
2014121907

1位港区、2位浦安市、3位渋谷区。。。 仕事中にマンホールマップを見ているのがバレた可能性が僕の地元船橋市がありません。もっと頑張らねば!

続いていきましょう、利用ブラウザランキング。一応マンホールマップを PC から見る場合は Chrome を推奨しているのですが、実態はというと・・・
2014121908

まさかの Internet Explorer !これ動作確認もしてないどころか、非推奨ブラウザなんですけど・・・


では OS 別ではというと・・・
2014121909

まあ順当、ですかね。 ちなみに1位の Windows はダントツ。2、3、4位が激戦。6位の Chrome OS はおそらく僕だけのデータです(苦笑)。


以上の統計結果より、意外に面白い 2014 年版マンホーラーの実態が浮き彫りになってきました:

・若い女性/新規参入者が多い
・「リア充」か「コンピュータおたく」に2極化している
・アメリカ人がロシアやフランスに旅行してマンホールを探している
・Internet Explorer の根絶は無理!


最後のはマンホーラーとは関係ないような気もするけど・・・


さて、次回はいよいよマンホール蓋別年間アクセスランキングの発表です。栄えある 2014 MVM(Most Variable Manhole) に輝くのはどのマンホール蓋か!? お楽しみに!


(2014/12/21 追記)
続きはこちら

 

このページのトップヘ