2018年12月29日土曜日

PythonでMCA(コレスポンデンス分析)

Pythonでコレポンをやる

コレスポンデンス分析

  • 略してコレポン

    • 数量化III類(Quantification Theory III)、対応分析(CA: Correspondence Analysis)、多重対応分析(MCA: Multiple Correspondence Analysis)、双対尺度法(Dual Scaling)など、呼び方や近縁手法が複数存在し、数理的には非常に近い関係にある
    • ここでは「コレポン」表現をメインに据えている。実際にはCAだったりMCAだったりするが数理的背景は非常に近いため細かい区別は気にしない
  • point

    • 観測データを単純化することで、データの背後にある潜在的な要素を解釈しやすくする
    • 質的データ(カテゴリデータ)の関係構造を探索するのに適している
    • 主成分分析(Principal Component Analysis)と数理的に近い構造を持つ
    • PCA同様にデータを縮約して、2次元プロットなどで可視化できる
    • 統計的厳密性よりは、結果解釈のしやすさや仮説探索的手法として喜ばれやすい(コレポンに限らない)
    • 大雑把な傾向把握にとどめるのが望ましい(細かいことを気にしないことこそコレポンらしさかも)
  • Rの場合

    1. インストールして library(ca)
    2. 読み込んで実行して ca(table.T)
    3. 可視化 plot(ca(table.T))
  • Pythonの場合

    • ここではmcaライブラリを使用 python -m pip install mca
    • 単機能でシンプルではあるが、新規に始めるならprinceライブラリの方がいろんなことに使いやすいかも

コレポンとPCA

  • コレポンの特徴
    • カテゴリデータや頻度データの関連構造を少数の軸で表現する手法。期待頻度からのズレ(カイ二乗統計量)が大きい方向を探す。
    • カイ二乗距離に基づく幾何を前提としている。行・列の周辺度数で基準化した行列を特異値分解する。
    • 行と列を双対的に扱い、同一空間上に同時布置できる。
  • PCA(主成分分析)の特徴
    • 数値データの分散構造を少数の軸で表現する手法。データのばらつき(分散)が最大になる方向を探す。
    • ユークリッド距離に基づく幾何を前提としている。共分散行列または相関行列を固有値分解する。
    • 行(サンプル)は主成分スコア、列(変数、特徴量)は負荷量として表現される。
  • コレポンとPCAの共通点
    • 多変量データの構造を少数の軸で要約・可視化する次元圧縮手法(データの背後にある構造を捉えるためのもの)
    • データ中の「似たパターン」や「関係構造」を低次元空間へ埋め込む(低次元に圧縮して、似た回答傾向を可視化する)
    • 元データを座標空間へ変換し、近い点ほど似た性質を持つと解釈できる
    • 軸ごとの構造を使って、クラスタ傾向や潜在的な特徴を読み解ける
  • コレポンとPCAの相違点
    • コレポンとPCAは少なくとも数理的な骨格は同じなんだが
    • 軸の解釈に対する考え方の違い、解析結果の安定性など運用上は多くの相違点が存在する(PCAにおける軸は量的な増減方向として解釈しやすい。コレポンにおける軸はカテゴリの対立軸として表れやすい)
    • だがコレポンは適用範囲が広い。理論的前提から多少外れていても、大まかな構造把握用途では有用な場合が多い。特に順序尺度のアンケートデータなどでは、PCA的に見るかコレポン的に見るかの境界が曖昧になることも多い

コレポンの注意点

  • 仮説探索や構造把握に向いた手法であり、推定や検定のような厳密性を主目的とする分析とは少し性格が異なる
  • 適用範囲が広い(深く捉えなくともなんでも実行しやすい)とはいえ、本来持っていた情報を相当捨てていることは気に留めておく
  • 変数間で尺度の意味が大きく異なるデータには向かない(例えば年収と身長と気温を同列の変数として扱うのは不適切)
  • PCA同様に異常値や希少カテゴリは空間構造をゆがめやすい

