Operaが無料でライセンス提供

ITmedia窓の杜の記事にも出ていますが、ノルウェー発WebブラウザのOperaが、8月30日、会社設立10周年イベントのひとつとして、24時間限定でライセンスキーを無料で配布しています。

Opera 10-year online anniversary party
http://my.opera.com/community/party/


Operaはライセンス登録無しでも使えますが、ライセンスがないと上部に広告が表示されます。私はWebサイトによっては時々Operaを使うことがあるので早速登録してみました。もともと気になるほどの広告ではありませんでしたが、やっぱりない方が気持ちはいいですね(^^)。

このイベントは、日本時間で8月31日午後10時までです。Operaを使われている方、興味のある方でお早めに。

【関連リンク】
Opera (日本語サイト)

コンパイル時の静的チェック(STATIC_ASSERT)

早起きは3億の徳

デバッグをスムーズに進めるにはどうすれば良いか。一つは、できるだけ早い段階でバグ(ミス)に気付くことです。assertやその派生マクロは、バグを早期発見する上で非常に有効な手段ですが、条件チェックは実行時でないと行われません。実行時ではなく、コンパイル時に静的にバグを発見できれば非常に便利です。

このようなコンパイル時の静的チェックのひとつがstatic_assertです。例えば、次のようにして使用します。
int send_msg(void* msg, size_t size);

int func()
{
  my_type_t my_data;

  ....

  STATIC_ASSERT(sizeof(my_type) <= sizeof(msg_t)); 
  send_msg(&my_data, sizeof(my_data));
}
通常のassertであれば、実行時上記コードを通った段階でabort()等で気付かせてくれますが、static_assertの場合は、コンパイル時にエラーになります。

では、このようなstatic_assertはどのようにして定義するのでしょうか。C++では、boost等でも用意されているtemplateを用いた方法がありますが、ここではCでも実現可能な方法を紹介します。
#define STATIC_ASSERT(expr) { char static_assertion_failed[(expr) ? 1 : 0]; }
分かるでしょうか?
通常長さ0の配列はコンパイルエラーになるため、exprがコンパイル時に成立していないと、コンパイルエラーになるのです。この方法の欠点は、エラーメッセージが「長さ0の配列は定義できません」等の意味不明なメッセージになる点です。少しでもわかりやすくするために、上の例では、変数名をstatic_assertion_failedとしています。
その他、C++でtemplateを用いた凝った方法を使うと、もう少し分かりやすいメッセージ表示にすることも可能です(関連書籍が参考になります)。


4894714353 【関連書籍】
Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート活用術

バグを潜伏させない工夫 - バグをいかに目立たせるか

とにかく目立て
Be visible
リチャード・ブランソン

一般的にバグの発生箇所と発現箇所が離れれていると、デバッグは難しくなり、時間もかかりがちです。今回のお話は、このような「バグの潜伏」を抑制し、「バグ」にいち早く気付かせるための実装上の工夫についてです。

ライブラリ設計において、何らかのオブジェクトにアクセスするIDを定義することがあります。例えば次のような関数定義があったとします。
file_id_t open_file(const char* path, int flags);
ssize_t   read_file(file_id_t id, char* buf, size_t size);
ssize_t   write_file(file_id_t id, const char* buf, size_t size);
off_t     seek_file(file_id_t id, off_t offset, int whence);
int       close_file(file_id id);
fileをオープンする関数によって返されたID(file_id_t型)が返され、以後のファイルアクセスはこのIDを介しての操作になっています。Linux等POSIX系システムで開発されている方はお気づきかと思いますが、上記の関数はPOSIXのI/O関連のsystem callのopen()/read()/write()/lseek()とほぼ同じ形をしています。POSIXでは、file_id_tに相当するのはint型のfile descriptor(fd)になります。POSIX系システムでは、ファイル以外にもsocketやデバイスドライバ等も同様のインターフェースでアクセスされます。POSIXで言えば、プロセスIDやユーザID等のIDもインターフェースに登場します

