進・日進月歩

IT, Jazz, study, engineering, すべての真実とクリエイティビティのために

sennaでpatricia treeを作る

  • Filed under: IT
Friday
Aug 28,2009

はてなのようなキーワードリンクをRubyで付与する実例
と、いうのをつくってもらったので、これをもとにCでsennaのpatricia treeを試すプログラムを書いたよ。

機能的にはとりあえずキーワードの検出だけ。

CODE:
  1. #include <stdio.h>
  2. #include <stdlib.h>
  3. #include <senna/senna.h>
  4. #include <string.h>
  5. //#include <exectime.h>
  6.  
  7. void create_index(char* index, char* filename){
  8.  
  9.         sen_sym *sym;
  10.  
  11.         if(!(sym = sen_sym_create(index, 0, SEN_INDEX_NORMALIZE, sen_enc_utf8))){
  12.             printf("cannot open or create sym file\m");
  13.             abort();
  14.         }
  15.  
  16.         FILE * fp = fopen(filename, "rb");
  17.  
  18.         char buffer[2048];
  19.        
  20.         sen_id sym_id;
  21.         while(fgets(buffer, 2048, fp)){
  22.             sscanf(buffer, "%s\n", buffer);
  23.            if(!(sym_id = sen_sym_get(sym, buffer))){
  24.                 printf("cannot create link\n");
  25.                 abort();
  26.            }
  27.  
  28. //           printf("%d\t", sym_id);
  29.         }
  30.  
  31.         fclose(fp);
  32.    
  33.         sen_sym_close(sym);
  34.  
  35. }
  36.  
  37. void traverse(char* index, char* filename){
  38.     printf("traverse\n");
  39.     sen_sym* sym;
  40.  
  41.     if(!(sym = sen_sym_open(index))){
  42.         printf("cannot open index file\n");
  43.         abort();
  44.     }
  45.  
  46.     FILE * fp = fopen(filename, "rb");
  47.  
  48.     if(!fp){
  49.         printf("cannot open file\n");
  50.         abort();
  51.     }
  52.  
  53.     fseek(fp, 0, SEEK_END);
  54.  
  55.     int filesize = ftell(fp);
  56.     int offset = 0;
  57.  
  58.     fseek(fp, 0, SEEK_SET);
  59.  
  60.     char * content = new char[filesize + 1];
  61.     const char * cp = content;
  62.  
  63.  
  64.     fread(content, sizeof(char), filesize, fp);
  65.     content[filesize] = '\0';
  66.  
  67.     sen_sym_scan_hit sh[32];
  68.  
  69.     char buffer[2048];
  70.  
  71.     const char * rest;
  72.  
  73.     exectime::start_timer();
  74.  
  75.     while((rest - content) <filesize){
  76.         int found;
  77.         if(!(found = sen_sym_scan(sym, cp, filesize, sh, 32, &rest))){
  78.             break;
  79.         }       
  80.  
  81.         for(int i=0; i<found; i++){
  82.             int key_len = sen_sym_key(sym, sh[i].id, buffer, 2048);
  83.             if(key_len> 0 && sh[i].length> 7){
  84.                printf("%s\n", buffer);
  85.             }
  86.  
  87.         }
  88.         cp = rest;
  89.  
  90.     }
  91.  
  92.     exectime::end_timer();
  93.  
  94.     printf("time: %f sec\n", exectime::time_result());
  95.  
  96.  
  97. }
  98.  
  99. int main(int argc, char** argv){
  100.  
  101.     if(!strcmp(argv[1], "make")){
  102.         create_index(argv[2], argv[3]);
  103.     }else if(!strcmp(argv[1], "traverse")){
  104.         traverse(argv[2], argv[3]);
  105.     }
  106.    
  107. }

Tuesday
Aug 25,2009

Darts: Double-ARray Trie System
http://chasen.org/~taku/software/darts/

dartsというのは、Trie木をdouble arrayで実装したライブラリです。ヘッダファイル一つだけの配布なので大変使いやすい。

今回HAT-trieを実装してみるにあたって、Trie木の部分の実装としてこれを使ってみることにしました。

しかし、サンプルが動かない・・・・!どうやらよく見るとテンプレート周りとconstを付け加えた際に、もともとのサンプルが動かなくなった模様。
なので、これを修正しました。別に大したことはしていません。

