Archive for 11月, 2012

最近、ちょっとこのように思うようになってきました。
「自分の大学卒論を見てみたい」
と。

確か、題名は
「多変量解析を用いた筆跡認証」
だったと思います。

Javaで初めてまじめにコードを書いたのですが、
遅すぎてまともに動かず、C++Builderでコードを書き直したのを覚えています。
N次元微分方程式を解くコードです。

はっきりいって、目的よりも手段がやりたかったので、
結論までの過程はかなりこじつけて書いているので、
内容は今読んでも乏しいと思いますが。

最近、確率とか解析みたいなことをちょっと個人的に思い出しながら調べていたら、
たまたま、この論文を書いたときの本を見つけて、
改めて読んでみると、
結構難しいことが書いてあるわけです。
そして、そこには「ベイズの定理」なんかもあり、

あれー、これって以前やったんだっけ?
それとも、無視したんだっけ?
あのときは、自分が何がわかっていたんだっけ?
なんか、内容よりも当時の記憶を呼び覚ましたら、なんかいいことあるかも?
(っていうか、このもやもや解消したい!?)

と思うようになったのですが、
だから、そのときの記憶を呼び覚ます資料として、自分が書いた卒業論文を見てみたいなーと思うわけです。

当時は、クラウドストレージなんてありませんし、紙で数年は取っておいた記憶もあるのですが、
引っ越し、引っ越し、そして、FDDの衰退(当時はFDDに保存でしたから)で、
いつの間にか、行方不明(というか、ゴミとして処理されてしまったか?)

まあ、修士論文でもなければ、博士論文でもないので、
大学側にとってはゴミなんでしょうけど・・・

あー、もったいない。
「だんしゃり」も考え物ですよね。

Brane CollaborationにDropbox連携を実装してみました。

どのような感じに使えるかと言えば、
WEB上の管理ツールから、ファイルをDropboxへ送り、それを更新して、
Dropbox上から管理ツールへ返す。
というような感じです。

1)登録されているファイルをチェックアウト時にDropboxに送る

DropboxへOAuthを使って許可を得ていない場合には、上記図の「Dropboxに接続する」のリンクをクリックすると、
Dropboxへ接続します。
ちなみに、このアプリケーションはDropboxのApp Folderというのを使っているのでそのフォルダ以外見えません。

2)チェックアウトをすると、自分のDropboxにファイルが追加されます。

そして、このファイルを編集していくわけです。
このとき、実はPHPのDropboxのライブラリの都合(というかPHPの)で、ファイル名の先頭に日本語があると、
ただしく、日本語ファイルを扱えません。
従って、あたまに数字を付けています。

3)チェックアウトしたファイルつかって、チェックイン(ファイルの更新)をする。

チェックアウトしたときにどのファイル名にしたかわかっていますから、
チェックイン(ファイル更新)時には、そのファイル名をDropbox上から取得して、ファイルを更新します。

これで、もうファイルのダウンロードとアップロードをしなくても、ファイルの更新をしていけます。
自分用のファイルシステムとしては、これで十分になってきました。

難点は、Dropboxへのアップロードとダウンロードが遅いことです。
ちょっとしたワードやパワポ、エクセルなんかのファイルは大丈夫ですが、
多少大きなファイル(数M以上)になると、固まったようになってしまいます。

ちなみに、Dropbox上からファイルを消してしまうと、

のような感じに、消されてしまっている事もわかります。
この場合には、再度Dropbox上へファイルを送ることも出来ます。

やはり、ファイル管理をするにしても、ブラウザだけではあまりにも使い勝手が悪いので、
DropboxのAPIを使い、連携することを検討中です。

要は、SubversionやGitをエンジニアが使っているときに、
ローカルのファイルシステムにチェックアウトする感じで、
ブラウザからクラウドストレージにチェックアウトするようにすれば、
結構、使えるのではないかと・・・・

ということで、DropboxのAPIについて申請をしてみました。

APIを使う場合には、まず、自分がDropboxのアカウントがなければなりません。
そして、
https://www.dropbox.com/developers/apps
から、つなぐアプリケーションを申請します。

今回は、このApp Folderという方を選択してみました。
せっかく、Recommendedと書いてあるからそうしようというレベルです。

で、申請した結果の内容はといえば、

この状態で、実際にAPIを使ってみると、

のように自分のDropboxにApps/Brane Collaborationのように作成されており、
このフォルダに対して、ファイルのアップロードやダウンロード等の操作ができるようになります。