このようにopen等の関数で一旦捜査対象のIDを取得し、その後はそのIDで操作すると言うインターフェースは様々なところで見られます。このようなIDを用いたインターフェースの利点は何なのでしょうか?全てのインターフェースにファイル名等の文字列をそのまま用いる方法ではだめなのでしょうか?あるいは、IDではなくファイルオブジェクトへのポインタを返すというのでは駄目なのでしょうか?
IDを用いたインターフェースの利点は次のようなものが考えられます。
  • int型等の単純な型を用いることにより、対象の発見コストが低い
    (int型の比較と文字列方のstrcmpをイメージしてみて下さい)
  • IDの有効範囲を適切に設定すれば、プロセス間、システム間のやりとりが可能。
    ポインタでは同一メモリ空間内でしかやりとりできない。
上記の理由などにより、インターフェースにIDを利用するというのは一種の常套手段です。

前振りが長くなりましたが、今回の話題は「IDにどのような値を用いるべきか」という点です。
多くの場合、IDは「特定のオブジェクトを一意に指すもの」として定義される程度で、その値が具体的にどのような値を持つかという点については外部仕様として定義されないことも多いかと思います。IDはマジックナンバーとして利用されるものですので、利用する側が特定の値を期待してはいけません。そう考えると、IDの値について定義しないというのは順当だと考えられます。
外部仕様としてはIDの値について具体的な定義はしないものとしたとしても、実装側としてはどのような値を持たせるべきでしょうか。外部仕様を満たすだけであれば、何でも良いでしょう。例えば、
  • 0から順番にインクリメントした値を振っていく
  • 利用されなくなったIDは再利用する
というルールがまず思い浮かびます。Linux等のfile descriptorはこのような実装です。しかし、このような実装にはいくつかの欠点があります。それは、
  • 0は偶然利用される可能性が高い
  • IDの再利用は、IDの取得/解放シーケンスにバグがあった場合に、複雑なバグをまねきやすい
というものです。つまり、偶然それらしい値が指定されることで、中途半端な動作をまねき、バグが発見されにくくなるというものです。これらは、ライブラリ使用側が埋め込んだバグによって起こる問題で、ライブラリ作成者に責任はありません。しかし、IDの値をちょっと工夫してやれば、ライブラリ使用者にもっと早い段階でバグに気付くチャンスを与えることができます。例えば、次のようなルールを導入してみます。
  • 特殊な値、(0,1は~1(0xffffffff)等)はIDとして使用しない
  • IDは(極力)再利用しない
  • IDは1インクリメントで生成せず、2や3インクリメントなどで生成する
これによって、0や0xffffffffといった偶然入ってしまいがちなIDは指定されたば段階で間違いを指摘することが出来ます。また、IDの再利用をしないことで、シーケンスバグによってバグが複雑化することをさけることができます。最後の「1インクリメントでID生成しない」というのは、IDを配列の添え字のようなインデックス値と同様にインクリメントして使用してしまっているコードでの偶発動作を防ぎます。
どれも、偶然適当な値が入ることによって中途半端に動作が継続し、バグの発見が遅れたり、解析の手間が増えることを防ぐ効果があります。

と、ここまでIDの値という点で書きましたが、話の趣旨は次の二点に集約されます。
  • 外部仕様に出ない部分でも、ちょっとした工夫をするかしないかでデバッグ効率は大きく変わる
  • バグを含むコードであっても「偶然」や「なんとなく」で動作を継続させるとデバッグが難しくなる。 バグのある地点にできるだけ近い地点でバグに気付かせることで、デバッグ効率は上がる

ライブラリ設計において、機能性、拡張性、柔軟性等を考えることは勿論ですが、開発時にバグが混入し難い、バグ混入しても発見しやすい工夫といったことも頭に入れて置きたいですね。

【関連記事】
デバッグ指向のススメ