CODE:
  1. #include &lt;iostream&gt;
  2. #include &lt;darts.h&gt;
  3.  
  4. int main (int argc, char **argv)
  5. {
  6. using namespace std;
  7.  
  8. const Darts::DoubleArray::key_type   *str[] = { "ALGOL", "ANSI", "ARCO""ARPA", "ARPANET", "ASCII" }; // same as char*
  9. Darts::DoubleArray::result_type val[] = { 1, 2, 3, 4, 5, 6 }; // same as int
  10.  
  11. Darts::DoubleArray da;
  12. da.build (6, str, 0, val);
  13.  
  14. cout &lt;&lt;da.exactMatchSearch&lt;int&gt;("ALGOL") &lt;&lt;endl;
  15. cout &lt;&lt;da.exactMatchSearch&lt;int&gt;("ANSI") &lt;&lt;endl;
  16. cout &lt;&lt;da.exactMatchSearch&lt;int&gt;("ARCO") &lt;&lt;endl;
  17. cout &lt;&lt;da.exactMatchSearch&lt;int&gt;("ARPA") &lt;&lt;endl;
  18. cout &lt;&lt;da.exactMatchSearch&lt;int&gt;("ARPANET") &lt;&lt;endl;
  19. cout &lt;&lt;da.exactMatchSearch&lt;int&gt;("ASCII") &lt;&lt;endl;
  20. cout &lt;&lt;da.exactMatchSearch&lt;int&gt;("APPARE") &lt;&lt;endl;
  21.  
  22. da.save("some_file");
  23. }

Tuesday
May 12,2009

activerecordの様なDBラッパーを作ろうと思って、 @ujm の協力の下module_evalを使って実装してみた。
必要最小限のことしか書いてないのでDBラッパーとしては貧弱だけど、module_evalの動きに注目してみてほしい。
本物のactiverecordも似たような実装をしていたと思う。(うろ覚え)

RUBY:
  1. require "rubygems"
  2. require "mysql"
  3.  
  4. class ModelBase
  5.  
  6. DEFAULT_DBUSER = "user"
  7. DEFAULT_DBPASS = "pass"
  8. DEFAULT_DBHOST = "host"
  9. DEFAULT_DBNAME = "name"
  10.  
  11. @@options = {"dbhost" =&gt; DEFAULT_DBHOST,
  12. "dbuser" =&gt; DEFAULT_DBUSER,
  13. "dbpass" =&gt; DEFAULT_DBPASS,
  14. "dbname" =&gt; DEFAULT_DBNAME
  15. }
  16.  
  17. def self.get_db_object()
  18. @@mysql_obj ||= Mysql::new(@@options["dbhost"], @@options["dbuser"], @@options["dbpass"], @@options["dbname"])
  19. end
  20.  
  21. def self.table_name(tn)
  22. module_eval <<"EOS"
  23. class &lt;&lt;self
  24. def get_table_name
  25. '#{tn.to_s}'
  26. end
  27. end
  28. EOS
  29. end
  30.  
  31. def self.query(sql, place_holder=[])
  32. db_obj = get_db_object
  33. stmt = db_obj.prepare(sql)
  34. stmt.execute(*place_holder)
  35. stmt
  36. end
  37.  
  38. def self.count(condition="1", options=[])
  39. sql = "select count(*) as count from #{get_table_name} where " + condition
  40. res = query(sql, options)
  41. count = res.fetch
  42. count[0].to_i
  43. end
  44.  
  45. private_class_method :get_db_object
  46. end

これを次のように使う。たとえばuserテーブルを扱うクラスはこんな感じ。

RUBY:
  1. require "lib/ModelBase.rb"
  2.  
  3. class UserModel <ModelBase
  4. table_name "users"
  5.  
  6. def initialize(id, name, screen_name, location, description, profile_image_url, url, protected, followers_count, friends_count, time_zone, favorites)
  7. @id = id
  8. @name = name
  9. @screen_name = screen_name
  10. @location = location
  11. @description = description
  12. @profile_image_url = profile_image_url
  13. @url = url
  14. @protected = protected
  15. @followers_count = followers_count
  16. @friends_count = friends_count
  17. @time_zone = time_zone
  18. @favorites = favorites
  19. end
  20.  
  21. def save
  22.  
  23. sql = "insert ignore into #{UserModel::get_table_name} (id, name, screen_name, location, description, profile_image_url, url, protected, followers_count, friends_count, time_zone, favorites) values (?,?,?,?,?,?,?,?,?,?,?,?)"
  24. UserModel::query(sql, [@id, @name, @screen_name, @location, @description,
  25. @profile_image_url, @url, @protected, @followers_count,
  26. @friends_count, @time_zone, @favorites])
  27. end
  28.  
  29. end

ModelBaseクラスを継承し、table_nameメソッドでテーブル名を指示しているわけです。

で、ポイントはModelBaseクラスの次の部分。

RUBY:
  1. def self.table_name(tn)
  2. module_eval <<"EOS"
  3. class <<self
  4. def get_table_name
  5. '#{tn.to_s}'
  6. end
  7. end
  8. EOS
  9. end

UserModelの冒頭でtable_nameとこのメソッドを呼んでいます。

module_evalは、そのメソッドが呼ばれたところをselfにして実行されるメソッドであるため、このtable_nameメソッドの中で定義されているget_table_nameは、UserModelのクラスメソッドとして定義されます。

つまり、UserModel内でtable_nameが呼ばれた時点では、次のコードと同じことをします。

RUBY:
  1. class <<UserModel
  2. def get_table_name
  3. '#{tn.to_s}'
  4. end
  5. end