ちなみに、設定のName of App Folderの名前と実際のフォルダ名がちがうじゃないか?
と気がついた方もいるかもしれませんが、こちらは私の方が後で変えました。
OAuthのレベルで成功したらフォルダができあがったのですが、フォルダにアクセスするとエラーがでるので、
半角スペースのせい?と思って変えたり・・・とちょっと試行錯誤してみた結果、変えてみたものの・・・

でも、それがいつ、どうやったらDropbox上に反映するのかがわかりません。。。。。
(まあ、結果的にこの違いはAPIのコード上に出てこないみたいなので、今は無視・・)

ちなみに、App FolderタイプのAPIの場合には、APIでの指定はsandboxになります。

root The root relative to which path is specified. Valid values are sandbox and dropbox.
のように記述があるのですが、これでsandboxを指定します。

App folder access type
The default root level access type, app folder (as described in core concepts), is referenced in API URLs by its codename sandbox. This is the only place where such a distinction is made.

と、https://www.dropbox.com/developers/reference/apiに書いてあったのですが、
これに気がつかず、アクセスで多少は待ってしまいました。
(というよりも、問題が解決してから、この記述が意味する内容がわかってきました。)

ようはフォルダ名の指定なし = Apps/Brane Collaboration になるわけです。
(実際に疑問に思った人しかわからない表現かもしれません。)

もう少し、整理がついてから、実際にPHPを使ったDropbox APIを紹介できればと思います。

前回の、「数学:考えを変えると勝率が変わる?
での、「モンティーホール問題」ですが、何名からやっぱり、理解できない(し、あんな理屈読みたくもない)という話をもらいました。

まあ、そうですね。
私も、あの事後確率理論を説得させる自信もありませんし、理解しているとも思ってもいません。

なので、自分で実験してみたいな-とおもっていて、
ちょっと作成したのが昨日のものです。
ですが、作っている最中に、選択を変えれば1/2ではなく、2/3の確率に上がることはわかりました。

つまり、これは視点の逆転が必要なわけです。
受け手にとっては、「ある事象(1/3の選択)」から「次の事象(1/2の選択)」に移ったときに、
確率は変わるのか?そのときに、どう変わるのか?また、どうして変わるのか?
という話になります。

しかし、相手に平等を装って出し手がいかに得をするか?
ということを考えてみてはどうでしょうか?

つまり、これはマジシャンが使う、「ミスディレクション」の技であると解釈するのです。

たとえば、ギャンブルでのディーラーとプレイヤーの1対1の対決とします。
ギャンブルでは確率的にディーラーが得をするようにしなければなりませんが、
かといって、プレイヤーが必ず負けてもいけませんよね。
(これではやる気を失っていまいます。)

つまり、プレイヤーは、選択を変えられないようにしましょう。
これで、常に、理屈では1/3の確率で負けることが確定しているユーザにするわけです。
それを確かめます。

まず、カード3枚が場にあります。

プレイヤー)任意の1枚を選びます。
コンピュータ)残りの2枚から1枚のハズレを場から取り下げます。
ディーラー)残った1枚がディーラーが選んだカードに自動的になります。

とこんなルールのようになります。
あれ?
コンピュータなんて役割が出てきてるぞ。
変じゃないか?
と思った感覚は正しいです。
しかも、プレイヤーか、ディーラーかの一方が必ず勝つように、
必ず「ハズレ」を下げるのです。
ここで、「アタリ」を下げる事があれば、また違いますよね。

つまり、言ってみれば、
「ディーラーは」は3枚の中から2枚を選んでいることと同じになります。
だって、コンピュータだってディーラーとグルなのは、ギャンブルの仕組み上当たり前です。
だったら、ディーラー側は2枚選んでますよね。確実に。

ここでのミスディレクションのポイントは、
「コンピュータが必ずハズレを引く」という言葉を使って、
ディーラー側に荷担しているにもかかわらず、平等を装っている点です。

もちろん、嘘はついていません。
示したルールもディーラー側は破ってもいません。

どうでしょうか?わかりやすくなりましたか?

最後に、
この問題は「受け手にとっての確率」と考えれば、
現在のビックデータ時代のデータ最適化ととらえる事が出来ます。

しかし、今回のようにミスディレクションというように考えると、
インターフェースの最適化ととらえる事が出来ます。
つまり、余計な(だけど嘘ではない)情報がいかに、人の直感を惑わせるか?
という事を考えた上で、必要最低限な情報で、正しい方向へいかに導くか?ということです。

まあ、