間違いを計算に入れる

調べ物をしようと思って検索エンジンにキーワードを入力して検索。「思ったより情報が少ないなぁ」なんて思ったら、実はスペルが間違っていた。

このような経験はないでしょうか。例えばメールソフトのThunderbird。「Thanderbird」や「sanderbird」「Thunderbard」では所望の検索結果は得られません。
一般的な英単語の微妙なスペル間違いであれば、Googleのスペル候補表示等で気付くこともありますが、キーワードが固有名詞だったり日本語だったりするとそうもいきません。
そもそもよく知らないものを調べようとしているわけですから、単語自体もうろ覚えということは少なくありません。
時には、情報側の方が間違っていることもあります。先程のThunderbirdの例では、「Thunderbard」や「Thanderbird」でも数百件のページがヒットしますが、これらは情報側が間違っているということを示しています。

以前「間違えやすい日本語」という記事を書きましたが、時には間違った表現の方が多く使われていることだってあります。例えば、「押しも押されぬ」と「押しも押されもせぬ」では、本来正しいはずである「押しも押されもせぬ」の方がヒット数が少なくなっています。

このような人間のしでかす間違いを逆手にとったサービスがあります。そのひとつが、百式さんで紹介されていたFat Fingersというサイト。オークションサイトeBayから検索するサービスなのですが、間違いがちなスペルを合わせて検索してくれるため、間違ったスペルで出品されているものも見逃さず検索してくれます。Googleのスペル候補
SEO等のマーケティング戦略として、このような「うろ覚え」をどう扱うかというのは面白そうなテーマです。

人間は間違えます。以前の記事(デバッグ指向のススメ)で書いたデバッグ指向プログラミングも、この考えに基づいた考え方です。

「間違いをなくす」ことはできませんが「間違いを計算に入れる」ということはできます。

【関連記事】
間違えやすい日本語
デバッグ指向のススメ

【関連リンク】
百式 - 間違いを計算にいれる
「うろ覚え」ユーザーを獲得しよう (japan.internet.com)

【関連書籍】
とっておきの秘技 Google検索の秘伝書 持丸 浩二郎 蒲生 睦男
ググる―検索エンジンGoogleを使ってネット上の情報を検索すること 津田 大介

ブラウザをRSSリーダーに

Firefox用のRSSリーダー拡張のsageをインストールしました。これは本当に便利。すごく快適になります。
Firefoxにはデフォルトでライブブックマークと呼ばれる一種のRSSリーダー機能がありましたが、フィードのタイトルしか確認できない、既読/未読がわからない、というあたりがネックであまり使っていませんでした。しかし、ブラウザ自体でRSSの確認が出来る、RSSの存在を発見してくれる、RSSの発見や登録が簡単、というメリットは捨てがたいものがあります。sageをインストールすれば、上記ライブブックマークの利点はそのまま、上記のsageの欠点もなくなって、Firefoxを非常に強力なRSSリーダーとして利用できるようになります。

sageはFirefox用ですが、IEにもRSSバーという同種の拡張があります。ちょっと使ってみましたが、個人的には、RSSフィードの発見・登録やフィード内容の表示等の機能がsageのより洗練されており使いやすく感じました。
RSSバーは高機能のタブブラウザSleinir用にも提供されていましたが、Sleinir 2.0からはプリインストールになったようです。

RSSリーダーはbloglines等のサーバーサイドサービスや、Thunderbirdのようなものもあり、それぞれに利点はあります。情報ソース毎に何が一番便利かは変わってくると思いますが、ブラウザのRSSリーダー機能の手軽さは非常に魅力的です。是非、使ってみてください。

(※)「Sage」は「セージ」と読むそうです。「サゲ」と読まれそうですが・・

【関連リンク】
RSS-search RSS情報サイト
sage - Firefoxまとめサイト
Firefoxで遊ぼう(FirefoxをRSSリーダーにしてしまうの巻)
RSSバー オフィシャルサイト
Sleinir 公式ページ
【関連書籍】
詳解RSS~RSSを利用したサービスの理論と実践
ブログユーザーのためのRSS徹底活用ガイド