コレポンの実情

  • 特にマーケティング分野におけるアンケート調査データにおいて重宝されやすい
  • 「結果の見た目がわかりやすい」「直感的に理解しやすい」「解釈やストーリーを考察しやすいので話が弾む」などが主な理由として考えられる
  • 他に「クロス数表があればできちゃう」「たいていの設問形式に対応できちゃう(ように感じやすい)」「簡単な操作で簡単なアウトプットが得られちゃう」もありそう
  • 理論的美しさよりも、実行しやすさや適用範囲の広さ、データの背後構造の見えやすさが魅力と言える

コレポンの守備範囲

  • 理論的には、行・列ともにカテゴリデータの頻度表(人数、出現数などのcountデータ)を対象としている

    • 例えば、行に「カフェのメニュー」、列に「性年代区分」を置いたデータセット(各メニューを好きと回答した人数の性年代別集計値)でおこなうのが王道
    • だがクロス数表を読み慣れている場合はコレポンやる意義を感じにくいかも
    • 性別や年代による違いは想像がしやすいため(ある程度わかってる顕在的要素をなぞってるだけに見えるぶんコレポンの利点が活かされにくい)
  • コレポンをよく使う場面

    • 例えば、行に「カフェのメニュー」、列に「イメージワード」を置いたデータセット(各メニューの印象にあてはまるワードを選択した人数のワード別集計値)
    • イメージが似てるメニューはどれとどれなのか、逆に似ていないのはどれかといった解釈がしやすい(クロス数表からは読み解きにくい)
    • コレポンの理論的枠組みからはやや外れるが、コレポンやる意義を感じさせやすい
  • 他に、

    • 行に「回答者」、列に「イメージワード」を置いたデータセット(回答者各自がカフェの印象にあてはまるワードに5段階評価したローデータ)
    • これも理論的枠組みからは外れる(PCAっぽいともいえる)が、ある人がどんなワードを重視してるか、似た者同士は誰かといった解釈がしやすい
  • 比率表(回答者数全体に占める割合、%データ)のデータセット

    • コレポン自体は実行できるし、頻度表よりも入手しやすい場面もあるなどこちらでおこなう人が多数派かもしれない
    • これまた理論的枠組みからは外れるが、単純化するという性質からさほど弊害が表れにくい(頻度表での実行結果と大差ないなど)
    • 同様理由で、表の縦%や横%が100を超える場合(複数回答形式設問)でもおこなわれているだろう

コレポン結論

  • 理論を超えて使いやすいが、わかりやすさに引きづられない
  • 簡単に得られる情報と引き換えに、捨てている情報も多いことを忘れない

コレポン実行例

  • あるカフェのお客様アンケート結果をコレポンしてみる
  • メニュー × イメージワード
    • 実務においてありがちなコレポンの使い方
    • お店のメニュー(8品)それぞれに対して、印象にあてはまるイメージワード(8項目)をMA(複数回答可能形式)で聴取
    • 行(メニュー)、列(イメージワード)のクロス数表(選択した人数の頻度表)
    • MA選択率よりはイメージワード各5段階評価のTOP2人数の方がコレポン理論には近い。とはいえ回答者負荷の高い設問形式を推奨したくない意図
# import
import pandas as pd
import numpy as np
from matplotlib import pyplot as plt
import mca

# version
import sys;print("Python", sys.version.split()[0])
import platform;print("OS", platform.platform())
print("is_google_colab:", "google.colab" in sys.modules)
from importlib.metadata import version
packages = [
"pandas",
"numpy",
"matplotlib",
"mca"
]
for pkg in packages:
    try:
        print(pkg, version(pkg))
    except Exception as e:
        print(pkg, "not installed")
Python 3.11.15
OS macOS-26.5-arm64-arm-64bit
is_google_colab: False
pandas 2.2.0
numpy 1.26.4
matplotlib 3.10.9
mca 1.0.4
# サンプルのdataframeを生成する

