2006-03-25[n年前へ]
■「男と女のデート大戦略（アルゴリズム）」をプログラムで語るスレ 
Tech総研ブログ 平林 純@「hirax.net」の科学と技術と男と女に「男と女のデート大戦略（アルゴリズム）」をプログラムで語るスレ 〜 オープン・ソースで「デート」支援 〜を書きました。
「男と女の間のデート戦略アルゴリズム」をプログラム言語で考えてみょう！という、ぽいんつさんをリスペクトしつつ（インスパイアされた）話です。プログラミング言語でデート戦略（シナリオ）を書けば、デートの作戦や考え方や(自分が予想する)相手の対応がすっきりわかりやすくなるでしょうし、何より面白そうです（理系的には）。
「誰もが活用できるデート戦略（アルゴリズム）」をオープン・ソースで開発してみることにしましょう。
float Men::interest(Person *one) { if( type==OPPAI_SEIJIN ) // 胸星人 retrun one->bust; // 興味は相手の胸の大きさが全て… }
float Women::judgeOne(Person *men) { switch (mensInterest)){ if(OPPAI_SEIJIN) return HATE; else if (PERSONALITY) return LIKE; }
double dispatchingで実装した方がいいのでしょうが… あくまで自立オブジェクトとして考えなくてはならないところが難しい
オブジェクト間での、コミュニケーションが上手くいくかどうかの問題にも繋がってきそうな。つまり、相互作用における相互参照に不正確・不確実さが入り込んでくる…という。
でもって、コミュニケーションに不正確・不確実性・確認の困難性が入り込んでくる場合、double dispatch がそもそも可能か…
2007-08-23[n年前へ]
■WIKI+画像処理
空いている時間は、テスターのアドバイスを参考に、「WIKI+画像処理」アプリをスケッチし直している。このアプリは、一番最初にノートにアイデアを描いた時は、"Cinderella Magic"という名前だった。だから、そのイメージを忘れないように、今でも隅っこにこんな文字を入れ込んである。
A dream is a wish your heart makes. If you keep on believing, the dream that you wish will come true.当初は、画像処理の拙い部分をWikiで補い、コトバで書ける単純な画像処理マクロを実装し、ついでに、別に考えていたWiki アプリを合体させる予定だった。つまり、あまりにもアイデアてんこ盛りだった。
スケッチを人に見せ、ヒアリング作業をするたびに、Wiki部分が見えなくなっていく。この調子でいくと、αテストが終わる頃には見た目「画像処理アプリ」になってしまうかも。
2008-07-23[n年前へ]
■「肌」と「昼の日差し」のスペクトル
夏の日差しを実感するようになりました。肌は日焼けして赤黒くなり、そんな肌はピリピリと痛く、熱っぽさすら感じます。そんな、夏の明るい景色を眺めていると、なぜか楽しくなります。
痛いけれど日焼けする夏の日差しが気持良く感じる人もいる一方で、日焼けする夏を嫌う人も多いと思います。特に日焼けしたくない女性にとっては、夏は面倒でとても嫌な季節だったりするのかもしれません。
…と考えているうちに、ふと、夏の日差しを浴びる「肌の色」を眺めてみたくなったのです。そこで、２週間ほど前に作った「光スペクトル操作用のMathematicaライブラリ」にいくつかの色関数（スペクトル吸収関数）を追加してみました（サーバからダウンロードできるライブラリ更新は数日後になります）。追加したスペクトル吸収関数は、「血液」「カロチン」「メラニン」…といったもので、皮膚内部にある物質の吸収スペクトルを表現するための（単純化した）スペクトル関数を実装してみました。
そういった色関数を組み合わせると、いろいろな「肌色」を眺めることができるます。たとえば、右上の図は、(どの波長も均等に含んでいるような)白色光源で照らした時に血液の反射スペクトルがどう見えるかを試しに計算してみたものです。
spectorPlot[transmissionSpector[
whiteLight, bloodColorFilter, 0.5]
]];
ところで、こんな「色関数」を作り、適当で大雑把な「肌」を作って眺めてみました。すると、色温度6500ケルビンの標準光源、すなわち自然な昼光光源であるD65で、肌色を形作るメラニンや血液を照らしてみると、意外なほど「反射スペクトル」が平らになるものだ、と気づかされました。
つまり、昼の日差しのスペクトルのうち、スペクトル強度が強い短波長領域では、メラニンや血液などの色吸収率が高く、その一方、「昼光」のスペクトル強度が低下する長波長域では、メラニンや血液などの色吸収率が低く、それらの結果として反射スペクトルが”結構”均等になるのだなぁ、と感じたのです。たとえば、右のスペクトルグラフが、昼光＝D65光源で皮膚を照らした時の反射スペクトルの例になります（ちなみに、右下のグラフがD65光源のスペクトルです）。
それは、単に長波長領域の光は皮膚中で吸収されることが少なく、短波長の光が吸収される、というだけのことでしょうし、さらには、人によってメラニンの分布量・形状が異なり、反射スペクトルは全然違うわけで、こんな結果も一般的なものでは全くありません。
けれど、「昼光の逆関数のような、まるで、強い日差しから身を守るかのように最適化されたような皮膚の吸収スペクトル」を適当に作ったライブラリ関数が生成したのを眺めたとき、とても不思議なくらい新鮮さ・意外な面白さを感じたのです。
2008-08-02[n年前へ]
■画像処理WEBアプリを簡単作成用「ビジュアル言語」を作る
「ビジュアル言語」風の画像処理WEBアプリの叩き台を作ってみました。
いえ、正確に言えば、そんな「ビジュアル言語」環境を作ってみました。つまり、画像処理WEBアプリを簡単に作れる!?「ビジュアル言語」を作ってみた、ということになります。
ここで言う「ビジュアル言語」という言葉には、３つの意味合い・特徴があります。
- 処理構造をグラフィカルな部品・ワイヤーで表現・作成すること
- 各場所で処理されている「データが見える」こと
- 部品・ワイヤーを並べ終わった画面そのものが「アプリケーション」のGUI画面となっていること
ブラウザ上の操作感は（UI周りはWireItライブラリを使っていて）YahooPipesを模範にしています。また、処理データ構造は（YahooPipesを意識した）ImagePipesに準拠するようになっていて（つまりある程度緩い規約にもとづいたJSONになっていて）、 「オブジェクト」に対してユーザが何かしたり、あるいは、入力部に他の部品からメッセージを受けた時に、Javascriptでクライアント内部で処理をしたり、あるいは、サーバに対して同期リクエストを送ることで、出力結果を生成し、そして出力ポートの先にある他部品に結果メッセージを送信する、という作りになっています。
下の動画がその「叩き台」アプリケーションの動作動画です(高解像度画像もここに置いておきます)。この動画が「何をしているか」を箇条書きすると、
- 「画像をアップロードするフォームパーツ」を作り（出力はアップロードされた画像情報を示すJSON）
- 入力を２出力に分岐する（JavaScriptで書いた）部品を配置し
- 入力された(JSONで表現されている)画像を表示する部品を置いて
- 部品間をワイヤーをつなぐ
WireItがYahooUIライブラリに実装された折にでも、適当にサービスを立ち上げてみたいな、と思っています。
2008-08-03[n年前へ]
■評論は何もできない実装しない人にまかせとけ
それが、ハードウェアでも、ソフトウェアでも、対して違いはない。「可能な条件下で作る」ただそれだけだ。実装する立場になってみれば、評論家・解説者みたいな曖昧で一般的な言葉は絶対に出てこない。たくさんの「条件」が決められてしまえば、嫌でもその条件に応じた最適解が決まってしまうものだ。そんなものだ。
評論なんか何もできない実装しない人にまかせとけ。実装して、その動いた結果が全てだ。上手く動けばオッケーだし、上手く動かなきゃ、上手く動くまでやるだけだ。
Iram Amayoa.
」など。