「確率変数」の正体は米田埋め込み - 檜山正幸のキマイラ飼育記 (はてなBlog)
確率変数（random variable, stochastic variable）という言葉の意味が分からない！ と何度か書いています。 2015-05-26 「確率変数」と言うのはやめよう 2015-05-27 「分布、測度、密度」は同じか違うか 2015-06-17 まだ「確率変数」が分からない 結局分からないままでした。「慣れ」の問題かも？ と思ったこともあります。 2015-05-28 「慣れれば分かる」問題 慣れることも出来ませんでした。 最近、「これなら納得できるかな」という解釈に出会いました。 [追記 date="翌日"]最後に分かりやすいマトメを付けました。[/追記] 内容： 「確率変数」はなぜ分からないのか アレックス・シンプソンのアイディア 「確率変数」の2つの用法 確率空間と圏Prob 測度論的確率変数 曖昧な確率変数 前層と米田埋め込み 米田埋め込みとしての確率変
ベイズ確率論、ジェイコブス達の新しい風 - 檜山正幸のキマイラ飼育記 (はてなBlog)
バート・ジェイコブスとコラボレーター達は、現状のベイズ確率論で使われている概念・用語・記法とは異なる、完全に新しい概念・用語・記法を提案しています。悪しき風習やしがらみを断ち切って、理論をリフォーミュレートしたのです。 従来のやり方に慣れている方は、彼らのスタイルに強い違和感を持つかもしれません。しかし、白紙で考えれば、とても使いやすいものです。僕は、ジェイコブス・スタイルを若干アレンジして使っているのですが、ほんとに気持ちよくて、従来方式に戻る気にはなれません。 今日は、その内容の詳細までは解説しませんが、基本概念だけに絞って雰囲気を紹介します（それでもけっこうな長さになりました）。 内容： ベイズ確率論を整理して再構成する 状態変換子と述語変換子 確率的状態 確率的状態変換子とチャンネル チャンネルについてもう少し 状態とチャンネルの実例 ファジー述語 ベイズ論理／ベイズ計算に向けて
古典的微分幾何・ベクトル解析のモダン化： ラムダ記法の利用 - 檜山正幸のキマイラ飼育記 (はてなBlog)
[追記]続きの記事を幾つか書いたので、この記事がハブになるようにシリーズ目次を付けました。[/追記] 微分幾何・ベクトル解析の古い教科書、あるいは古いスタイルで書かれた説明は、とても分かりにくいものです。記法の説明や計算の仕方はちゃんと書いてあるのですが、その記法が何を表すのか？ 計算によって何をしてるのか？ 実体／実状が把握できないんです。 今でも古いスタイルの説明はよく見かけます。それに文句を言うのはやめて（過去、文句を言いましたが(笑)）、古い（古典的／古式）スタイルの記述に、モダンな解釈を与えるにはどうするか、を解説します。 古典的／古式なスタイルは、微分幾何・ベクトル解析に限らず、例えば中学・高校の教育でも使われているので、それを避けるのは難しいでしょう。モダンな解釈、モダンな再定式化を知っておいて損はないと思います。 今回だけでなく、2,3回は書くと思います（たぶん）。とりあえ
もうGitは怖くない： 自信を持って使いたいあなたへ - 檜山正幸のキマイラ飼育記 (はてなBlog)
2014初頭に書いた「WindowsにおけるGit利用環境は整った： Git for Windows と SourceTree for Windows」の最後の文： ブランチは、Gitのなかで最も重要でありながら最も分かりにくい概念でしょう。表面的な言葉に騙されず、先入観を持たず、SourceTreeの視覚的表示（樹形図）の力を借りながら学習するのが、理解への一番の近道です。 そんへんの詳しいことはまたの機会に述べるかも知れません。 1年半以上たってしまいましたが、「またの機会」がやって来ましたよ。ええ、Gitの説明をします、ブランチを中心に詳しく。 「基礎編」と「ブランチ編」で2回に分けようかと思ったけど、長大な記事として一挙公開。これからGitを使う人が対象ではありません。Gitが何をやっているのか、自分が何をやっているのかイマイチ自信が持てない方向けです。 ブランチやマージって、なん
最近のビルドツールって何なの？ - 檜山正幸のキマイラ飼育記 (はてなBlog)
TypeScriptでは、コンパイルが必要です。プログラムをブラウザーとNode.jsの両方で使おうとすると、さらに加工が必要です。ミニファイだの文書も作るだのすると、ちょっとしたビルドプロセスとなるので手作業では辛くなります。 今更Makeでもないよなー、と思い、最近のビルドツールを試してみました。 内容： 流行りすたりが激しすぎる gulpを使ってみる：こんなサンプル gulpのビルドスクリプト タスクランナーってのはビルドツールとは違うのか？ ビルドツールは進化したのか 参考資料： 例題のファイルとコマンドの一覧 ソースファイル 追加の話： gulp問題ひきずり：ウォッチがまたおバカ過ぎる 流行りすたりが激しすぎる 「確かGruntってツールがあったよな」と、インストールと使い方を調べていると、やたらにgulpって単語が目立つんですよね。Gruntのライバルの新興勢力らしいです。 「
bashの $() はやはり便利だ - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕はWindowsでもbash（MinGW/MSYSのシェル）を使っているのですが、Windowsだとwhichの使用頻度が高いなー、と思います。Linux/Unixだと、コマンドはだいたい /usr/bin/, /usr/local/bin あたりに入りますが、Windowsだとアッチコッチに分散するので居場所を知りたいことが多いです。 $ which hg /c/Installed/Python27/Scripts/hg コマンドがインストールされたディレクトリを取るには、 $ dirname `which hg` /c/Installed/Python27/Scripts で、そのディレクトリにcdしたいとき、バッククォートは入れ子にできないですが、$() が使えます。 $ cd $(dirname `which hg`) バッククォートを使わずに cd $(dirname $(wh
ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記 (はてなBlog)
僕は、ソフトウェアシステムの構造や処理の流れを絵で描くのが大好きです。 つうと、「UML図か」とか思われそうですが、UML図には気力が湧きません。 理由1：ナントカ図、カントカ図といっぱいありすぎる。 理由2：オブジェクト指向設計の影響が強すぎる。 UMLから派生したSysMLだと、図の種類も少ないし、オブジェクト指向風味も薄まっているようです。それでも僕には面倒な感じです。「フローチャートをめぐる迷信と妄言と愚昧」にも書きましたが、箱と矢印だけくらいの、少数の要素からなる絵がいいのです。 内容： ロバストネス図 手書きにサイコー バウンダリーとインターフェイス まとめ ロバストネス図 絵にするのは好きだがモノグサである僕にピッタリだと思えるのがロバストネス図です。ロバストネス図の要素は3つしかありません。ユースケース図の要素を入れても5つです。「ロバストネス図の概要」（http://ww
ブラウザが消滅して： APIベースのWeb - 檜山正幸のキマイラ飼育記 (はてなBlog)
「僕らが大好きだったWebはなくなるのかもしれない」において、「Webページ／Webサイトから構成される従来型のWebはなくなるのではないか」と述べました。 ここで、極端な想定として「Webブラウザが消滅してしまった」としましょう。これは、あくまで想定であって、未来予測をしているわけではありません。 汎用のブラウザに代わるのは、個別の機能を持ったアプリ群です。これらのアプリ（の多く）は、通信のインフラとしてインターネットを利用するので、インターネットはやはり必須で重要な存在です。 ブラウザがなければ、Webページから構成されるWebサイトは意味を持ちません。Webサイトはアプリのリモートバックエンドに置き換えられ、Webページはアプリの状態に取って代わられます。 アプリとそのリモートバックエンドは通信をするのでプロトコルが必要です。そのプロトコルは、HTTP（の発展形）がやはり主流でしょう
目で見えるだけじゃなくて、機械可読なデータをくれー！ - 檜山正幸のキマイラ飼育記 (はてなBlog)
奥村先生の論説『「ネ申 Excel」問題』の指摘には強く同感・同意します。僕も、2011.3.11東日本大震災のとき、Web上の情報が目視でしか確認できないもの（画像やPDF）があり困惑しました。この話は、災害時だけのことではなくて、Linked Open Dataの文脈でティム・バーナーズ=リーが叫んでいた「Raw Data Now!」にも通じます。 僕自身に関わる話をしましょう。 僕の今の事務所は低地にあるので、目黒川が氾濫すると浸水の危険があります。次のURLにアクセスすると、目黒川の水位をほぼリアルタイムにグラフ表示してくれます。 http://dim2web09.wni.co.jp/megurocity/obssuii/40220043600000248_suiigraph10.html たいへんにありがたい情報なんですが、水位は画像なんです。次のURLの画像が定期的に更新される
MongoDBの日時 - 檜山正幸のキマイラ飼育記 (はてなBlog)
MongoDBの日時（date型）は、UNIXエポックからのミリ秒だそうです。 http://docs.mongodb.org/manual/reference/bson-types/#date より： the number of milliseconds since the Unix epoch (Jan 1, 1970). ミリ秒はちょっと珍しいかな。UNIXエポックからの秒ならよく使われていて、たとえばこのはてなダイアリーのエントリーIDがそうです。この値は、コマンドラインから次のようにして確認することもできます。 $ date +%s 1381302493 表示された値（秒単位）に000を付ければMongoDBのdate型になります。mongoimportやmongoexportで使う特殊なJSON形式なら、次のように予約フィールド名$dataを使って日時を表すことができます。 {
便利で超強力なWSGIサーバー uWSGI を使ってみよう - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Nginxをダウンタイム・ゼロで入れ替える方法」で書いたように、/usr/local/nginx/ のNginxを version 1.0.13 に更新しました。これとは別に、catyというユーザーアカウントのホームディレクトリ内にNginxをインストールして、Nginx+uWSGIとCatyの実験をしようとしています。 Nginx+uWSGIは、Catyに限らず一般的なWSGIアプリケーションを稼働させる良い環境を提供します。簡単に紹介しましょう。 内容： WSGIとuWSGI なぜ Nginx+uWSGI にしたのか uWSGIについて少し インストール とりあえず動かしてみる ソレナリに動かしてみる プロセスの制御など WSGIとuWSGI WSGI（Web Server Gateway Interface）*1は、Pythonで書かれたWebアプリケーションとアプリケーションサー
Linked Open Data - 檜山正幸のキマイラ飼育記 (はてなBlog)
Linked Data、Open Data、両方あわせて Linked Open Data （LOD）なるものに興味をいだいています。ティム・バーナーズ=リー（Tim Berners-Lee）が2006年に公開した次の論説がことの始まりのようです。 Title: Linked Data Author: Tim Berners-Lee Date: 2006-07-27 (last change: $Date: 2009/06/18 18:24:33 $) URL: http://www.w3.org/DesignIssues/LinkedData.html TEDの動画として、2009年2月のバーナーズ=リーによる公演が採録されています。 http://www.ted.com/talks/lang/ja/tim_berners_lee_on_the_next_web.html Linked
JSONだってハイパーメディア -- JSONハイパースキーマ仕様をなんとかしたい - 檜山正幸のキマイラ飼育記 (はてなBlog)
JSONハイパースキーマという仕様があります。 http://tools.ietf.org/html/draft-zyp-json-schema-01#section-6 この仕様の動機や目的に、僕は強い共感をおぼえます。欲しかったんですよ！ こういう機能。 だけど、JSONハイパースキーマ仕様はダメです。どこがどうダメかを解説するのも建設的でないのでしません。このままでは、ちょっと使えそうにありません >JSONハイパースキーマ仕様。そこで、できるだけもとの仕様を尊重・保存しながら僕の目的に適合するように変更します。 JSONハイパースキーマ仕様では、型システムとして定式化すべき部分と、型システムとは何の関係もない部分がゴッチャになっています。ここでは、型システムに吸収できそうな機能だけを取り上げます。 内容： ハイパースキーマの目的 ここで採用する方式の概要 与えられたJSONオブジェ
MongoDBにJSONオブジェクトを保存するときの注意 - 檜山正幸のキマイラ飼育記 (はてなBlog)
1年くらい前に、MongoDBにJSONオブジェクトをドキュメントとして保存する方法について調べたことがあります。そのまま眠っていた短いメモを公開します。「最新の状況を確認してから」とも思ったのですが、そうするとメモは永久に眠ったままになりそうなので確認してません。という次第で、現状との食い違いがあるかもしれません。 まず、2010年に書いた記事「唐突に MongoDB の話」の「BSON」、「BSONとJSONの違い」という節で次の注意をしています。 BSONは名前も構造もJSONと似てますが、別物です。 BSONを「JSONのバイナリーフォーマット」と思うと大間違い。データモデルが違います。 そのとき指摘しておいたギャップは： BSONの数値は、「32-bit signed integer」、「64-bit signed integer」、「64-bit IEEE 754 floati
“記号の乱用”を実装すべきかもしれない - 檜山正幸のキマイラ飼育記 (はてなBlog)
最近、名前付けとか階層化された名前とかについてシリアスに考えざるを得ない状況になりました。そもそも、ソフトウェアではなんでこんなにも名前が登場するのでしょう？ もちろん、人間はバイト列や整数値による識別には耐えられないので、自然言語に基づく意味的連想を必要とする事情があります。さらに、名前を階層化して小分けにしないと、人間は把握できません。 しかしそれにしても、数学的概念の名前とかだと、名前空間や階層構造で悩むことはそう無いですよね。機械可読な記述や証明だとそうもいかないのですが、人間どうしのコミュニケーションだと、いいかげんな名前の使い方をしてもなんとかなります。 おそらく人間は「用語法／記号法／図示法は、ほんっとうーに方言が多い」や「理解をさまたげるモノ／誤解をまねくモノ、それと対処」に書いた次のような言葉の使用法を受け入れるからでしょう。 バラバラ ズボラ その場限り コンピュータだ
自己関手の圏とモナド - 檜山正幸のキマイラ飼育記 (はてなBlog)
「久しぶりに圏論勉強会」で触れた次のこと： 非対称なモノイド圏という概念 モナドの定義をモノイドとして再確認 これを、お絵描き計算（pictorial calculation）を使ってチャント（になるかな？）説明してみようか、と思いました。こういうことは一気にババッと書き切らないと、ヘタって後が続かないことが多いのですが、残念、本日は厳密モノイド圏の実例で息切れ。でもまー、お絵描きの準備はできたから、いいとしよう。 内容： モナドはモノイドだ -- 言ってるだけ 循環的な状況が恐いけど魅力的 準備：ボックス図からストリング図へ 準備：徹底的に左から右の記法 自己関手の圏End(C) 余談：圏論は、ほぼ計算だけ 厳密モノイド圏 実例：行列の圏 実例：非負の実数 実例：釘にラベルが付いたブレイド図の圏 ほんとに面白いのは モナドはモノイドだ -- 言ってるだけ 実は、「モナドはモノイドだ」とい
順序集合の上でモナドなど - 檜山正幸のキマイラ飼育記 (はてなBlog)
昨日の「またインデックス付き圏が出てきたけど、これはどうなっている？」とかで当てずっぽうを言ってるわけですが、圏論の一般的命題で「だいたいこんな感じかなー？」と山勘で思ったときは特殊例を作って状況証拠ぐらいは集めるようにしています。特殊例として便利なモノとして順序集合があります。順序集合は圏とみなせるので、一般的な命題を順序集合に適用してみると、簡単に確認できることがあるのです。 もちろん、順序集合で成立しているからって、圏一般で成立するとは限りませんが、実験の道具としては使いやすいと思います。id:oto-oto-otoさんが、順序集合を圏とみなす話を書いているので、参考にしてみてください。 順序集合で圏 (1) 〜 (6) 次のような対応があります。 圏一般 順序 圏 順序構造を持つ集合 対象 集合の要素 射 順序 x≦y 恒等射 反射性 x≦x 射の結合 推移性 域 順序 x≦y の
圏と関手をできるだけ簡単に書き下す方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
スピヴァックの関手データモデルでは、圏の表示が重要な役割を果たします。なにもスピヴァック理論にかぎらず、圏一般において表示は重要です。特に有限表示（finite presentation）は、我々人間が手で圏を書き下す唯一の方法と言っていいでしょう。そこで、圏の有限表示について考えてみます。 圏の有限表示とは、“ノードの個数”も“辺の本数”も有限な有向グラフと、有限個のパス同値関係（path equivalence relations）の組です。パス同値関係とはスピヴァックの用語で、普通に言えば可換図式です。 圏の有限表示を絵、つまり実際の有向グラフで描けば視覚的に把握できていいのですが、いつでも絵を描くのは面倒です。テキストによる表現を考えます。方針は次のとおり。 キーボードのタイピング量を減らす。 見た目が割と自然になるように。 次の記事で書いたことが背景になっています。 有向グラフを
多品種少量データとMongoDB - 檜山正幸のキマイラ飼育記 (はてなBlog)
MongoDBは、よく知られているように、ジョインもトランザクションもサポートしてません。これは確かに不便なこともありますが、欠点・弱点というよりは、最初からそのように設計されているもので、ひとつの設計判断です。パフォーマンス、スケーラビリティ、耐障害性、分散化の容易性などをより重要視した結果でしょう。 MongoDBの特徴を見ると、大規模なデータセットを高速にハンドリングするためにチューンされているように思えます。しかし、それとは違った場面で使える機能性も備えています。それは「ユニオン型を自由に扱える」ということなんですが、地味であまり言及されないし、ちょっと分かりにくいところもあります。でも、この特徴は、僕にとっては嬉しいものです。ちょっと説明してみます。 ジョインとユニオン SQLDBはジョインができます。ジョインとは、“直積”と“等式的条件による絞り込み”の組み合わせです*1。等式
スキーマとインスタンス -- 一般関手モデル - 檜山正幸のキマイラ飼育記 (はてなBlog)
スピヴァックの関手データモデルは、実に示唆に富んでいます。スピヴァックのアイディアは、データモデルに限らず、ソフトウェアシステムのさまざまな側面のモデル化に使えそうです。 関手データモデルの要点を簡略にまとめるなら： （データベース）スキーマは圏である。 （データベース）スキーマの制約は可換図式である。 （データベース）スキーマの全体は“圏の圏”である。 （データベース）インスタンスは（データベース）スキーマからの関手である。 （データベース）インスタンスのあいだの準同型射は自然変換である。 括弧のなかに入れた「データベース」を他の言葉で置き換えてもこの発想は通用します。実際の適用例はいずれ出すつもりですが、まずは、この発想の一般的な枠組みをハッキリさせておきましょう。 スキーマは圏なので、S, T のようなイタリック体文字で表すことにします。“スキーマの全体”もまた圏を形成しますが、個々
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