# メニュー(行)
menus = ['Coffee', 'Tea', 'Latte', 'Espresso', 'Cake', 'Sandwich', 'Cookie', 'Toast']

# イメージワード(列)
words = ['香り高い', 'コスパが良い', '見た目が映える', '濃厚な味わい', 
         'ボリューム満点', '手軽に食べれる', '贅沢な気分', '健康的なイメージ']

# プロットがある程度バラつくように、『Tea』『Cookie』『手軽に食べれる』が中心近辺にくるように平均的な値に寄せている
data = [
    [50, 25,  5, 15,  5, 30, 10,  5], # Coffee
    [25, 20, 15, 10, 10, 35, 15, 15], # Tea
    [10, 10, 45, 35, 10, 20, 30,  5], # Latte
    [40, 10, 10, 55,  5, 15, 25,  5], # Espresso
    [10, 10, 50, 30, 10, 15, 45,  5], # Cake
    [ 5, 25, 10,  5, 50, 40,  5, 30], # Sandwich
    [20, 20, 18, 15, 15, 30, 15, 12], # Cookie
    [10, 40,  5,  5, 35, 40,  5, 20], # Toast
]

df = pd.DataFrame(data, index=menus, columns=words)


# MCAの実行
ncol = df.shape[1]
mca_ben = mca.MCA(df, ncols=ncol, benzecri=False, TOL=1e-8)


# 行スコア(=座標)
result_by_row = pd.DataFrame(mca_ben.fs_r(N=2))
result_by_row.index = list(df.index)
print ("Score by row:")
print(result_by_row.round(3))
Score by row:
              0      1
Coffee    0.010 -0.686
Tea       0.132 -0.137
Latte    -0.513  0.348
Espresso -0.535 -0.413
Cake     -0.594  0.440
Sandwich  0.771  0.284
Cookie    0.080 -0.020
Toast     0.710  0.047
# 列スコア(=座標)
result_by_column = pd.DataFrame(mca_ben.fs_c(N=2))
result_by_column.index = list(df.columns)
print ("Score by column:")
print(result_by_column.round(3))
Score by column:
              0      1
香り高い     -0.184 -0.727
コスパが良い    0.433 -0.130
見た目が映える  -0.533  0.537
濃厚な味わい   -0.629 -0.123
ボリューム満点   0.724  0.326
手軽に食べれる   0.339 -0.065
贅沢な気分    -0.579  0.227
健康的なイメージ  0.642  0.160
# 固有値と寄与率

# MCAでは「行と列のどちらか少ない方の数-1」 が固有値(eigenvalue)の最大数になるためそれを算出
num_of_eigenvalue = min(len(df.index), len(df.columns)) - 1

data = {
    'Factor': range(1, len(mca_ben.L) + 1),
    'value': pd.Series(mca_ben.L),
    'ratio': mca_ben.expl_var(greenacre=False, N=num_of_eigenvalue)
}
columns = ['Factor', 'value', 'ratio']
table2 = pd.DataFrame(data=data, columns=columns).fillna(0)

# ratioの累計(cumulative_ratio)列を追加
table2['cum_ratio'] = table2['ratio'].cumsum()

print("Principal & Inertia(固有値 寄与率):")
print(table2.round(3).to_string(index=False))
Principal & Inertia(固有値 寄与率):
 Factor  value  ratio  cum_ratio
      1  0.266  0.598      0.598
      2  0.131  0.296      0.894
      3  0.033  0.075      0.969
      4  0.007  0.016      0.986
      5  0.004  0.008      0.994
      6  0.003  0.006      1.000
      7  0.000  0.000      1.000

# 上記Factor1,2でプロット
plt.figure(figsize=(7, 6))

# plt.rcParams['font.family'] = ['sans-serif', 'Meiryo']  # windows
plt.rcParams['font.family'] = ['sans-serif', 'Hiragino Sans']  # mac

# plot by row
plt.scatter(result_by_row[0], result_by_row[1], color='tab:blue', s=20, marker="o", label="Row")
for k, v in result_by_row.iterrows():
    plt.annotate(k, v, xytext=(2, 2), textcoords="offset points")

