$mogrify -quality 85 *.jpg
ただし一度プレビューで品質下げて書き出すなどしたのを改めてやると、ファイルサイズが大きくなることもある
コマンドで画像を一括処理! ImageMagickの便利な使い方
https://liginc.co.jp/394506
画像を最適化する
フォルダ内のjpegファイルをjpgにする
for file in *.jpeg ; do mv $file ${file/%.jpeg/.jpg} ; done
Pythonでコレポンをやる
略してコレポン
point
Rの場合
library(ca) ca(table.T)plot(ca(table.T))Pythonの場合
python -m pip install mca理論的には、行・列ともにカテゴリデータの頻度表(人数、出現数などのcountデータ)を対象としている
コレポンをよく使う場面
他に、
比率表(回答者数全体に占める割合、%データ)のデータセット
# 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()
(2026年5月更新)
1990年代 インターネットの商用化、Web検索サービスの登場、パソコン/携帯電話/デジカメ/ビデオゲームの普及。ゴードン・ムーアが1965年に予測、のちに修正・確立されたムーアの法則を自己成就するかのごとく集積回路は細密化、需要拡大を伴って、情報処理能力、伝送容量、記憶容量のコストは劇的に低下した(IT革命)。
急速な進化の時期: 1990年代〜2000年代前半
ムーアの法則(半導体の性能が約2年で2倍になる)が一番ハマっていた時代。Windows 95が出た1995年頃のCPUのクロック周波数は100MHzくらいだったのが、2000年代に入るとあっという間に1GHzを超えた。処理速度が数十倍〜数百倍に跳ね上がった。
急速な進化の時期: 2000年代前半(2001年〜2005年頃が特に激変)
ダイヤルアップ接続(ISDNなど)は画像1枚開くのにも時間がかかっていた。ADSLや光ファイバー(日本や韓国の場合。ヨーロッパではADSL アメリカではCATV)といったブロードバンド(高速大容量通信)が一気に普及して、通信速度がkbpsからMbpsのレベルに一気に跳ね上がった。
急速な進化の時期: 1990年代後半〜2000年代
巨大磁気抵抗(GMR)効果の技術がHDDに応用されて、ハードディスクの容量はMBからGBへ突入。2000年代後半には垂直磁気記録方式の恩恵により、TBへと爆発的に増えた
言葉の誕生は2000年前後。学術的な論文やデータマイニングの専門家の間で、管理しきれない巨大なデータ群を指す言葉として「Big Data」が使われ始める。
ブロードバンドの普及と記憶容量の増大により、従来のシステムでは管理、処理しきれないほど巨大な膨大な複雑なデータがもたらされる。
Googleは2000年代前半、膨大なウェブデータを処理するために自社開発した画期的なインフラ技術を、以下の3本の論文として相次いで世界に公開。のちのビッグデータ技術の基盤となった。
Googleがこれらの仕組みを論文として理論(設計図)だけ公開したため、世界中のオープンソース開発者たちが、自分たちでも使えるように同じものを作ろうと動き出した。
そうして2006年に生まれたのがHadoop(GoogleのGFSを真似たHDFSと、MapReduceを真似たHadoop MapReduceのOSS版)。Hadoopが開発されたことで、安価に大容量データを扱える土台が整い、Google以外の一般企業でもビッグデータ分析できる時代が到来。
Hadoop(HDFSとMapReduceのOSS版)を開発したのは2人のエンジニア、ダグ・カッティング(Doug Cutting)とマイク・カファレラ(Mike Cafarella)
2人はもともとオープンソースの独自のWeb検索エンジン(Nutchプロジェクト)を開発していた。しかし世界中のWebページを集めて検索インデックスを作るには、データ量が多すぎて個人のPC環境では限界を迎えていた。
そこへ前述のGoogleの論文(GFSとMapReduce)が公開。衝撃を受けた2人は、この仕組みをオープンソースで真似すれば、自分たちの検索エンジンも巨大データを扱えるようになると考え、Java言語を使って独自に実装し始めた。これがHadoopの原型。
とはいえ、個人での開発には実験用のサーバー代や資金の限界があった。そこに目をつけた、当時Googleを猛追していた米Yahoo!(Yahoo! Inc.)は、2006年 ダグを自社に雇用し(マイクは大学院で研究しながら外部からサポート)、潤沢な資金と数千台規模の検証用サーバー群を提供して全面支援。
Yahoo!の強力なバックアップを得たことで開発は一気に加速、急成長。検索エンジンの一機能から「大容量データを分散処理する共通基盤」として切り離され、独立したプロジェクト「Hadoop」に。
Yahoo!での開発が進んだ2006年、非営利団体であるApacheソフトウェア財団(Apache Software Foundation)にプロジェクトは寄贈。
Hadoopは特定の企業が独占する商用製品としてではなく、誰でも無料で使えるオープンソースソフトウェア(OSS)として世界に向けて正式に公開。
Hadoop: ダグの子供が、お気に入りの黄色い象のぬいぐるみに付けた名前が由来。Hadoopの公式ロゴに使われている。
巨大なデータを、安価に、壊れないように保存するための仕組み。
安価な構成: 特別な高級ハードウェアではなく、普通のハードウェア(サーバーやハードディスク)を大量に並べて巨大な保存スペースを作る。
自動バックアップ: どこかのハードディスクが1台や2台壊れてもデータが消えないよう、自動的にデータを3つ以上の場所にコピーして保存する仕組み(レプリケーション)を持っている。
| 特徴 | GFS / HDFS(オンプレミス型) | Amazon S3(クラウドネイティブ型) |
|---|---|---|
| 実体 | 自分たちで用意した「サーバー(CPU+ハードディスク)」の集まり。 | AWSが管理する、インターネット経由の「純粋なデータ保存スペース」。 |
| 拡張方法 | 容量が足りなくなると、サーバーを丸ごと1台買い足してネットワークに繋ぐ作業が必要。 | ユーザーは何もしなくてよい。データを入れれば入れるだけ、容量が無限に自動拡張される。 |
| 計算方法との関係 | データを保存しているサーバーそのものに計算(MapReduceなど)をさせる。 | 保存に特化している。計算するときは、別の計算用サーバー(EC2やEMRなど)を必要な時にだけ起動してS3に接続する。 |
大量のデータを並列で処理・加工する役割
大量データの並列処理: 1台のコンピューターでは処理できないテラバイト・ペタバイト級のデータを、数百〜数千台のマシンに分散して同時に計算する。
データの変換(ETL): 散らばった生データ(ログやCSVなど)を読み込み、きれいに整えて、分析しやすい形に変換して別の場所(S3など)に書き出す。
| 特徴 | MapReduce(原典/Hadoop) | Amazon EMR / AWS Glue(現代のAWS) |
|---|---|---|
| 処理のスピードと仕組み | データを処理する際、一工程ごとにハードディスク(ストレージ)への書き込みが発生するため、処理が遅い。 | EMRやGlueの主流である「Apache Spark」は、データをメモリ(RAM)上で処理するため、MapReduceより最大100倍高速。 |
| サーバーの管理 | 処理をするために、常に数千台のサーバーを自前で起動・維持しておく必要がある(使っていなくても電気代や管理費がかかる)。 | EMR: 処理するときだけ自動で数百台のサーバーを起動し、終わったら消せる(使った分だけ課金)。Glue: サーバーの存在すら意識しない(サーバーレス)。 |
大量のデータから特定のデータを一瞬で読み書きするデータベース
超高速レスポンス(低レイテンシー): データ量がペタバイト級に増えても、アクセスが1秒間に数百件〜数百万件に激増しても、常に「1桁ミリ秒(1000分の数秒)」という超高速でデータを返す。
NoSQL(キー・バリュー型 / ワイドカラム型): 行と列でガチガチに固められた従来のRDB(SQL)とは違い、特定のキー(鍵)を指定して一直線にデータを取り出す仕組み。データの構造(項目)を後から自由に追加・変更できる柔軟性を持っている。
| 特徴 | Bigtable(Google原典) | Amazon DynamoDB(AWS) |
|---|---|---|
| データの管理単位(アーキテクチャ) | ワイドカラム型: 巨大な1つのスプレッドシートのような構造。データは「行(Row Key)」ごとにアルファベット順で並べられて管理される。 | 進化型KVS(ドキュメント/ワイドカラム対応):基本の骨組みは、列を後からいくらでも横に広げられるワイドカラム型(KVS)。その中にJSONのような複雑なデータの塊(ドキュメント)をそのまま丸ごと放り込める柔軟な構造に進化。 |
| 運用のハードル | 安定して高速に動かすためには、最低でも数台(できれば数十台)のサーバー(ノード)をクラスターとして維持する必要があり、初期コストが高い。 | 完全サーバーレス: データの読み書きの回数や、保存したデータ量だけで課金される。小さな個人アプリから、Amazonのプライムデーのような超巨大イベントまで自動で伸縮する。 |
鍵(Key)と中身(Value)がペアになって保存されている、非常にシンプルなデータ構造のこと。コインロッカーのようなイメージ。
従来の一般的なデータベース(SQL)は、Excelのように列と行が複雑に組まれており、データを検索するときは「A列が〇〇で、かつB列が××のデータを上から順番に探す…」という複雑な探索(計算)をする。そのためデータが増えると重くなる。
一方、DynamoDBのようなキー・バリュー型は、「105番のロッカーを開けて」と指示するだけ。データが100万件あろうが1億件あろうが、目的のロッカーへ一直線に向かうため、常に一瞬(1桁ミリ秒)でデータを取り出すことができるのが最大の強み。
DynamoDBは、ロッカーの中に入れる「バリュー(荷物)」の形として、JSONという書類(ドキュメント)のような複雑な階層構造のテキスト形式をそのまま丸ごと放り込める柔軟性(ドキュメント型としての特徴)を、ワイドカラムな骨組みの上に持たせている。
ワイドカラム型は、ロッカーの中にさらに細かく仕切られた小さな引き出し(カラム)が大量に並んでいるイメージ。鍵(行キー)でロッカーを開けたあと、3番目の引き出し(列)のデータだけを読み込むことができる。そして引き出しは10個だったり100個だったり、後からいくらでも横に広げる、ワイドにできるためワイドカラム型と呼ばれる。
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でビッグデータシステムを組む場合、S3 + Glue + Redshift/Athena + SageMakerの組み合わせが王道
以下の条件を、世界で初めて同時に満たしたから。
中世抜きで発生した国
政府に賭博を禁止してほしい、あると自分がやっちゃうから
(2009年1月メモ)
錯覚とは、知覚された対象の性質や関係が、刺激の客観的性質や関係と著しく食い違う現象
認知 cognition:知的な心の情報処理。知覚、記憶、思考(推論、問題解決、意思決定)、注意、学習、、、
錯視いろいろ
我々は
解が定まらない不良設定問題
奥行き知覚の手がかり
クレーター錯視
恒常現象 constancy phenomenon
知覚とは
子供の絵の特徴
歴史的観点で考えると、古代や東洋の絵も完全恒常の世界を描いていると言える
大きさの恒常性の克服
印象派の登場
写実派:見たままに描く
キュビズム(立体派):多視点性、複数の視点がねじ込まれている
トロンプ・ルイユ(だまし絵)
絵の中に影を描く→絵の中に空間が生まれる
記憶の誤情報
記憶インプランテーションの特徴と仕組み
記憶のメカニズム
記憶の錯覚が起こる仕組み
考え方の二つのタイプ
たいていの人は確証の方を試みる(自分の考えが正しいはずだという思考になっている)
確証バイアス confirmation bias
肯定性バイアス
錯誤相関(幻相関) illusory correlation
ポジティブ・フィードバック 予期の確証
クリティカルシンキングのためのポイント
大数の法則 law of large numbers
利用可能性ヒューリスティック availability
アンカリング(投錨)と調整 anchoring and adjustment
認知的不協和理論
戦略
入会儀礼、通過儀礼の実験
おもちゃで遊ぶことに厳しい罰を課す
平均への回帰 regression の錯誤
身近に入り込む回帰の誤謬 regression fallacies
単なる統計的回帰に、複雑な因果関係を想定してしまう
回帰が認識されやすい課題
前後論法
以前はaだったが、以後bになった
前後論法における変化要因
原因帰属推論には偏りが生じる、錯覚が起きる
原因は心理的に決定する、目立つものに注目してしまう
原因帰属 attribution
ケリーの立方体モデル:四分割表の発展版
全領域の情報を集めるのは大変
原因帰属の錯覚
学習性無力感(セリグマン)
物事が失敗した時の説明スタイル(どこに原因を求めるか)
情動と身体的整理変化・興奮
情動二要因理論 two-factor theory of emotion
情動ラベリング 情動が認識される
血液型性格相関説の歴史
ラベリング効果
フリーサイズ効果
性格的中の錯覚
疑似科学
科学の要件 反証可能性 falsifiability
疑似科学の兆候
宏観異常現象
疑似科学の問題点
ポジティブ幻想 positive illusion
日本人の場合
軽い鬱は現実主義的、たいていの人は楽観的に現実を錯覚している
精神的な健康形成にはよく役立っている、ストレスに強い
日本人のイリュージョン
男性は自身を過剰評価しやすい、女性は過小評価しやすい byシェリル・サンドバーグ’s TED 2010
計画された偶発性(運、よい偶然を引き寄せるには)J. Krumboltz
錯誤には意味がある
人の認知システムに働きかける原則
錯覚とのよりよいつきあいのためにはメタ認知