雑記の最近のブログ記事



Chapter 6 - プロセス間同期


Chapter 4まででマルチタスクの実現のための仕組みを説明しましたが、マルチタスクであるが故に起きる問題があります。


クリティカルセクション(Critical Section Problem)

ある計算機上で複数のプロセスが動いているとき、競合が発生することがあります。具体的には:



  • 共有している変数の変更

  • DBにおけるテーブルの更新(Operating System Conceptには挙げられていますが、実際にはDBの場合はこんなにシンプルじゃない気がする)

  • ファイルの更新


というようなものが挙げられます。あるプロセスとあるプロセスが同時にこういった処理を行うと、最終的な結果に不整合が発生することが考えられます(2009年8月9日時点のWikipediaの解説がわかりやすいです)。


こういった処理をクリティカル・セクション(Critical Section:以下"CS")と呼びます。


クリティカルセクションを処理する

CSを処理するプログラムは次のようなセクションにわかれます。



  • entry section: CS処理の前処理(資源のロックなど)

  • critical section

  • exit section: CS処理の後処理(資源のロックの解放など)

  • remainder section: 残りの処理(要するにクリティカルセクションとは関係ない処理


それと同時に、CSを処理するプログラムには次の3つの性質が求められます:



  1. 相互排他: あるプロセスがCSを処理している間は、別のプロセスはCSを処理できない

    • 原文ではMutal Exclusionで、これは割と有名なMutexの語源らしい



  2. 連続性: CSの入り口(entry sectionね、たぶん)で待っているプロセスのみ、次にCSを処理するプロセスとして選ばれうる

    • でも、Progressの意味合いからすると「Critical sectionを処理せずにremainder sectionを処理することはない」または「Critical sectionに入れないからといって、critical sectionを飛ばしてremainder sectionに入っちゃうようなプロセスは選んであげない」のようにも読めるのだよなあ



  3. 有限の待ち時間: プロセスがentry sectionで待たされる時間は有限か、制限がある(原文では"There exists a bound, or limit on the number of times..."となっており、boundはcritical sectionが有限時間で終わる(ことが推奨される)こと、limitは有限時間でcritical sectionを負えないプロセスは強制終了するべきであることを意味している、と思う)


ピーターソンの方法

上記の性質を満たすCS問題の解法として、2つのフラグ変数と1つの状態変数を用いる"ピーターソンの方法"があります。2つのフラグ変数というわけで、この方法はプロセスがふたつの場合にしか利用できません。


PiとPjの場合を見てみます。



int turn;
boolean flag[2];
do{
// entry section
flag[i] = TRUE;
turn = j;
while( flag[j] && turn == j);

// Here is cretical section

// exit section
flag[i] = FALSE;

// remainder section
}while(1);
// ※C言語でシンタックスハイライトしていますが、C言語ではありません
// entry sectionでturn = jする理由がいまいちわからないなー

同期ハードウェア

ピーターソンの方法はソフトウェア的な実現でしたが、ハードウェア的な実現もできます。


セマフォ

ピーターソンの方法や、ハードウェアを利用した方法を抽象化したのがセマフォです。


セマフォは整数値を持つオブジェクトで、WaitSignalという2つの操作だけが提供されています。


Waitは次のように表現されます:



wait(s){
while( s <= 0)
;
s--;
}

Signalはこうです:



signal(s){
s++;
}

例によってC言語ではありませんので念のため...


waitがentry sectionのための関数で、signalがexit sectionのための関数です。間違えると混乱する点が、セマフォの初期値は0ではないということです。


要するに:



  • 初期値nのセマフォ

  • CSを処理する前(entry section, セマフォではwaitですね)にデクリメントする

  • CSが終わったら(exit sectionなのでセマフォではsignal)インクリメントする

  • waitしたとき、セマフォが0になっていたら待ち続ける


ということなので、結果的に:



  • n個のプロセスがcritical sectionに入っていたらセマフォは0

  • n+1個めのプロセスはwait内で待ち続ける

  • いずれかのプロセスがsignalすればセマフォは1なので、n+1個めのプロセスがCSに入る

  • CSに入るプロセスの数をn個に制限できる!


ということになります。


バイナリセマフォ(Mutex)

で、初期値が1のセマフォなら同時にCSに入れるプロセスの数は1個なので、相互排他が実現できていることになります。n>1の場合と異なり特殊なので、特別にバイナリセマフォとも呼ばれますし、Mutex(ミューテックス)とも呼ばれます。


セマフォの場合、ピーターソンの方法と違ってCSを処理したいプロセスがn個あっても大丈夫なので、非常に実用的です。実用的なのでいろんな本に載っていて、学術的なテキスト(Operating System Concepts)に載っていてちょっとびっくりしました...


参考文献



  1. ”Operating System Concepts” 2004/12 (Abraham Silberschatz他)

  2. Wikipedia - セマフォ

  3. Wikipedia - ミューテックス

  4. ファイヤープロジェクト - セマフォ

Operating System I

| コメント(0) | トラックバック(0)



Chapter 1 - OSとは何か


オペレーティング・システムとはなにか

OS(Operating System)とは、具体的には:



  • Unix

  • Linux

  • Windows

  • MacOS


などが挙げられます。


OSも、動作するレイヤーこそ違えど我々が書くべきプログラムのひとつです。そのことを念頭に据えてオペレーティング・システムの世界を概観してみましょー。


OSの目的

OSが必要な理由は大まかには次のふたつです。これらの意味するところは、あとのほうでわかってきます。



  1. ユーザのプログラム(アプリケーション・プログラム)を実行し、ユーザが計算機で問題を解決するのを簡単にする

  2. 計算機システムを使いやすく整備する


計算機システムの構造

計算機システム全体は、大まかには次の4つのものから成り立っています。



  1. ハードウェア: ディスプレイやハードディスク、メモリとかその辺です

  2. OS: ここで話題にしている、オペレーティングシステムです。基本ソフトウェアと呼ぶこともありますね

  3. アプリケーション: OSの上で動作するプログラムです。ワープロからブラウザ、コンパイラも電卓も

  4. ユーザ: 計算機の利用者です。私でありアナタであり、場合によっては他の計算機である場合もあります


ストレージ

計算機システムでは、計算の経過や結果を保存するためのデータの保存領域が重要になります。ストレージと呼ばれます。


ストレージは、以下の3つのパラメータがあります。



  • 速度: 単位時間当たりに書き換えられるデータ量

  • コスト: 単位記憶容量当たりの製造コスト

  • 揮発性の有無: 給電が途絶えた際に記録が保持されるかどうか


基本的に、速度とコストはトレードオフの関係にあります。揮発性の有無は他のふたつとは独立のパラメータで、記憶の実現方式に依存するケースが多いです。


以下に、典型的な記憶機器を列挙します。上から高速・高コスト(小容量)順で、下にいくにつれて低速・低コスト(大容量)になります。



  • CPUレジスタ

  • CPUキャッシュ

  • メインメモリ

  • 電気ディスク

  • 磁気ディスク

  • 光学ディスク

  • 磁気テープ


それから、重要な機能のひとつに「キャッシュ」があります。キャッシュとは、頻繁にアクセスされるデータが遅いデバイスにある場合、速いデバイスに移しておくことで計算の高速化を図る手法です。


Chapter 2 - OSの構造


OSは以下の機能をユーザに提供します。



  • ユーザ・インターフェイス

  • プログラムの実行

  • 入出力の制御

  • ファイルシステムの操作

  • 通信

  • エラー検出


概ね、ハードウェアのラッパーであると考えてよさそうですね。


システムコール

上記の機能をユーザプログラムから利用するために、システムコールが用意されています。


システムコールは基本的にAPI(Application Programming Interface)の形態で提供されますが、実際にはシステムコールの実体はカーネルと呼ばれるプログラムの一部です。


ユーザプログラムに呼び出されたAPIは、関連付けられたシステムコールをOSの中から探し出して実行し、システムコールのステータス(成功したかどうかなど)と何かしらの値を返します。


APIから利用する限り、ユーザプログラムの開発者はシステムコールがどのように実装されているかに気を配る必要はないので、基本的にはAPIからの利用が推奨されています。


(講義ではここでMS-DOS, UNIX, Mac OS X, Solaris, VMware, Java Virtual Machineでの実装を紹介しています)


Chapter 3 - プロセス


プロセスとはなにか

OSの中では、常にたくさんのプロセスが動いています。


プロセスはときに「ジョブ」とも呼ばれるとおり、抽象的にはOSの作業のひとつの塊を意味します。プログラマ的に考えるなら、プログラムの実行時の実体がプロセスである、ともいえます。


わたしのメモリの中のプロセス

プロセスはメモリ上で、以下の4つの領域を持ちます:



  • stack: ローカル変数など、コンテキストに応じて増減するものが格納されています

  • data: グローバル変数など、プロセス内で共有されるデータが格納されています

  • heap: 動的に確保された領域(mallocなどによって)が格納されます

  • text: プログラムのコードそのものが入ります。コードといってもソースコードではなく、コンパイラによって翻訳された機械語です。


この中で、stackとheapはプログラムの実行中に必要な領域が変化することがあります。stackは関数呼び出しがネストした場合、heapはmallocなどにより新たにメモリが要求された場合に増加し、それぞれその逆の場合に減少します。


プロセスの状態

複数のプロセスを同時に処理すること(マルチプロセス)を実現するため、プロセスは状態を持つことが多いです。


シンプルに考えるため、2状態のものを考えます。プロセスは、以下の2つの内どちらかの状態を持ちます:



  • Running

  • Not Running


それぞれ文字通りの意味で、あるプロセスがRunningであるとき他のプロセスはNot Runningです。


実際には、5状態のモデルが利用されることが多いです:



  • New: あたらしく生成されたばかりの状態です

    • [Admit]->Ready



  • Ready: 実行される準備ができた状態です

    • [CPU Dispatched]->Running



  • Running: 実行中の状態です

    • [Interrupt]->Ready

    • [I/O event wait]->Waiting

    • [Exit]->Terminated



  • Waiting: 入出力の完了を待っている状態です

    • [I/O event completed]->Ready



  • Terminated: 実行が終了し、OSにより削除されるのを待っている状態です


[カッコ]内のイベントで対応する状態に変化します...が、こちら図を見るほうがわかりやすいです。


Process Controll Block

CPUがプロセス(と、その状態)を管理するため、Process Controll Block:PCBというデータが準備されます。PCBの中には以下のような情報が格納されています。



  • プロセスの状態: 先ほど説明したプロセスの状態です

  • プログラムカウンタ: 現在どこまでプログラムを実行したか(実際には、次に実行すべき命令があるアドレスはどこか

  • レジスタ: RunningだったときのCPUのレジスタの状態(レジスタは次にRunningになったプロセスにより上書きされてしまうので、ReadyやWaitingになる際には一時退避しておく必要がある)

  • CPUのスケジューリング情報(Chaper 5で)

  • メモリ管理情報(Chapter 8で)

  • プロセスの管理情報(Process numberやProgrammCounterもここに含まれる?)

  • 入出力情報


Chapter 4 - スレッド


マルチタスクを実現するためにプロセスという考え方が生み出されましたが、より効率的で先進的な並列プログラミングのためにスレッドという考え方も現れました。


スレッドとは、ひとつのプロセスの中でtextとdataとfiles(PCBにおける入出力情報、どんなファイルやデバイスを開いているか、など)を共有し、スレッドごとに独立のレジスタ領域とstack領域を持たせたものです。


スレッドを利用するメリットは以下の4つがあります:



  1. 応答性: 重い処理とUIのイベント処理を別のスレッドにすることで、体感速度や利便性の向上が見込める

  2. リソースの共有: dataやfiles, textは共有される

  3. エコノミー: リソースを共有しているので、実行しているプロセスの切り替えに比べてスレッドの切り替えは計算機的コストが低い

  4. マルチコアCPUの機能を利用できる: マルチコアCPUを利用している場合、スレッドごとに別のコアで処理できる


Chaper 5 - CPUスケジューリング


マルチタスクOSでは、プロセスを実行する順番も大切になります。どういった順番でプロセスを実行するかを決めることをスケジューリングといいます。


マルチタスクの実現方式 - preemptivbe, non-preemptive

スケジューリングにはプリエンプティブなものとノン・プリエンプティブなものがあります。


プリエンプティブなマルチタスクとは、プロセスの実行をOSが強制的に中断でき、OSの裁量でスケジューリングできるものを言います。preemptionとは横取りのことで、CPUがプロセスの実行権限を横取りすることからこう呼びます。近代的なOSはだいたいプリエンプティブです。


ノン・プリエンプティブなマルチタスクとは、プロセスの実行の中断をプロセス自身に委ねており、OSにスケジューリングの権限が(基本的には)ないものを言います。ノン・プリエンプティブ以外にコーペレイティブ(cooperative)とも呼ばれます。こちらは「協調的な」などといった意味で、マルチタスクの実現にプロセスの協調が必要なことからこう呼ばれます。


スケジューリングの評価尺度

プリエンプティブにせよノンプリエンプティブにせよスケジューリングのアルゴリズムには種々ありますが、その前にスケジューリングをどのように評価したらよいかを考えます。



  • CPU utilization: 計算リソースを余すことなく利用するには、できるだけCPU使用率を高く保つ必要があります

  • Through put: 単位時間当たりに処理できるプロセスの数

  • Turnaround time: CPUでの計算時間やメモリの確保、I/O待ちなども含めたひとつのプロセスの開始から終了までの時間

  • Waiting time: 計算時間以外の待ち時間

  • Response time: ユーザの操作に対して応答が帰るまでの時間。インタラクティブなシステムでは、ビジーになってばかりでは利便性に劣ります。Response timeはChapter 4において、スレッドを使うことで改善できることがわかっていますね。


First Come, First Served: FIFS

先に入ってきたプロセスから処理します。早い者勝ちで、基本的にノンプリエンプティブな方式です。


Shortest Job First

処理に要する時間が短いプロセスから処理します。これはプリエンプティブでもノンプリエンプティブでもいけます。


処理に要する時間がわからなければならないので、実用は困難です。バッチ処理とかで使われるらしい?


Priority Scheduling

プロセスに優先度をつけて、優先度の高い順に処理していきます。プリエンプティブでもノンプリエンプティブでも大丈夫です。


Round Robin

プロセスの処理内容に関わらず、一定の時間間隔で実行するプロセスを切り替える方式です。プリエンプティブです。




オープンソースの文化祭, オープンソースカンファレンス2009 Tokyo/Fallにつくらぐとして出展してきました.


つくらぐからは,



  • 配布: これまでの発表の概要をまとめた冊子

  • 展示: 第6回で発表したプログラム

  • 展示: 第2回で発表した機材


という感じでブースの設営を行いました.


個人的には準備した冊子200部+αがすべて受け取っていただけるかどうかがちょっと心配だったのですが, 幸い31日の16時時点で配布完了となりました. 手に取っていただいた皆さま, 貴重な時間をありがとうございました.


準備から終了まで, 万事滞りなく進行してとても満足. みんな楽しんでいたようなので, ぜひ2月のTokyo/Springも参加したいなあ.


以下, 写真など. 重いので別ページにしておきます.


f:id:Tnzk:20091029184716j:image


会場に掲げられていたノボリ. 個人的にはOSCのイメージは青とか(公式サイトの影響だろうねえ)なんだけど, なぜか黄色と赤.


f:id:Tnzk:20091029170235j:image


f:id:Tnzk:20091029164824j:image


f:id:Tnzk:20091029164529j:image


ブース設営中.


f:id:Tnzk:20091029171703j:image


f:id:Tnzk:20091029171653j:image


左右をGentooJPとOpenSorarisというそうそうたる軍勢に挟まれて萎縮しつつブース設営.


f:id:Tnzk:20091029170235j:image


f:id:Tnzk:20091029180647j:image


ブースが大体完成. そこそこの出来になって満足. 次回からはもうちょっとギミックに工夫してみたいなー.


f:id:Tnzk:20091029180806j:image


設営が終わると, エントランスホールで運営陣がパンフレットとかをセットアップしてた.


f:id:Tnzk:20091031153523j:image


@hktechnoが展示の説明中.


f:id:Tnzk:20091031161039j:image


OSC閉幕後, NovellさんがGeekoのぬいぐるみをじゃんけん大会で配布すると宣言. 代表が超ほしそうな目でみている.


f:id:Tnzk:20091031161441j:image


大Geekoは逃したものの, 小Geeko×2は@tnzkと@hktechnoで獲得. かわいい


f:id:Tnzk:20091031162945j:image


終了後, みんなで記念撮影. おつかれさまでした




筑波大学 Linux User Group(つくらぐ)の活動の一環として、オープンソースカンファレンス 2009 Tokyo/Fallに参加します。


参加日程は、



  • 30日: 無人・資料配布

  • 31日: ブースにメンバー数名・勉強会で発表された機材および資料配布


という感じです。30日は平日の金曜日で、きれいにみんな外せない講義が入っていたので泣く泣く無人ということになりました(日程自体は泊まり込みで参加しても日曜日がクッションになって良心的だと思います、念のため)。


31日はみんなで会場に向かい、ブースにいたり講演を見に行ったりする予定です。メンバーはそれとわかるようなストラップをぶらさげていますので、見かけたら声をかけてみてください。


終わったら詳細まとめようと思います。





"It's not that I don't believe in contemporary literature," he added, "but I don't want to waste valuable time reading any book that has not had the baptism of time. Life is too short."



嘘かほんとかわからないけど、村上春樹が「死後何年かした作家の作品以外は評価しない」というポリシーを持っているという話はよく聞かれる. 今日, 授業でやっている英語版ノルウェイの森の和訳(ややこしいねぇ)で, そのポリシーが作中人物によって語られる場面に触れた. 上のものがそれだ.


「時間による洗礼」(baptism of time)というのは大雑把にいうと「何十年にも渡る時間による淘汰が, 本当に良いものだけを選りすぐってくれる」ということだ. これって, 最初に聞いたときはなるほどと思ったけど, よく考えるといまいち納得できない.


つまり, 時間による淘汰というのは大衆による取捨選択に過ぎない, という問題があると思う. 必ずしも良いものが残るとは限らない.


たしかに, 幸運にも後世で再評価される機会があれば, 成立当時は評価されなかった良い作品が残る可能性もある. フランツ・カフカとかがそうらしい. だけどそれは, むしろそういうものの存在は, その影で二度と評価される機会を持たなかったが非常に優れたものが存在するということの裏返しでもある.


今この時代, この瞬間に華やかにスポットライトを当てられたものの影で, 優れた側面を持つにも関わらず「わかりにくい」という理由だけで後世に残らないものも必ずある. 後世に残らないなら, それを味わえるのは今しかない.


そもそも過去の評価はそれほど確かなものだろうか? 今「評価」の代名詞であるメディアが取り上げるのはほとんどの場合ろくでもないものじゃないだろうか? そうやって後世に伝えられてきた作品が, なぜ必ずしも素晴らしいといえるのだろうか?


それから, 現代の作品を読まないというのは「時間による洗礼」への参加を辞退しているということになる.


秋がくる

| コメント(0) | トラックバック(0)



つくば市ではだんだん気温も下がってきて、昨晩半袖で歩いていたら風邪をひいてしまったし、今朝はとうとうパーカーの出番になった。一昨日くらいから一気に気温が下がったように思う。


ここしばらくはずっと、北関東の冬の厳しさを感じている。Yahooの天気予報をブックマークに入れるのが億劫でいつも日本全地図からつくば市までFlashをぽちぽちしているのだけど、ときどき何となく伊勢市の予報も見たりしている。やっぱり、だいたい2度くらいこちらのほうが寒いらしい(特に朝とか、なぜか伊勢市のほうが5度くらい気温が低いことがある。冬の朝に僕が布団からなかなか出られなかったのは仕方のないことだったのだろう...というわけではない?)。


なつやすみ中に帰省して、それ自体はなかなか楽しかったのだけど、タイミング悪く持病が激化(悪化なんてもんじゃなかったなあ)してしまって以降、いろんな活動(大掛かりなことも、小さなことも)を停止していた。たぶん少なくない人に迷惑をかけたと思うので、誰も見ていないかもしれないけどここで謝っておきたいと思います。


時間が経つのは恐ろしいくらい早くて、つい最近はじまったはずの2009年も残すところあと3ヶ月足らずとなっている。高専をドロップアウトして大学に入って、たくさんの環境がいろいろな方向に変化した。僕はその変化についていけた部分もあるし、取り残されていたけど追いついた部分もあれば、未だにどうしていいのかわからない部分もある。ある程度予想どおりに進んだ要素の傍らで、たくさんの障害に阻まれた要素が身動きも取れずにもがいている。あきらめたことだっていくつかある。


自分のスタンスと立ち位置も少しずつだけど見えてきた。そういった類のものは全部が全部自分で選べるわけではない、ということを最近になって知った。周りの人のイメージや間柄、自分の虚栄心と現実がせめぎあって、SFに出てきても不自然じゃないような複雑なメカニズムを経て少しずつ構築されていく。僕らは基本的にはそれを見ていることしかできない、というよりもしっかりと見ていなければいけない。


一度ぼろぼろになった(比喩的にも肉体的にも)おかげで、何を得て何を捨てるべきか、おぼろげだったその正体の輪郭くらいは見えるようになった。僕らは何よりも健康に生存する必要があるし、だからといってパンを食べるために生きているわけでもない。


できればしたくなかった後悔も何度かした。(複数の集合について)僕らに残された時間は長くて短い(そもそも時間というのは本質的にそういうものなのかもしれない)。




こういう自分垂れ流し系のサービスってどう使い分ければいいのか悩む。距離感を測るためにtwitterをやめてみたりmixiをやめてみたり(不思議と意識しなくてもブログは続かない。なぜだろう?)したけど、結局のところうまくまとまらないからせめて今の気持ちを記録しておく。


twitter



  • 最近気づいたけど最初のpostまで遡れるわけじゃなさそうなので、ログとしての利用は長期的には難しい

  • エクスポートのようなことはできない(わっさーではそれができるらしい?

  • 「どこかに書きたいが長くは残ってほしくない」内容に向く

    • 歌詞の写し

    • 愚痴

    • 詩的なぼやき




mixi



  • 「顔見たことある人だけ!」とかって言える人にはmixiの存在価値は大きいと思う。僕はそこまで潔くないのでうまく住み分けできない

  • 適当なこと書いても誰もツッコまない空気がある。一長一短だけどそうされたくないような文章を書くのには向いてる

  • ただしエクスポートはできないので技術的・ノウハウ的な内容には合わないか


フロー



  1. 何か書きたいと思う

  2. それが140文字にまとまる程度ならまずtwitterへ

  3. シンタックスハイライトなどが使いたければブログへ

  4. あとはmixiへ

  5. twitter/mixiに投げたものを後で見て、誰かの何かの役に立ちそうならブログへ

2+8+4-5+1

| コメント(0) | トラックバック(0)




int strcmp(const char *s1, const char *s2)
register const unsigned char *ss1, *ss2;
for (ss1 = (const unsigned char*)s1, ss2 = (const unsigned char*)s2;
*ss1 == *ss2 && *ss1 != '\0';
ss1++, ss2++)
;
return *ss1 - *ss2;

学生A「それは何?」


学生B「ふたつの文字列の比較をする関数だな」


学生A「関数名を見ればわかるね。僕はどっぷりハマってるわけじゃないから意味まではわからないけど、授業で習った覚えはある。どういう仕組みなの?」


学生B「俺にもわからない」


学生A「そうなんだ。でも、朝から晩までそういうのやってんでしょ、それでもわからないの?」


学生B「なかなかな。そもそもこういう作品っていうのは、先人が時間をかけて試行錯誤を繰り返して作りあげてきたものなんだ。そうすぐに底が見えちゃ浮かばれないよ」


学生A「ふうん」


学生B「たとえばさ、10という数値があったとして、それが間違いなく確かな10であることは誰の目にも明らかだよな」


学生A「2に足せば12になるような紛れもない10だね」


学生B「そうだな。けれどそれがどういう10なのかはすぐにはわからない。先人たちがゼロから作りあげるとき、はじめに3を足してみて、そのあと8を足して、それから2を引いてみたりしたのかもしれないし、単純に0 + 10だったのかもしれない」


学生A「悩んだ挙句小数も使ってみたりしてね」


学生B「誤差なんか出てきてドツボにハマるんだよな」


学生A「ねえ、どうしてみんな最初に10を足さないの?それが一番スムーズじゃない」


学生B「まあ今回のことだったらそうだな。でも世の中のたいていのことって、求められているものが10なのか15.32なのか、それともπなのかさえわからないんだ。ことによっては何らかの関数かもしれない」


学生A「そっか。だからあくせく加減しては、本当にそれで納得がいくのか試しているんだね」


学生B「でも一番厄介なのはそこじゃないんだな」


学生A「そうなの?どういうことが厄介?」


学生B「俺たちが今満足している10よりもっとピッタリくるものがどこかにあるかもしれないんだ。最初に探しはじめたのが偶然10の近くだっただけで、もしかすると2,000,000とか、-4,027.5134とか、不幸なときなら虚数を含んでいるかもしれない」


学生A「せめて数直線上にはあってくれないとなかなか見つからないよね」


学生B「そうだな。だからどこを探すか、大まかなアタリをつけるためにはまず先人の見識を詰め込む必要がある。どういう場所に密集していて、ある場合にはこんなところにあって、ここには絶対にない、という知識が多ければ多いほど新しいものを見つけられる見込みは大きくなるからな」


学生A「なるほどね。そういうアタリをつけるためには何をすればいいの?」


学生B「それだってわからん。ただ"アタリをつけるために何をすればいいか"のアタリをつける方法ならひとつだけ知ってる」


学生A「ほおう」


学生B「さっきから人の課題を眺めては写してる手を止めて自分でコードを書いてみるんだよ」


参考





 しばらく前のクローズアップ現代(だったと思う)で、駐車している電気自動車を大容量バッテリーに見立てて、太陽光発電で充電し、夜間に家庭用電源として利用するという構想が語られていました。


 電気自動車が今後主流になるとして、案外アリかもと思ってしまいました。


http://slashdot.jp/hardware/comments.pl?sid=460752&cid=1613409:title

バッドノウハウとも言われうるけどこういう発想の転換、(比較的)よくあるものでカバーするというアイデアに触れるとちょっと気持ちがあたたかくなるなあ。


引用の空虚

| コメント(0) | トラックバック(0)



小説やマンガなんかを読んでいて気の利いた一節を見つけるとtwitterなんかやmixiなんかにメモしてたことがあったのだけど、それというのはなかなか空しい行為だと最近思うようになった。


ありがたく写経しても後になってまるで覚えてないんじゃなあ。


このアーカイブについて

このページには、過去に書かれたブログ記事のうち雑記カテゴリに属しているものが含まれています。

前のカテゴリは講義です。

次のカテゴリは音楽です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

ウェブページ

Powered by Movable Type 4.32-ja