# plot by column
plt.scatter(result_by_column[0], result_by_column[1], color='tab:orange', s=20, marker='s', facecolors="none", label="Column")
for k, v in result_by_column.iterrows():
    plt.annotate(k, v, xytext=(2, 2), textcoords="offset points")

plt.axhline(0, color='gray', linestyle='dashed')
plt.axvline(0, color='gray', linestyle='dashed')
plt.xlabel('Factor 1')
plt.ylabel('Factor 2')
plt.title("Correspondence Analysis\n(Customer Satisfaction Survey Example)")
plt.legend(loc='best')
# plt.gca().set_aspect("equal")
plt.show()

結果の解釈例

  • 左上のCakeとLatteは似たイメージでお客様から捉えられている
  • CakeとLatteはともに「映える」「贅沢」といったリッチなイメージが強そう
  • これらとは対極の右側にはSandwich, Toastが「手軽に食べれる」日常的なMenuとの評価
  • 横軸(第1軸)はハレと日常を表すような背後要因が考えられる
  • 下方のCoffeeはハレと日常の中間的ポジションながらも、Espressoともども「香り高い」イメージ
  • 縦軸(第2軸)は寄与率が1軸ほど大きくなく、背後要因はやや読み解きにくい(今回使用したイメージワードでは不足だった可能性も考えられる)
  • 中心付近にプロットされた「Cookie」「Tea」は他のMenuほどには強い特徴がみられなかったと解釈できる

(2026年5月更新)


2018年11月17日土曜日

exif情報の一括削除

ImageMagickでできる

フォルダ内のExif情報を削除したい場合はオプションの「-strip」で可能
該当フォルダに移動した後、一括操作の「mogrify」を使う
mogrify -strip *.jpg


イメージマジックでフォルダ内のExif情報を一括削除する
https://www.s-oj.com/ec-business/system/imagemagick%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%82%B5%E3%83%96%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%E3%81%AEexif%E6%83%85%E5%A0%B1%E3%82%92%E4%B8%80%E6%8B%AC%E5%89%8A%E9%99%A4/

----

すべてのpng画像をjpgに変更
mogrify -format jpg *.png
(元画像は残る)

https://liginc.co.jp/394506

----

ImageMagick基本編:Mogrifyを用いた画像の一括処理について
http://shumilinux.blogspot.com/2016/06/imagemagick-mogrify.html

2018年10月13日土曜日

AWSとGoogle CloudとHadoop

AWSとGoogle CloudとHadoop(やその元になったGoogleサービス)を対比。


Amazon S3 ≒ Google Cloud Storage ≒ オンプレ(HDFS / GFS)

巨大なデータを、安価に、壊れないように保存するための仕組み。

安価な構成: 特別な高級ハードウェアではなく、普通のハードウェア(サーバーやハードディスク)を大量に並べて巨大な保存スペースを作る。

自動バックアップ: どこかのハードディスクが1台や2台壊れてもデータが消えないよう、自動的にデータを3つ以上の場所にコピーして保存する仕組み(レプリケーション)を持っている。

特徴 Amazon S3(AWS) Storage(Google Cloud) オンプレ(GFS / HDFS)
実体 AWSが管理する、インターネット経由の「純粋なデータ保存スペース」。 Googleが管理する、インターネット経由の「純粋なデータ保存スペース」。仕組みはS3とほぼ同じ立ち位置。 自分たちで用意した「サーバー(CPU+ハードディスク)」の集まり。
拡張方法 ユーザーは何もしなくてよい。データを入れれば入れるだけ、容量が無限に自動拡張される。 同様にユーザー側での容量管理は不要。データを入れれば入れるだけ自動拡張される。 容量が足りなくなると、サーバーを丸ごと1台買い足してネットワークに繋ぐ作業が必要。
計算方法との関係 保存に特化している。計算するときは、別の計算用サーバー(EC2やEMRなど)を必要な時にだけ起動してS3に接続する。 同様に保存に特化。計算するときは、Dataprocなど別の計算用サービスを必要な時にだけ起動してGCSに接続する。 データを保存しているサーバーそのものに計算(MapReduceなど)をさせる。