の本を読んでみたので、ちょっと別の方向から考えて見ました。

今回は確率の話です。

まずは、下のゲームをやってみてください。
このゲームは、黄色い「WIN」があるカードがどこにあるかを当てるゲームです。
(決して、WINと出たら当たりではありません。紛らわしいかもしれません。)

ルール)
1)3枚の中からすきな1枚を選んでください。(クリックです)
すると、自動的に残りの2枚から、1枚はずれ(LOOSEと表示されます)がオープンされます。
2)残った2枚の中から、あたりと思う方を再度選んで(クリック)ください。
 つまり、同じカードを再度、選んでもいいですし、変えてもかまいません。
3)そして「決定」ボタンを押してください。(再度クリックしても「決定」と同じ動きをします。)

これで、「WIN」のカードの場所が表示されます。

さて、ここでクイズです。(ここが本題)
2)で、カードを変えた方がいいのか?それとも変えない方がいいのか?
もちろん、確率の話です。

やってみて、わかったでしょうか?
答えは
「カードを変える」
です。
(やってみても、むしろ変えた方がいいぞ!とか、変えた方にしかならないぞ?とかは、
私の意志ではありません。JavaScriptでロジックを組んでいるので、ソースを見ればわかります。
間違いがどこかにあったらおしえてくださいね。。。)

カードを変えない場合の勝率が”1/3″として表示され、
カードを変えた場合の勝率が”2/3″として表示されます。
(実際に、その通りになっているでしょうか?)

不思議だなーと思ったでしょうか?
そうですよね、不思議ですよね。

これは、「NUMBERS 天才数学者の事件簿」という話に出てきます。

たとえば、何も考えていなければ、
2つからの選択になるので、確率は50%なわけです。
しかし、事前にどれを選ぼうか目星を付けておけば、その勝率が66%まで上がるという訳です。
でも、そんな意志があるか?ないかで確率が変わってしまうなんて、あり得るのだろうか??

まあ、上の説明も「刷り込み(意図的な誘導)」なのですが・・・・
どうしても、納得できないという方は上のゲームを何度もやってみてください。
(クリックだけで、何度も実行できるようにしています。ボタンを押すのは面倒なので・・・)

この問題「モンティホール問題」というらしいのです。

それに、理解できなくても、関係ないな-と思う方はちょっとその考え方は変えた方がいいです。
それが「ベイズの定理」とも関係があるからです。

あれ、「ベイズ」ってきいたことあるなーと。
どうやら、「ベイズ」さん、今後のビックデータ時代にとっても重要な人みたいです・・・

ちなみに「NUMBERS 天才数学者の事件簿」では、メールのスパム振り分けの理論なんかも出てきて、
やはり、コンピュータエンジニアには、楽しみながら「あれってどうやってるの?」をどう調べたらいいかわからない。
と思っていたことがわかるかもしれません。

現在、作成しているコラボレーションツールですが、
今は、ファイル管理を作っています。

グループウェアでファイル管理がありますが、あまり使い勝手がいいものではありません。
まあ、WEBでファイルを見せても、あまり使い勝手がいいものではありません。
しかし、ファイルシステムはファイルシステムでファイルのメタ情報管理が乏しいし、それに階層構造にとらわれてしまい、
こちらは管理の観点からすると都合が悪いことも多々あります。

ということで、まずはWEB側の得意なメタ情報を管理できるようにしようということで、

とこんな感じにしてみました。
まだまだ、ダミーの部分も多々ありますが、いわゆるMicrosoftのOffice Open XML形式のファイルなら、
その中にある情報も自動で表示しています。
こちらでも多少、記述しましたが、
Wordのサムネイル画像はdocxの中にあるthumbnail.wmfファイルをSVGにして表示しています。
(なので、IE8とかではみることができないかも知れません。(未確認))
画面からは見えませんが、コメントも記述できます。

あと、ちょっとかわったところでは、複数のファイルをパッケージとしてまとめることができます。

このパッケージという機能は、例えば、いくつかのドキュメントを「201211ミーテリング資料」のようにフォルダでまとめますが、
これだとどうしても、その中のファイルをほかのフォルダにも置きたい場合にコピーするか、リンクをつくるか?
ということになりますが、このパッケージという形でこれらをフォルダとは別にまとめることができるようにしました。
これで何がいいかと言えば、「ダウンロード」ボタンでまとめてzipにてダウンロードできます。
パッケージを作成する際に、zipのパスワードをつけようと思いましたが、こちらはPHPで作ってみたら激遅で、
ちょっと保留です。
後は、ファイルの関連性がつけられますので、あとあと、それらに応じた表示もできるようにしたいものです。