こうすることによって、プログラム中でテーブル名をハードコードしなくてもすむようになるとともに、countなどの関数を親クラスで定義できるようになるわけです。

例えば、この方法で作ったクラスで全レコード数を数えるコードはこうなります。

RUBY:
  1. require "lib/UserModel.rb"
  2.  
  3. UserModel::count

大変すっきりしていますね。

蛇足:

これはtwitterのポストを扱うために書いているプログラムの一部です。
rails使おうかとも思ったのだけど、railsはまだ多機能すぎるためこの程度なら書いてしまった方が悩みが少ない(重いとかファイルの配置とか拡張性とか)かと思って自分で書いています。

しかし、自分でフレームワーク作るかというと・・・・たぶんないですね。
フレームワークは必要じゃない機能もたくさん足すことになります。
なんの目的もなしに機能追加を繰り返していくと、フレームワーク自身のメンテナンスに負荷がかかるようになってしまうし、コードの自由度がどんどん下がっていきます。

それよりは、構造化を心がけながらプログラミングをし、拡張性を担保しながら、必要十分なものを作っていく・・・と、いうのが賢いプログラミングである気がしました。

テクノロジーの神話

  • Filed under: 雑記
Monday
Mar 30,2009

「テクノロジーが重要なんだ」

こういう人は少なくないです。工学部を今年卒業する自分としても、「テクノロジーが重要」というのはとても同意できることです。
しかし、これが一度サービスに関する議論になった時どうでしょう?
私はこういうときにいつもこういいます。

「技術的問題はほとんどの場合解決可能なので、ユーザが受けるべきメリットについてよく考えてください」

これがなかなか難しいらしいことに最近気づく。
技術者は「技術的面白さ」が「一般人の感覚から離れすぎている」ことで、ユーザのメリットを考えにくい傾向があるように感じられる。
これはよくよく指摘されていることです。
が、面白いことに「技術者じゃない人」も同じく、「技術ありきでサービスを考える」傾向がとても強いことに最近気づいた。
やっかいなのは技術に関する知識がない分、発想が貧弱だということだ。