Amazon EMR / AWS Glue ≒ Google Cloud Dataproc ≒ オンプレ(Hadoop MapReduce)

大量のデータを並列で処理・加工する役割

大量データの並列処理: 1台のコンピューターでは処理できないテラバイト・ペタバイト級のデータを、数百〜数千台のマシンに分散して同時に計算する。

データの変換(ETL): 散らばった生データ(ログやCSVなど)を読み込み、きれいに整えて、分析しやすい形に変換して別の場所(S3など)に書き出す。

特徴 Amazon EMR / Glue(AWS) Dataproc(Google Cloud) オンプレ(Hadoop MapReduce)
処理のスピードと仕組み EMRやGlueの主流である「Apache Spark」は、データをメモリ(RAM)上で処理するため、MapReduceより最大100倍高速。 DataprocもSpark/Hadoopを動かせるマネージドサービスで、同じくメモリ処理のSparkが主流。ストレージはHDFSではなくGCSを使う設計。 データを処理する際、一工程ごとにハードディスク(ストレージ)への書き込みが発生するため、処理が遅い。
サーバーの管理 EMR: 処理するときだけ自動で数百台のサーバーを起動し、終わったら消せる(使った分だけ課金)。Glue: サーバーの存在すら意識しない(サーバーレス)。 処理するときだけクラスターを起動し、終わったら消せる(使った分だけ課金)。さらに「Dataproc Serverless」を使えば、クラスターの管理自体が不要になる。 処理をするために、常に数千台のサーバーを自前で起動・維持しておく必要がある(使っていなくても電気代や管理費がかかる)。

Amazon DynamoDB ≒ Google Cloud Bigtable ≒ オンプレ(Apache HBase)

大量のデータから特定のデータを一瞬で読み書きするデータベース

超高速レスポンス(低レイテンシー): データ量がペタバイト級に増えても、アクセスが1秒間に数百件〜数百万件に激増しても、常に「1桁ミリ秒(1000分の数秒)」という超高速でデータを返す。

NoSQL(キー・バリュー型 / ワイドカラム型): 行と列でガチガチに固められた従来のRDB(SQL)とは違い、特定のキー(鍵)を指定して一直線にデータを取り出す仕組み。データの構造(項目)を後から自由に追加・変更できる柔軟性を持っている。

特徴 Amazon DynamoDB(AWS) Bigtable(Google Cloud) オンプレ(Apache HBase)
データの管理単位(アーキテクチャ) 進化型KVS(ドキュメント/ワイドカラム対応):基本の骨組みは、列を後からいくらでも横に広げられるワイドカラム型(KVS)。その中にJSONのような複雑なデータの塊(ドキュメント)をそのまま丸ごと放り込める柔軟な構造に進化。 ワイドカラム型の元祖サービス。巨大な1つのスプレッドシートのような構造で、データは「行(Row Key)」ごとにアルファベット順で並べられて管理される。 Google BigtableをモデルにHadoopエコシステム向けに作られたOSS実装。データの並び方や設計思想はBigtableとほぼ同じ。
運用のハードル 完全サーバーレス: データの読み書きの回数や、保存したデータ量だけで課金される。小さな個人アプリから、Amazonのプライムデーのような超巨大イベントまで自動で伸縮する。 フルマネージドではあるが、DynamoDBほどの完全サーバーレスではなく、クラスター(ノード)を明示的に確保して動かす方式。オートスケーリング設定はできるが、自前HBase運用に比べると圧倒的に楽、という立ち位置。 安定して高速に動かすためには、最低でも数台(できれば数十台)のサーバー(ノード)をクラスターとして維持する必要があり、初期コストが高い。

キー・バリュー型(ドキュメント型)とは?