できれば、ここからDropboxやSkydriveみたいなネットワークドライブと連携してファイルの更新ができるようにしたいとはおもっているのですが、
そこにはちょっと時間がかかりそうな雰囲気です。

最近、電車の中で

を見ています。
といっても、DVDではなく、ドコモのビデオサービスですが・・・
これを夜のうちにスマホにダウンロードしておいてみるのが最近の電車の中での暇つぶしです。

プログラムをやっているエンジニアにはちょっとおもしろいんじゃないでしょうか。

なんかストリーが進むに従い、数学の役割が減ってきている気がしますが、
「数学」というものの「わかりやすさ」と、「わかりにくさ」を伝えている気がします。

まず、「わかりやすさ」ですが、
これは、何事も数学が関連しているんだよー。ほら、こうね・・・・
そして、こうして、次が見えるでしょ!

って、これをみてへー、すごい。
と思うのもいいのですが、
私が見てほしいのは、「わかりにくさ」です。

事件が次に何処で起きるか?いつ起きるか?どうやってそれを防ぐか?
これがみんな(ドラマの中のFBIの捜査官)は知りたいわけです。
当事者であれば、それが当然なのですが・・・・

よく、システムトラブルでもききますよね。こんなセリフ。
「原因なんてどうでもいい、いったい、いつ、トラブルが直るんだ。」
似てますねー。

でも、残念ながら、「数学」は直接は教えてくれません。
天気予報も地震予報も株価予想でさえ数学はできる(正解率はあるが・・・)のに、
この事件では、「数学」は答えを教えてくれないよ。
だって、原因がわからないんだから・・・・
だから、「原因(原点)」を探そう。
ここまでは、よくきく話です。

でも、このセリフ(ニュアンスだけです。実際のセリフは覚えていません。)はいいなと思いました。
現象(未来)とは「原点(原因)」からの「拡散」である。
だから、「拡散」の傾向から、次の「拡散」を探すのではなく、
「原点」を探す必要があるのだ・・・・
というような事を言うわけです。

数学者は、事件から何が有効な「データ」なのか?
を探し、そして、「キー」となるポイントを探す。
そして、「キー」から、理論を作り、仮説を作る。

そこからは、数学者のお兄さんでもあるFBIの捜査官が、
経験と勘をたよりに現実問題を解決する。

というのがたいていの話の「軸」です。

余談ですが、結局はKK(経験と勘)さえあればいいという話を聞きますが、
それが正しかろうが、間違っていようが、
それに乗ってしまっては、相手の思うつぼですよ。
だって、言っている人と言われている人ではKKは言っている人の方があるのですから。
つまり、自分を絶対抜かせないセリフが「結局はKKがすべて」なのですから・・・
時間が平等なのでしたら・・・

さて、
学校で習う「数学」というのはたいていは、
仮説(といっても現実解だと証明されたもの)から、
答えを導く訓練をしてきているだけなので、
数学を見る視点が逆なのです。
だから、すごく「数学」がわかりにくいのだと思うのです。

「答え」を導く処理をするのが、「数学」なのではなく、
「答え」から「原因」を導くのが「数学」の醍醐味なのです。
「その逆もしかり」の部分を学校で勉強していて、そこがすべてだと思い込む訳です。
(しかも、それすらわからない。し、そもそも答えを求めてないし・・・だれが、楕円の表面積を知りたいんだよ・・ってね。)

でも、実際の生活の中では「答え」も「原因」も確認(検証)できないままに過ごすことの方が多いわけです。
それに、宝くじに当たる確率の方が、交通事故に当たる確率よりもだれだって高い訳です。気分の上では。
理論上当たらないなんていう都合悪い理論を知ったところで何もいいことはないのです。

だからこそ、数学を使って「仮説」「実行」「検証」「予測」を訓練するのだと思います。
この一連の具体的な方法例を示してくれるものって少ないですよね。
自然現象は自分にとって都合よいも悪いもそれほどないですから。

んーそれって、いわゆるPDCAサイクルってやつでしょ。
社会人になると「上司」がうるさくてさ・・・

ほら、マネジメントモデルでさえ、数学と関係があるってわかりました!?
数学がそう見えるようになったら、もうこう言えますね。
「あーPDCAね。それは中学生の時の必須項目でしたね。」ってね。

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2012年11月
« 10月   12月 »
 1234
567891011
12131415161718
19202122232425
2627282930  

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