よくgoogleが引き合いに出される。(一応特定個人のことを言ってるわけではなくて本当にそういう人が多いということです。)
だいたい理屈はこんな感じだ。
「googleにはpagerankというテクノロジーがあった。かならずイノベーションにはテクノロジーが必要なんだ」
「googleにはcloudを持つ技術があった。だからイノベーションにはテクノロジーが必要なんだ」
しかし、これをいってる人の何人がpagerankによる効用やcloudによる効用を説明できるのかはかなり疑問です。
「テクノロジーが必要」といいながら、その実「テクノロジーが本当に重要だったかどうか」については全く検討されていないように感じられる。
とくに「cloudを持つ技術がある」というあたりは、もはや末期的な発言に聞こえる。cloudに関する技術的な定義は大変あいまいで、技術がわかる人は少なくともこういう発言はしない(と、俺は少なくとも思う

私はここに「テクノロジーの神話」があるように思えてならない。

もうテクノロジーの時代は去ろうとしているということに気づかないといけない。
「サービスの時代」といわれ、先進国は三次産業にうつっているといわれて久しい昨今。「テクノロジーの発明」に固執することはおかしいのではないだろうか?

もはやほとんどの電化製品は技術の集大成であるということを認識しないといけない。webサービスはもっと多くの技術の上に成り立っている。
RDBひとつとってみたところで、技術の集大成だ。
もはやフィラメントを光らせたらそのまま製品にできるような時代はとっくの昔に終わっている。ひとつの技術がイノベーションを起こせるというのはすでに時代錯誤でしかない。

現代のテクノロジーにおいて必要なことは2つ。「市場をみること」と「多くのテクノロジーを知ること」だ。
市場を見ることで、どのようなテクノロジーが必要とされており、なにを開発するべきかを知らないといけない。
そして、市場の問題を解決するために、適切なテクノロジーを選択できなくてはいけない。

もし、現代にイノベーションが求められているというのであれば、「技術の発明」に固執してはいけない。
イノベーションは、テクノロジーの与えた経済的・社会的インパクトで計られ、しかも技術の発明がそのまま社会にインパクトを与える時代は終わってしまっているからだ。
今はむしろ、与えるべきインパクトから逆算することが求められている。与えるべきインパクトから、適切な技術を開発・選択することが求められている。

今一度真摯に「テクノロジー」「イノベーション」という言葉について考えてほしい。
本当に、あなたが考えている「pagerank」や「cloud」がイノベーションに必要だったんだろうか?むしろ、単純に「検索結果がよかったから」じゃないだろうか?
インターネットは本当にあなたの生活を変えたのだろうか?ニコニコ動画がなかったら?Amazonがなかったら?googleがなかったら?あなたはwebサービスがなくてもインターネットに感動しただろうか?

こういう言い方をしてもいいかもしれないです。あなたの「目で見たもの、耳で聞いたもの、肌で感じたもの」を信じてください。
本当にpagerankにあなたは感動したのでしょうか?メディアにだまされてそんな気がしてるだけじゃないですか?
本当にインターネットに感動したのでしょうか?今あなたの見ているものはインターネットなんですか?

重要なのは、事実がどうだとかではないです。あなたの目で見、頭で考え、そして納得したことなんでしょうか?

誰かが作った「テクノロジーの神話」に騙されてませんか?

技術をマネージする・予期する

  • Filed under: 雑記
Tuesday
Jan 27,2009

今日の日経新聞朝刊に「科学研究 国の役割増大」という記事があって面白かったので転載。

ドイツでは、ある完了が大蔵大臣に銃を突きつけるようにして、科学研究費の獲得に勤めていた。その官僚の名前はフリートリヒ・アルトホーフという。

(中略)

彼は優れた科学上のアイディアを持ちながら、それを発展させる資金がないために困っている人物を見つけると、一存で研究費を投入して完成に導いた。あるいは優れた能力を持ちながら、なかなか教授になれないでいる人物を見つけると、大学側の反対を押し切り、教授に任命した。

そうした研究者が数年もすると、次々にノーベル賞を受賞して言った。そのため彼は後年「ノーベル賞受賞者のゴッドファーザーと呼ばれた」

(中略)

しかしその反面、アトホーフはいつまでも国家財政に頼っているのでは、限界があることを見抜いていた。彼は巨額な民間資金が科学研究に投入されている米国を横目で見ながら、それに強い危機感を抱いていた。そこでひそかに同様に仕組みをドイツに導入する計画を練り始めた。

しかし彼の企画はスムーズには進まなかった。

(中略)

アルトホーフの没後百周年にあたる2008年10月彼の人物や功績を再検討しようと、八カ国の報告者が参加した国際シンポジウムが開かれた。シンポジウムでは、今後科学研究はいかなる資金によって支えられるべきかという点に議論が集中した。

「役に立つ知識か否かは、市場によって選別される。市場から求められない研究分野が消滅するのは、当然の結果である」「科学研究にかかるコストは、その成果から直接利益を得る企業が負担すればよい」「なんらの企業利益も生まないような科学研究は支援する価値がない。」・・・・こうした発想が現代では主流となっている。

しかし学問とか科学研究は、レンガを一つ一つ積み上げてゆく作業である。一つ一つのレンガは目に見える利益を生まなくても、それがなければ知識全体がつみあがっていかない。

(中略)

この現代では新たな研究成果は、出資者の私有財産となり、他者が自由には使えないケースが増えた。

(中略)

大学予算削減が連続する時代には、第二、第三のアルトホーフもまた欠かせない。

なるほど。研究成果と企業云々の部分に関して似たようなことをドラッカーも実は書いている。

テクノロジストの条件 ドラッカー

p131

近代企業は、いわば技術の産物である。(中略)今日の大企業のルーツは、最初の大企業である19世紀半ばの鉄道、つまり当時の技術的イノベーションだった。それ以降、今日のコンピュータメーカーや製薬会社に至る成長企業のほとんどが、それぞれの時代の新技術による産物だった。

それどころか、やがて企業が新技術を生み出すようになった。(中略)技術は、イノベーションとして社会的に有効なものとなる上で、ますます企業に頼るようになった。

今日たまたま素粒子物理の友人と話していたが、「加速器一回まわすのに一千万くらいかかる」という話である。一回の実験で一千万。ひとつの研究をなすのにも世界中の企業からお金を集めなければない世界がここにある。

素粒子物理はともかくとして、実際に企業活動をベースとして技術を捕らえる事に関して、ドラッカーは「技術を予期することが肝心だ」と説く。

テクノロジストの条件 ドラッカー

p132

第一に、技術は神秘的なものでも予期できないものでもない。合理的に予期することは可能であり、そうすることが必要である。

(中略)

第二に、技術は事業活動と別種の活動ではない。そもそも事業と別のものとしてしまったら、マネージメントできない。

(中略)

技術は把握できないとする考えは、もはや時代遅れである。まさにこの考えが技術に対する恐怖をもたらす。発明は予期したり計画したりできないとする考えも、また間違いである。

(中略)

特にイノベーションについては、予期すること、計画することが重要だって、かつ必須である。

「技術を予期することが容易だというのではない」と言ってはいるが、繰り返し繰り返し、技術やイノベーションを予期することの大切さを説いている。おもしろいのは、この続き。

マネジメントが関心を持つべきものは、発明ではなくイノベーションである。イノベーションとは社会用語であり、経済用語であって技術用語ではない。(中略)イノベーションは、たとえ発明から生まれることが多くとも、発明と同義ではない。

言われてみると当たり前のことなんだけど、実はこの視点、結構かけているように感じることが多い。
正直よく「こんなことできるなんてすごい!イノベーションだ!」とか「これが開発できたら今までになかった!イノベーションだ!」ときいたりするんだけど、その経済効果とかってあまり考えられていないなぁとよく感じることが多い。
結局売れなかったものは「イノベーション」と呼ばないにもかかわらず、なぜか開発段階やコンセプトの段階で、この「経済効果」という概念を欠いているものが多いように感じることが多い。
むしろ個人的な感想としては、開発やコンセプト段階で経済効果について言及することが悪とさえ思われてるんじゃないかと思うことすらある。

また一方で、「イノベーションなんか予期できない」と言っている人がいますが、実は割りと限定的に予想することは可能だったりします。それなりの業界知識と工学知識があると、「何があたるか」はわかんなくとも「何が可能そうか」はわかるし「何が売れそうか」もなんとなくわかる。俺的に問題は「可能そう」でかつ「売れそう」なものを考えるのが案外難しい。

こっからは持論ですが、結果的に工学や科学・ソフトウェア、なんでもいいんですが、そういったものに対するそれなりに深い知見と、ある程度のマーケットへの洞察が「イノベーション」を起こすためには重要であると思っています。「それなりに深い」っていうのは難しいところですが、工学が全くわからない人は論外だけど、それほどマニアックでもないといったところであるきがします。

現に工学部の研究室の研究というのは、現代の技術のちょっとした発展を扱っているというものが多いです。結局研究もほとんどのものは従来のものに自分なりに方向付けをして付け足していると考えてもそれほど間違ってはいないと思います。これからの企業は、現代のテクノロジーの把握と、マーケットを見据えた方向付け、そして資源の集中と開発という技術とともに発展していく形というのがいいのではないかなと思います。技術の発展には企業活動による資金の供給が必要であり、企業はマーケットを見据えその方向性をコントロールすることで技術をお金に変え発展する。こういう技術に対する先見性と経営が必要なんじゃないかなと思う今日この頃でした。

論理的思考(笑)

  • Filed under: 雑記
Saturday
Jan 24,2009

常々「論理的思考」というものには辟易している。
それはよくある反論のように「論理的に考えたところでイノベーションは起こらないんだ!」とかいう抽象的な話ではない。
「論理的に考えることがいいことだ!」と言ってる人も「論理的に考えてもイノベーションなんか起こらない」とか言ってる人も、俺はどちらもたいていの場合賛同できない。
自分が言いたいのは、人間なんてそもそも論理的に物事考えてなんかいないということだ。

そう、問題は「論理的に物事を考えていない」ということ。もしくは「考えてる論理が穴だらけすぎてやばい」ということか。

と、いうのはこの記事のような内容。
http://blog.goo.ne.jp/hi_tsuka/e/c8cbf35ecc957120699cbd987635df45

ちょっとあえて小難しく論理的に考えてみよう。しばらくお付き合いを。

まず、直感的に正しいと思える次の主張はまったく間違っていることに気づかない人は存外多い。

「9回連続で赤が出る確率はXX%。。。だから、次は黒!」

普通に高校レベルの確率論をやっている人は、「8回赤が出たときに9回目に赤が出る事後確率」を計算すべきだと気づくと思う。
今回の場合、善良なディーラーであると仮定するならば、すべての試行は独立であり、結局今まで何回赤が出ようが、9回目に赤が出る確率はpで一定であり、かつ、黒が出る確率は1-p。

問題は、赤が出る確率pがどの程度かという点である。残念ながらこれは判断できそうにない。

じゃぁ赤と黒が均等に出ているのかどうかを大真面目に検定してみよう。ちょっと馬鹿馬鹿しい気もするけど二項検定してみました。

帰無仮説「赤と黒が確立1/2で出る」 → p-value=0.007812

有意水準1%だとすると、どうやら帰無仮説は棄却されそうです。つまり台はゆがんでたりなんかするかもしれない可能性がそれなりに高い。

さて、ちょっと記事の話に戻りましょう。検定方法が正しいのかとかいろいろな問題はあるんですが、どうやら記事中の社長さんと同じ結論になってしまいました。「台は壊れてるんじゃないかkk」(kk = 確率的に考えて)

結局何を言いたかったかというと、論理というのは手段なのであって、論理性と「イノベーションが起こせるかどうか」は無関係なのです。うそ。正確に言えば「関係があるかどうかはわからない」ということ。
なので、どっちを信じるかはあなた次第ですが、本当に論理的に考えてる人であるなら、関係があるともないとも言えないはずなのです。

さらにもう一歩突っ込むと、「論理的に考えることに限界がある」というのは嘘です。これってつまり、難しい数学の入試問題が解けなかったときに「これは俺の能力の限界じゃない!数学の限界なんだ!」とか言っているのと同じです。
さっきの記事で言えば、そこで「仮説検定して台が壊れているかどうかを検定してみよう」と思えるかどうかは、論理性とは別に「深く考えることができるか」だったり「知識・知恵があるかどうか」という問題なのです。

むしろ論理的思考が重要なのは、「それが正しいかどうかが検証できる」という点にあります。
たとえば今の例で行けば、検定方法は正しいのか?有意水準は1%でいいのか?いろいろな検証が可能です。
その検証可能性が、結果的に説得力にもつながっているといえるでしょう。
なぜか、この点が忘れ去られて、単純に「結果がすぐ導き出せる魔法の道具」として「論理」を考える人が多すぎる気がします。

もちろん、現実では必ず結果を出さなくてはならないため、特に論理が必要でない場では結果が優先されます。
それは別に悪いことでもいいことでもありません。ただ、論理的に考えつくすことができなかったのだとすれば、それは論理の限界ではなくあなたの能力の限界です。
これを単に「論理の限界」にすり替えるのはどうかと思います。

また、辺に自分の論理にこだわるのもいかがなものかと思います。会話していると「言葉の意味」とか「前提」とかが、自分と相手で微妙に違うことにしょっちゅう気がつきます。
もし、お互いに本当に論理的に話しているのだとすれば、相手の論理に自分の論理を写像して考えることも可能なのではないでしょうか?
もし写像できないなら、それは分かり合えないところだと思って納得しておけばいいと思います。

論理というのは道具に過ぎないということをもう一回考えてみたほうがいいんじゃないでしょうか?
なんだかわかんないけど、ロジカルシンキング(笑)だとかMECE(笑)だとかすぐに言い出す新しいおもちゃを与えられた子供みたいな人たまにいるので辟易してるのですが、論理に振り回されず、他人とちょっと楽しい会話するためのコツとして考えてみるのはどうでしょう?

Sunday
Jan 11,2009

iPhoneアプリで面倒なのは、プログラム的に作れるかどうかに加えてappleの審査に通るかどうかです。
それをまとめたページをtwitterからひろったのでリンクを。

なんかこのページそのものがNDA違反で消えるんじゃねぇかという予感がしないでもない。
(アプリへのリンク張ってる人は要注意だと思うなー)

http://q.hatena.ne.jp/1231517350

個人的にネックだと思ったのは、up-sellさせるような表示の禁止の部分。up-sellはマーケティング手法としては基本中の基本で、俺これ知らずに誰かにアドバイスしちゃった気がするよ・・・・嘘いってごめんなさい・・・・

3. ベータ版あるいは機能限定版の場合、以下のように reject されることがあります。

「CashFlow Free cannot be posted because it is a beta or feature-limited version. Any reference to demo or beta needs to be removed from the binary and metadata. Free or "Lite" versions are acceptable, however the application must be a fully functional app and cannot reference features that are not implemented or up-sell to the full version.」

大体の意味からすると、「アプリケーション単体の中ではすべての機能が動作しないといけません。上位バージョンや有料バージョンへの誘導をアプリの中からしないでください」という感じのようです。

いまんところiPhone関係は、本格的にフォローしてるわけではないのだけど、実際やるといろいろ大変そうだなぁ。

Thursday
Jan 8,2009

http://www.blu-ray.com/news/?id=2252

Finally, Panasonic has partnered with Amazon on demand to offer film downloads from Amazon's library of over 40,000 titles. This feature will be available on all new Viera-cast products.

最後に、パナソニックはアマゾンとビデオオンデマンドに関してパートナーシップを結んだ。4万タイトルを超える映画をダウンロードできるようになる。次のvieraから使えるようになる。

いまさらといえばいまさらだけど、パナソニックが積極的に外部のサービスを自社の製品に取り込むというのが進んでいます。
かくいう自分もこっそり大手電機メーカーのテレビに自社サービスを提供している会社に一時期かかわっていました。

ほかにも保険系の会社が社内のシステムの一環としてどこかの会社の事件情報(これもベンチャー)を利用するなど、そういった外部情報やサービスの積極利用が進んでいるなと一昨年の暮れから感じていました。

この傾向は今後も進んでいきそうです。

ubuntu8.10 でdvipdfmxが通らない

  • Filed under: 雑記
Saturday
Jan 3,2009

ubuntu8.10上で卒論研究してるわけですが、学科指定のlatexのクラスファイルでpdfが作れない!なんてこった。
というのを解決したのでメモ。

現象は、dvipdfmxでdviからpdfを作るときに次のエラーが出る。

[1kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 1+199/600 --dpi 799 gbm-jis
mktexpk: don't know how to create bitmap font for gbm-jis.
kpathsea: Appending font creation commands to missfont.log.

** WARNING ** Could not locate a virtual/physical font for TFM "gbm-jis".
** WARNING ** >> There are no valid font mapping entry for this font.
** WARNING ** >> Font file name "gbm-jis" was assumed but failed to locate that font.
** ERROR ** Cannot proceed without .vf or "physical" font for PDF output...

Output file removed.

どうやら、フォントのマッピングがうまくいってない模様。次のサイトにあるように設定ファイルを変更したら解決。

http://lists.debian.or.jp/debian-users/200301/msg00263.html

あと、/etc/texmf/dvipdfm/dvipdfmx.cfg の最後に

f jis-cjk.map

と追加してやると良いかと思います。/etc/texmf/dvipdfm/jis-cjk.map は
ptex-jisfonts パッケージに含まれています。

これで万事解決。

今年の抱負「情報」

Friday
Jan 2,2009

※新年の抱負書こうと思ったら前振りが長くなりすぎた・・・抱負は一番下。

※せっかくなので似たようなエントリにトラックバック打たせてもらいました。
http://uva.jp/dh/mt/archives/005165.html
http://mitaimon.cocolog-nifty.com/blog/2009/01/2009newyear.html

あけましておめでとうございます。

世間では不況不況と騒いでおりますが、去年はそれほど世間と関わっていなかったせいかあまり実感するところではありませんでした。
ちょっと遠い知り合いの会社が無くなってたりとか、取締役だった人が平になっていたりとか、東京に出てきていたベンチャーが会社を田舎に引っ込めるとか、そういうことはあったようですが、もともとがんがんつぶれてくものなので(ぉぃ)不況のせいかどうかは今一よくわかりませんでした。

さて、そんな中で私の主たる関心であるITや情報に関しても、こうした事件から感じることがありました。

「未曾有の金融危機」「100年に一度の危機」「偽装表示」「産地偽装」などなど。これらに共通することのひとつとして「情報」が深く関連しているように感じました。
それは現代人が扱わなくてはならない情報の「量」についてです。

サブプライム問題を正確に理解してるわけではないですが、情報という観点から見れば、情報の不達が原因で起こっている事件といえることである気がしました。
サブプライムローンの債権を証券化し売りさばき、それをまたほかの商品と合体して売りさばく。これを繰り返していくうちに金融商品は複雑化し、いったいその商品がなんだったかわからなくなる。
かけられたレバレッジを支えている根本がわからなくなるわけです。

これは、産地を偽装された食品にも似ているなと感じました。複雑な流通経路をたどるうちに、小売店に来るころには消費者にその商品の価値を支えている根本がよくわからなくなっているわけです。
こちらのほうは金融商品なんかと比べれば幾分法整備も進みましなのかもしれませんが。

さて、皆さんに考えてほしいのは「情報」の信頼性とは何なのかという話です。私たちは何を信じればいいのでしょうか。

東大で行われているビジネスコンテストでこれに関連するビジネスプランを考えてヒアリングにいったときの言葉です。誰もが知っている大手の金融系の会社2社。

情報は早さが命。いちいちソースの信頼性とかは確認していられないし、そもそも今日正しかったことが明日も正しいとは限らない。情報の信頼性はほとんどその人にかかってる。

昔に比べて扱える情報の量が格段に増えている。昔ならたくさんの人を使って計算していたことが今ならエクセルで瞬間的に計算できる。

まさにIT革命の恩恵をフルに利用しているといえる気がします。金融に限らず現代はどれだけ膨大な情報を適切に消費するかに価値があるという感じでしょうか。
情報はある。処理することもできる。しかしその情報そのものがどういう性質のもので果たしてどんな素性のものなのか?すでに私たちが日々触れる情報は一生かかって処理できる要領をはるかにこえてしまっているようです。
すでに情報をやたらめったら消費する時代は過ぎ去ろうとしているのです。これを産地偽装問題や金融危機から学び取らなくてはならないのではないでしょうか?今時代は情報をうまく「管理」する時代へと変わろうとしています。

2007年にGTD(getting things done)やlifehack本が流行り、2008年にはいわゆる勝間本やgoogleをうまく使うための本が大変流行りました。
これらは、いかに効率よく大量の情報を取得し、うまく管理するかとの方法論としてくくることができそうです。今まさにそうした情報管理に長けた人たちが時代の長者として台頭し始めているのです。
それの典型が、勝間和代さんの提唱しているフレームワーク思考なのでしょう。

さて、時代の最先端はどうやら情報の大量取得・大量処理、そしてそれを何とか管理しようというところまでやってきているようです。
ここからはちょっとITの世界・インターネットの世界での情報の話をします。

インターネットが登場し、情報を発信する場だったのがだんだんと情報を貯める場に進化していきました。イメージとしては、PR的なものや情報公開的なものばかりだったwebが、個人のメモや日記など、公開非公開の別はともかくとして、個人のストレージの代わりとして使われるようになったということです。

そしてgoogleの大ブレイク。機械検索はそうした個人のストレージに他人がアクセスすることを可能としました。これに連動するように個人サイトやブログも急増しました。ちょうど公私の中間くらいの情報公開が大変増えたといえるでしょう。
googleは巨大なストレージへのアクセス手段となりました。

ここでひとつ重要な変化が起こります。内外の情報量の反転です。

今まで私たちは、簡単に外部の情報を得る手段がなかったために、自分の持っている・知っている情報の方が探し出せる情報より多かったのです。
しかし、webとういう巨大なストレージへのアクセス手段を機械検索を通して得た今、自分の持っている情報より探せる情報の方が多くなっているのです。

そして、アグリゲータやマッシュアップの登場。複数のソースから情報を取得し整理公開するサイトが登場しました。
プログラムで自動的にやるものが主ですが、世間に多く存在するニュース記事のコピペブログなども同じカテゴリといえる気がします。

さらに最近ではリブログという概念が登場し、tumblrなどのサービスが提供されるようになりました。大まかには、簡単にネット上の情報をメモしまとめ上げ公開するサービスです。アグリゲータ・マッシュアップを手動でやるための便利サービスという感じでしょうか。

さらにはもう一歩踏み込んで、evernoteというサービスが登場しました。これは脳の外部化を明確に歌っています。

Evernoteで自分の脳を拡張する techcrunch

CEOのPhil Libinの言葉を借りれば、「Evernoteの本旨は外部に脳を持つこと」だそうだ。

こうして、私たちの主たる情報への感心は、インターネットの登場による「公開」から、情報の蓄積、検索、管理へとこの順にシフトしていっているのです。

では、テクノロジー方面では何が起きているのでしょうか?(ちょっと長文で疲れてきたのではしょります)

記憶装置の単価が爆発的に安くなり、日々私たちが消費できる記憶容量は拡大して言っています。いまは大量の情報を手に入れるだけでなく蓄積することができるようになっているのです。
変な話ですが、今までインターネットを通して大量の情報に触れることができていたにもかかわらず、私たちは情報を所有することができていなかったのです。
それがようやくここに来て可能となってきました。

そして、ここが最大のポイント。私たちは大量の情報を得るだけでなく、それを処理するコンピューティングパワーを手に入れようとしています。
本来であれば一部の大企業や大学しかもてなかったスーパーコンピュータに匹敵する計算力を、仮想化の技術で安価に得ることが可能になったのです。
しかし、私たちは今その力を持っているにもかかわらず、その力をなんのために使うべきかを知りません。

あるEC系企業は何年も前から大量の顧客情報を持っているにもかかわらず、それを有効につかうすべを持っていません。
それは、計算力の問題とどうやったらいいのかというノウハウの問題がありましたが、いまや残る問題はノウハウのみとなりました。
いわゆるデータマイニングの分野の問題です。

ばらばら書いてきましたが、ちょっとまとめると・・・・

情報の大量取得・大量消費をしてきた世界は、今情報の適切な管理運用方法を必要としている。一方で技術的発展から情報の所有が可能となりそれを処理する力も得た。しかし、どう処理すべきかをいまだ知らない。

これは非常にチャレンジングな問題です。たとえばECで使ったノウハウがそのまま金融で使えるかというとそんなわけではないわけです。
さらに、いま私たちはそういった特定分野の情報だけではなく、多種多様な情報の洪水に見舞われています。
あるときは金融商品の情報が、あるときは食品の情報が気になるわけです。

そのためには、ながらくweb開発で使われてきたMVC(Model-View-Control)モデルに当てはめて考えるのが適切であるように感じます。
簡単に言えば「情報の蓄積」「表示」「処理」でしょうか。

巨大で安価なストレージが手に入るようになり、データ構造的な問題を別にすれば、モデルの問題は解決してきました。
情報を手に入れる先に関しても、EDINETの動きのように日々多種多様な情報がねっとで公開されるようになって来ています。

ビューに2007-2008はappleのおかげで大変インターフェースに関心が集まりました。wiiなどもインターフェースのあり方に関して一石を投じたように思います。
しかし、大量の情報を管理するという視点ではまだまだ改善の余地がありそうです。

またコントロール=処理の部分はまだまだ改善の余地がありそうです。むしろいまだに未開拓であるといってもいいように思います。

というところでようやく新年の抱負をば。

こうした背景の中で、私は今大量の情報を処理する部分に興味があります。マシンビジョンや機械学習・パターン認識・統計などなどを今まさに研究中です。
また、具体的なアプリケーションとしては、個人の情報活動支援をどうすべきかという点に関心があります。

「誰でも大量に情報を手に入れられる時代」は、個々人の判断を要求します。手に入る情報が限定的であったpre-googleの時代と比べて、主体的に情報を取捨選択し行動することが必要となっています。
そしてその情報はすでに人力ではどうしようもない量に達しています。
そこに対して、ITからのアプローチができないかということを今年は考えていこうと思います。

これは個人的興味からだけではなく、自分の生産性やできることを拡張するための重要なこととしてやっていきたいと考えています。

今年は、大学院に進学し、就活するのと、不景気なので雇ってくれなかったことも考えて起業する準備も含めていろいろどたばたする予定です。
そういうところも含めて、なにやったら面白いか、儲かるか考えて生きたいと思います。

というわけで、なんだか長くなりましたが、今年もよろしくお願いします。

追記:

毎年やってる新年の抱負さいとを作ったのでよければ皆さんかいてください。

http://ny2009.gijutsuya.jp/

about me

原田 惇

応用数学や統計、ITなどを利用していろんなことをしています。
自己紹介はこちら

adsense

amazonお勧め