鍵(Key)と中身(Value)がペアになって保存されている、非常にシンプルなデータ構造のこと。コインロッカーのようなイメージ。

  • キー(Key): ロッカーの番号。世界に一つだけで絶対に重複しない
  • バリュー(Value): ロッカーの中に放り込まれている荷物(データ)そのもの

なぜ超高速なの?

従来の一般的なデータベース(SQL)は、Excelのように列と行が複雑に組まれており、データを検索するときは「A列が〇〇で、かつB列が××のデータを上から順番に探す…」という複雑な探索(計算)をする。そのためデータが増えると重くなる。

一方、DynamoDBのようなキー・バリュー型は、「105番のロッカーを開けて」と指示するだけ。データが100万件あろうが1億件あろうが、目的のロッカーへ一直線に向かうため、常に一瞬(1桁ミリ秒)でデータを取り出すことができるのが最大の強み。

DynamoDBは、ロッカーの中に入れる「バリュー(荷物)」の形として、JSONという書類(ドキュメント)のような複雑な階層構造のテキスト形式をそのまま丸ごと放り込める柔軟性(ドキュメント型としての特徴)を、ワイドカラムな骨組みの上に持たせている。

ワイドカラム型は、ロッカーの中にさらに細かく仕切られた小さな引き出し(カラム)が大量に並んでいるイメージ。鍵(行キー)でロッカーを開けたあと、3番目の引き出し(列)のデータだけを読み込むことができる。そして引き出しは10個だったり100個だったり、後からいくらでも横に広げる、ワイドにできるためワイドカラム型と呼ばれる。



AWSタイムライン

2006年3月:Amazon S3誕生。巨大なデータ保存庫。AWSというクラウドサービスのほぼ最初のサービスとして誕生。クラウドの歴史が始まる。

2009年4月:Amazon EMR誕生。Hadoopをクラウドで動かす基盤として登場(当時はまだMapReduce処理が全盛期)。

2012年1月:Amazon DynamoDB誕生。リアルタイムを支える超高速NoSQLデータベース。

2012年11月: Amazon Redshift誕生。大量のデータを高速で集計・分析(SQLクエリ)するための超巨大なデータベース。普通のビジネスマンやアナリストが、使い慣れたSQLでペタバイト級のデータを一瞬で集計できる。企業のデータ分析が一気に大衆化。

2016年11月: Amazon Athena誕生。S3のデータに直接SQLを投げるサーバーレス・クエリの決定版。S3に置いてあるデータ(CSVやログなど)に対して、データベースに移し替えることなく、S3にある状態のまま、直接SQLを投げて一瞬で集計できるサービス。データはあるけどわざわざデータベース(Redshift)を起動してインポートするのは面倒という常識を破壊。現在のデータレイク(S3に全部貯める)という設計思想を決定づけた主役。

2017年8月:AWS Glue誕生。サーバーの管理を不要にし、Apache Sparkなどを使ったモダンなデータ加工を自動化する、サーバーレスETLとして登場。

2017年11月: Amazon SageMaker誕生。貯まったビッグデータを使って、AI(機械学習・ディープラーニング・生成AI・LLM)のモデルを開発・学習・デプロイするためのオールインワン環境。ビッグデータの最終ゴールを、集計からAIによる予測や生成へとシフト。Glueなどできれいに加工したビッグデータを、そのままAIの学習に流し込むための心臓部。



AWSの進化

  1. 貯める(S3)から始まり、
  2. 処理する(EMR)
  3. 分析する(Redshift/Athena/Glue)
  4. AIで活用する(SageMaker)へと発展してきた

AWSでビッグデータシステムを組む場合、S3 + Glue + Redshift/Athena + SageMakerの組み合わせが王道



Amazon S3が革命的だった理由