商標の話

いいアイディアなら、いいからやってしまえ。許可を得るより、謝るほうがずっと簡単だ。
マーレイ・フーパー

7-ELEVEn セブンイレブンのロゴを良く見ると、「7-ELEVEn」と最後のnだけが小文字になっています。最近Blogの記事に書かれているのを見て、始めて気がつきました。看板と言うのは毎日ほど見かけているものでも案外細かいところは気にしていないようです。
「n」の理由には諸説あるようですが、
・商標としては、単なる数字のままでは認められなかったので、最後のnだけ小文字にして独自性を出した
という最もらしい答えがあるようです。

「商標」といえば、最近Windowsの定番エディタ「秀丸エディタ」の作者によるメールソフト「鶴亀メール」が商標の問題で「秀丸メール」に名称変更していました。その他、ちょっと前だと「阪神優勝」、もう少し最近では「ホリエモン」や「風太」も話題になっていましたね。身の回りには一般名称だと思っているものが、特定の商品を指す「商標」であることがよくあります。トリビアの泉などのテレビ番組でも取り上げられています。意外なものもあって面白いので、少し紹介しておきます。

一般名称として使用されがちなもの
4062111551
商標名登録者一般名
ウォークマンソニーポータブルプレイヤー
宅急便ヤマト運輸宅配便
デジカメ三洋電機デジタルスチルカメラ
ポリバケツ積水化学工業プラスチックバケツ
エレクトーンヤマハ株式会社電子オルガン
ホッチキスホチキスステープラー
セロテープニチバンセロハンテープ
タッパー日本タッパーウェア株式会社食品密閉容器?
着メロアステル着信メロディ

意外なもの
商標名登録者一般名/補足
マルチタスクNEC 
イーサネット(ETHERNET)富士ゼロックス 
ホワイトチョコレート六花亭白チョコレート?
アーモンドチョコレート江崎グリコアーモンド入りチョコレート?
ウーパールーパー 正式名はアホロートル
弾丸ツアーJTB 
A-SHOCK~Z-SHOCKカシオ計算機G-SHOCKのパクリ対策にAからZまで全部登録!
NO17LION上下さかさまにするとLION
1・2・3ダァーアントニオ猪木事務所 


商標のチェック最近始めて知ったのですが、Wordには、上で挙げたような商標や商品名をチェックする機能が付いています。メニューから[ツール]→[オプション]→[文書校正]→[詳細設定]でダイアログを開いて、「商標・商品名」にチェックを付けます。これで、「宅急便」等の単語は波線で警告されるようになります。公式なドキュメントを作成する際にはいいかもしれません。

意外な商標に関しては、他のサイト(関連リンク参照)にもいろいろと紹介れています。
ここまで来ると、犬も歩けば・・・ってとこですね。

(※)セブンイレブンのHPには、『理由についてはこちらでも分からないというのが現状です。(中略)「デザイン性を持たせるためにnだけ小文字にしたのではないか」など社内での憶測はありますが、この「真相」については迷宮入りのようです。』とあります(^^;)。

【関連書籍】
なぜみんなスターバックスに行きたがるのか? Scott Bedbury 土屋京子
アシモフの雑学コレクション 星新一 Isaac Asimov
トリビアの泉〈第1巻〉―へぇの本 フジテレビトリビア普及委員会

【関連リンク】
特許電子図書館(特許庁)
雑学大作戦:知泉 [登録商標]
登録商標を探せ
鶴亀メール、「秀丸メール」に名称変更
Wordで商標や商品名をチェックする

C++関連書籍

C言語を使うと自分の足を誤って撃ち抜いてしまうことがある。 C++を使えばそのような間違いを犯しにくくなる。しかし、やってしまったときには足全体が無くなる。
Bjarne Stroustrup