以下の条件を、世界で初めて同時に満たしたから。

  • 初期費用ゼロ、使った分だけの従量課金: 数億円の初期投資をせずとも、クレジットカード1枚で使い始められる。
  • API(ネット経由)での全自動操作: 人間がサーバーをセットアップするのではなく、プログラム(HTTPリクエスト)から一瞬でデータを保存・取得できる。
  • 容量が最初から「実質無限」: ユーザー側で「来年はデータが何ギガ増えるか」を予測してハードディスクを買い足す必要がなくなった。



AWS誕生の経緯

IT革命があって、ビッグデータが溢れるようになって、GoogleとYahoo!が頑張って、Hadoopが生まれたから。

詳しくはこれ → 書籍『AI 70年:思考する機械からChatGPTへの道のり』


心理学の成り立ち


哲学の時代
自分の感覚(外部世界)と、知識は一致していた
ヒポクラテスの四体液説みたいな感じ
宗教の教えみたいな感じ(万物は神が創ったものだとか)

ところが、科学や技術が進歩してくると、どうもそうでもないらしいことが判明してきた

医学、物理学、天文学、科学いろいろ
コペルニクス、ガリレオ、ダーウィンとかとか

どうやら自分の感覚を疑わざるを得ないようだ

こうした知識・感覚と事実に矛盾があることから、
人の心の動きを明らかにしたいという学問的欲求、探究心が発生
心理学という学問が萌芽し始める

考えてるだけでは哲学の領域を出ない
科学的学問として成り立たせたい

哲学を科学化させたのはヴントの功績かも

数量化、客観化、機械化、解釈の排除、演繹
誰もが納得しやすい、わかりやすい、結果だけをみればOKというふうにしたい

客観性:再現可能性、反証可能性
信頼性:確実性(手堅さ)、監査可能性
内的妥当性:有意味性、真正性(迫真性ではない)
外的妥当性:転用可能性、一般化限定性


観察者であるか、行為者であるか
目の前で猫がエサを食べているのを
じっと見守って事実を伝えるか
エサを食べさせようとするか

前者がシャルコー
催眠で、体の症状だけでなく、心の症状が引き起こす事態があることを明確にした

後者がフロイト
催眠で治療しようと思った

(2009年3月メモ)



アメリカの成り立ち

中世抜きで発生した国

ピューリタン

  • カトリックとは反対で、ギリシャ・ローマ文明の知識
  • 建物もギリシャ・ローマ風、中世的なゴシックはなし

中世とは

  • 奴隷制度と騎士道
  • 中世ヨーロッパは1,000年かけて奴隷をなくした
  • 戦争のルールが変わった
  • 対等の敵と考えるか、悪者と考えるか
  • 機関銃という無差別殺人兵器に抵抗感を感じるかどうか

モンロー主義

  • 外の世界と関わらない
  • 自国産出の石油を無限に使えるから成り立つ、ただし60年代までだった
  • 70年代からは石油輸入国に(その後シェールガスが出てくるわけだが)
  • OPECや有色人種国にも気を使わないといけない

るつぼ

  • 日本は民族の吹き溜まり:うまく混ざってる
  • アメリカはその前段階なのかも:モザイク的に散らばってるだけ、混ざってはいない



自分の欲望に他律的

政府に賭博を禁止してほしい、あると自分がやっちゃうから

ピューリタンは他律的に抑える

  • オランダの家の、道に面した部屋の窓の広さ
  • 不道徳なことをしていないかを互いに監視
  • デスパレートな妻たちみたいな感じ

プロテスタントと違いカトリックは

  • 自分の罪を告解(懺悔)することで神の赦しが得られると考える
  • スペインの家は、中庭があって、内に開かれている

日本もカトリック的発想

  • 世間様と家の自治
  • 世間の縛りはあくまで家に対して、個人ではない
  • 家制度が活きてる時代は、個人が家に守られてたとも言える
  • だが今は家が守ってくれない、個人に直接攻め込まれる
  • (今の不寛容さは、カトリックからプロテスタントに移行してると見ることもできる)

(2009年1月メモ)


2018年7月1日日曜日

アサガオの数咲き作り

発芽したら
・本葉の6枚目と7枚目の間で摘芯
・双葉も摘む
・1,2,6枚目の脇芽も摘む

3,4,5枚目の脇芽を伸ばしていく

・6枚目の脇芽はグイグイ伸びてくるのでちょいちょい摘む
・子葉の両脇の芽も摘む


・3本ある子づるのそれぞれ2枚目と3枚目の間で摘芯

その後5~6日で孫づるが伸び出し、ここに蕾がつく、らしい

https://www.shuminoengei.jp/?m=pc&a=page_image_slideshow&target_report_id=7213&num=7
https://www.shuminoengei.jp/?m=pc&a=page_image_slideshow&target_report_id=7213&num=8


2018年6月24日日曜日

頻度流とベイズ流

ラプラスの悪魔
自然現象は「現在の位置と状態, そして現象の法則さえ分かれば未来も完璧に予測できる」と考えられていた。 だがしかし、未来を予測するのに必要な情報が足りないときに, 人間は何らかの信念に基づいて予測するしかない。

この主観的な信念を数値化したもの→主観確率

サイコロを振って5の目が出る確率→6分の1(どの目が出るかの条件は1〜6いずれも等しいだろうという信念が前提にある)

信念じゃないものに頼るなら、とりあえず振ってみる、何度も振ってみる。5の目が出た頻度を数え上げる。
過去の実績に基づいてるのが信念よりも確からしそうだし、誰の目から見ても変わらない実績なので信念よりもあてになりそう
→頻度流(頻度に基づいて確率を定義する)

 頻度流統計では最もな尤度のみを用いる→最尤法
 ベイズ流では事前分布+尤度

ただしこの考え方だと試行回数、すなわちサンプルサイズにいろいろ依存することになる。

サンプルサイズをあまり意識しないでよい。
事前確率はひとまず2分の1とでもおく。試行をちょっとずつ観察しながら5の目の出るもっともらしさ(尤度)の情報を得ながら事後確率を計算(更新)していく
→ベイズ流(主観確率に基づいて確率を定義する)


最尤法ではモデルが複雑な場合や、サンプルサイズよりも説明変数が多い場合などに無理があり、対応できない(サンプルサイズよりも説明変数が多いと最小二乗法、最尤法の計算が原理的に不可能になる)。

モデルが複雑になるとデータの最小単位がわかりにくい、サンプルサイズをカウントしづらい、解釈が難しい

厳密な実験計画が前提になっており、ベイズ更新、カルマンフィルタ(センサーなどから得られる情報をもとに機械の状態を把握し, リアルタイムで機械の動きを修正していくという工学の方法論で, 代表例としては人工衛星の軌道制御に応用される)のような後から追加情報が入ってくることを頻度流は想定してない

→頻度流の限界


反対に、ベイズ流の弱み

モデルが複雑で再現性が低い

事前分布をどう設定するかが初学者には難しい
(MCMCのようにたくさん事後確率を発生させるなら事前分布の有意味性が薄れる場合には問題視されにくい)



[教材] 今更だが, ベイズ統計とは何なのか.
http://ill-identified.hatenablog.com/entry/2017/03/17/025625

頻度論 vs. ベイズ統計(後半)
https://healthpolicyhealthecon.com/2015/12/28/bayesian-2/

コインで理解するベータ分布
http://r-tips.hatenablog.com/entry/beta-distribution

ベータ分布の確率密度、下側累積確率、上側累積確率のグラフを表示します。
https://keisan.casio.jp/exec/system/1161228837


600世帯での過去平均視聴率15%→見た人90人、見なかった人510人
(90,510)
この情報は、事前分布(1,1)+(89,509)の事後分布だったと考えることもできる

事前分布(1,1)にそれぞれ足して(91,511)で計算する

ベータ分布Beta(a, b)は「(a-1)回成功、(b-1)回失敗という情報が与えられたときの、二項分布のパラメータpの事後分布」と説明することができます(ただしa,bが非負整数のときのみ)。

ベイズ統計学とベータ分布 
http://www.creativ.xyz/beta-distribution-345