C組み込み系ではまだまだC言語が主流ですが、オブジェクト指向とともにC++も徐々に広まってきています。最近も知り合いから「プロジェクトでC++を使うことになったんだけど、おすすめの本ってない?」と聞かれることがありました。Webだけでも十分情報は集まりますが、活字の形の方が便利なこともあります。
そこで、今回は個人的におすすめのC++本を紹介したいと思います。

Effective C++ 原著第3版 スコット・メイヤーズ
4894714515 C++のバイブルとして評判の高い一冊です。その評価は、私も過言ではないと思っていますので、C言語の経験のある人にC++本を紹介する時は、必ずこの本を薦めています。
CからC++への移行する時のポイント、new演算子のオーバーロード、コンストラクタの挙動、オブジェクト指向設計等、C++プログラマなら知っておくべき内容で、かつ他の書籍では意外と触れられていないことが多い内容が、非常にわかり分かりやすく書かれています。
アスキーのHPでページサンプルのPDF(序章、第一章 CからC++への移行、第二章 メモリ管理)がダウンロードできます(※1)。

More Effective C++ ― 最新35のプログラミング技法Scott Meyers (アスキー)
4894714760 Effective C++の続編です。前回と比較してよりつっこんだ内容になっており、どちらかと言えば中級者以上向けとなっています。placement new、仮想コントラクター、スマートポインター、参照回数計測、プロキシークラス、二重ディスパッチなどの応用テクニック、例外機構の留意点等が詳しく解説されています。取り上げられている応用テクニックをそのまま使用することはないとしても、そのコーディングのテクニックや設計思想は、非常に参考になります(※2)。

プログラミング言語C++ 第3版Bjarne Stroustrup
プログラミング言語 C++これもまたC++言語のバイブルとされる一冊です。C++言語の開発者であるBjarne Stroustrupによって書かれたもので、C言語で言えば、K&Rのプログラミング言語Cのようなものと言ってもいいのではないでしょうか。ANSI/ISO C++の最終標準仕様について、templateに例外、STLコンテナからalgorithmまでC++仕様が網羅的に解説されています。
但し、内容が濃い分、非常に分厚い本なので、電車の中で気軽に読むなんてことはできません。内容もある程度の知識を前提として書かれているため初心者向けでもありません。しかし、文章は分かりやすく、内容も充実していますので、C++をある程度理解したら、是非とも本書を読破してほしいところです。 リファレンスとしても机の上に是非置いておきたい一冊です。

独習C++ ハーバート・シルト (翔泳社)
独習C++ 独習C独習Perlと同じ独習シリーズのC++版。著者も独習Cと同じです。私は独習シリーズを通読したことはありませんが、周りの評判が良さそうなのでとりあげておきます。このシリーズの特徴は、分かりやすさです。ですので、初心者の方は、まずこの本で概要を理解して、ある程度使えるようになったのちに、上の書籍でステップアップというのがいいかもしれませんね。

C++プログラミングの処方箋―ひと味違うコードを書くための99の鉄則 Stepehn C. Dewhurst
4798106321 プログラミングを学ぶ最もよい方法は、優れたコードを読むことです。しかし、逆に悪いコード、あるいは失敗例から学べることもまた多いものです。本書は、いわば陥りがちなアンチパターンの紹介と、そこから導かれる原則、テクニック等を紹介しています。自分で失敗すると身にしみて学習することはできますが、それには長い年月がかかります。まずは、人のふりみてわがふり直せということで、ここから学べることは非常にたくさんあります。ここで紹介している他の書籍程、紹介例を見かけない気がしていますが、もっと評価されてもよい良書だと思っています。
C++中心ではありますが、Cプログラマをはじめその他の言語を使うプログラマにとっても参考になるところは多いと思います。

Boost C++Librariesプログラミング 第2版 稲葉一浩
Boost C++ Librariesプログラミング 「C++標準」であるSTLは洗練されてはいますが、いまひとつかゆいところに手が届かない。物足りない。ということでC++言語標準化委員会メンバーが、さらに強力なライブラリを求めて作られたtemplateライブラリが「Boost」。本書はその「Boost」の日本語リファレンスといった内容です。気が付けば第二版がでていました。
まずSTLから、という方に関しては、「Effective STL―STLを効果的に使いこなす50の鉄則 (Scott Meyers)」あたりが定番でしょうか。

Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート活用術 Andrei Alexandrescu
4894714353 この本は入門書ではありませんのでご注意を。C++のtemplateを使いこなしたいという中・上級者向けの内容です。タイトルにも「究極のテンプレート活用術」とありますが、templateの特性を最大限に引き出すテクニックが満載です。しかし、あまりにトリッキーなため、実装を一読しただけでその意味するところを理解するのは常人では不可能です(できあがったパターンを利用するのは可能でしょうが)。よって、実際のプロジェクトで使う時には注意が必要かもしれません (^^;)。
本書については、templateを使った実装上のテクニカルな内容も圧巻ですが、ポリシーを基にしたクラス・デザインといった設計上の考え方等も一読の価値があります。C++、特にtemplateを極めたい人にとっては必読でしょう。

C++の設計と進化 Bjarne Stroustrup
C++の設計と進化私自身この本はまだ読んでいませんが、是非読んでみたいと思っていますので挙げておきます。C++の設計者であるStroustrup氏がC++言語自身の設計思想と開発経緯に関して語った本です。C++は非常に複雑な言語仕様から敬遠されることも多いですが、私はその強力な記述能力は好きです。多重継承も使い方によっては非常に便利な仕様です。ようは道具の使い方の問題です。
言語設計の背景と経緯を知ることは、言語を使う側にとっても有益でしょう。


※1 最初に紹介したときは第二版でしたが、第三版がでたので更新しました。
※2 2007/7に新訂版もでています。

質問する前に調べる

質問をする前に、まず自分で調べてみる。質問をする時の最低限のマナーです。
トラブルシューティングやHOWTOであれば、掲示板やMLの過去ログ、マニュアルやFAQをまず見ます。キーワードが分からないのであれば検索エンジンで十分な情報が得られることが多いでしょう。

とはいえ、実際は、「調べれば簡単に分かる」ような質問をされることも多々あります()。そんな時、「次からはまず調べてからお願いしますね」とやんわり(でもない気がしますが)と伝えてくれるサービスが百式さんで紹介されていました。

Google It, You Moron (http://www.googleityoumoron.com/)

質問を受けたら、ここで生成されるアドレスをメールで送ってあげましょう。例えば、「volatileって何ですか?」と質問された場合、次のリンクを教えてあげます。
http://www.googleityoumoron.com/?go=volatile
"I will use Google before asking stupid questions."「次からはしょうもない質問をする前にはGoogleを使います」という表示の後、Googleの検索結果が表示されます(^^)。日本語が通らないのはちょっと残念です。

答えを教えるのだけではなく、答えの探し方をさりげなく教える。
効果の程は怪しいですが、その考え方、それに遊び心はいいですね。

【関連記事】
検索力
volatileで最適化を抑制する
【関連リンク】
百式 - 先人の知恵を伝える (Google It, You Moron)


自分もすることがあります。要反省 (^^;)

過学習と局所解

もし、私が電気の専門家であったなら、電話を発明することはできなかっただろう。
何故なら、そんなものは最初から不可能だと決め付けたであろうから。
グラハム・ベル
冒頭の引用にあるベルの言葉※1は、たまたま見たテレビ番組で取り上げられているの見て初めて知りました。非常に印象的な言葉でした。

技術者として仕事をしていると、無理難題とも言える仕様、無理なスケジュールを突きつけられることが良くあります。そんな時、ついつい「無理を言うのは技術を分かっていないからだ。無理を言われても困る」と考えがちです。しかし、実際は中途半端に技術を理解しているがために視野が限定され、結果として発想力に乏しくなっているのは技術者の側、ということもあるのではないでしょうか。ここで、学生の頃かじったニューラルネットワーク(Neural Network)や遺伝的アルゴリズム(GA)のことを思い出しました。

ニューラルネットワークとGA。どちらも生命現象にヒントを得た最適化/学習モデルです。このような最適化/学習モデルでよく課題として登場するのが「局所解問題(ローカルミニマム問題:local minumum problem)」や「過学習(Overfitting)」です。
局所解問題を簡単に説明するとすれば、「部分的な最適解に系が収束し、本当の最適解にたどり着かない」という現象です(※1)。
過学習の方は、「特定の入力と出力の組み合わせ(学習データ)に対して系が収束しすぎたために、その他の入力(非学習データ)に対する汎用性がなくなってしまう状態」といったところでしょうか。同じ教師パターンで何度も学習を繰り返すことによって発生します。これは、特定のパターンにのみ最適化された局所解に陥ってる状態と見ることができます。

ニューラルネットワークはもともと脳の神経回路を模したモデルですから、実際の人間の脳に関しても同様の現象が見られます。例えば、年を取るほど頑固になるという現象。これは、長期間同じ思考パターンを繰り返している(過学習状態になる)と脳内のシナプ結合が特定のパターンに収束してしまっている(局所解に陥っている)ために起こっていると考えることができます。

冒頭のベルの言葉は、技術者が過学習によって局所解に陥ってしまいがちだということを表しているように理解できます。専門知識に精通すればするほど、その分野の常識にしばられて突飛な発想ができない。まさに、過学習によって局所解に陥っている状態です。

過学習というのは「勉強しすぎ」が問題なのではありません。学習データのパターンが限定されるのが問題なのです。つまり、まずはもっと視野を広げて、幅広い情報に触れることが重要なのです。直接関係のないもの程、役に立つ確立は低いですが、その分発想の飛躍を与えてくれることもあります。
漸近的努力だけでは局所解からは脱出できません。時には確固たる「信念」のようなものも重要ですが、ブレークスルーには発想を飛躍させるための「雑音(ノイズ)」も必要なのです。

最後に、SFの巨匠アーサー・C・クラークの残した有名は言葉を紹介しておきます。
"When a distinguished but elderly scientist states that something is possible he is almost certainly right. When he states that something is impossible, he is very probably wrong."
「著名な、だが年老いた専門家が、何かが出来るというとき、それはおそらく正しい。しかし、何かは不可能だというとき、それは絶対に間違っている」
"The only way of discovering the limits of the possible is to venture a little way past them into the impossible."
「可能性の限界を見極める唯一の方法は、不可能の領域に足を踏み入れてみる事だ」
"Any sufficiently advanced technology is indistinguishable from magic."
「十分に進歩した科学技術は魔法と区別が付かない」
不可能も可能になり得ます。技術者として、不可能への挑戦の気持ちは忘れないでいたいものです。

【関連リンク】
電話の歴史
ニューラルネット入門
Metal Brain(ニューラルネットワークに関する解説があります)
【関連書籍】
学習とニューラルネットワーク (熊沢 逸夫)
遺伝的アルゴリズム (北野 宏明)


(※1)ベルの言葉といえば、初めての電話を通した言葉、"Mr. Watson, come here, I want you." 「ワトソン君、すぐ来てくれ。頼みがある」も有名ですね。
ベルが難聴者教育に熱心であり、ヘレン・ケラーとの交友が深かったことも同じテレビ番組で初めて知りました。

(※2)解空間が多峰性をもつような場合に、バックプロパゲーション等の最急降下法的なアルゴリズムでよく問題になります。

本のおすすめ

4274065979

4844337858

482228493X

4904807057

4873114799


プロフィール

  • Author:proger
  • 組み込み関係で仕事してます

ブログ内検索