 
|
はてなキーワード: 変数とは
それが困るのは、自分の味覚で味を調整しようとするからなんだぜ？
まだそんなことができる段階じゃない。
今塩を足したら味はこうなるとかシミュレーションできないうちはやめた方が良い。
レシピにもよるが、「適量」とか「お好み」とか省略して書いて無い奴をまずは作る。
それが美味いか不味いかは、レシピ書いた人の味覚と作った人の味覚の違いによるので仕方がない。
基準ができれば、次回から二人の好みに合わせて調整したレシピを作っていけばいい。
一通りのレシピが完成したら、それがお前さんたち夫婦の家庭の味になるって事だ。
コミュニティのためにレシピを公開するのも良いんじゃないかね？
方程式が線形なら、その方程式系の性質を調べる一般的な枠組みを線形代数学と言う。
線形方程式系が解を持つ条件は、変数の数と方程式の数が同じなら、その係数行列が逆行列を持つということと同値。
行列が逆行列を持たないとき、その行列の行列式が0になるので、例えば2次元かつ方程式2つなら、それらがどのくらい「平行に近いか」と「行列式がどれくらい0に近いか」が関係ある。
変数の数より方程式の数が多いときは行列が正方行列でなくなるので、逆行列は存在しない。
でもその場合でも、（ムーア・ペンローズの）一般化逆行列というものを求めることができて、これを使うと「全ての方程式を最大限満たす解」を書き下すことができる。
この「最大限満たす解」が「完全に満たす解」であれば解が存在することになる。その条件も一般化逆行列による記述を使えば調べることができるだろう。
もっと高級なこと言い出すとジョルダン標準形がどうとかいう話になるかもしれないけど…。
しかし、こういうのをネットで簡単にいろんな人に訊けるというのはほんと羨ましい。
俺の頃にもこういうのがあったら良かったのになあ…。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
//ダイアログクラスにメンバ変数を定義 std::auto_ptr<CBitmap> m_pbmp; //bitmapを設定するメンバ関数 void C*****Dlg::Set*****Bitmap() { CDC* pDC = GetDC(); CDC memdc; memdc.CreateCompatibleDC(pDC); m_pbmp.reset(new CBitmap()); CBitmap&amp; bmp = *m_pbmp; bmp.CreateCompatibleBitmap(pDC, width, height); CBitmap* old = memdc.SelectObject(&amp;bmp); memdc.FillSolidRect(0,0,width,height, color); memdc.SelectObject(old); ((CStatic*)GetDlgItem(IDC_STAIC_*********))->SetBitmap(bmp); }
スクリーンと同じデバイスコンテキストとビットマップを作成し単色で描画している。描画し終わった後のSelectObjectを忘れてはいけない。
CStatic::SetBitmapに渡した後も実際に描画されるまでCBitmapの寿命を保証しなければならない。
そのためメンバ変数にCBitmapを持たせるがCBitmapが再利用を考慮していないという驚くべき仕様なので仕方なくauto_ptrでラップしている。
いい加減MFC滅びてくれないかな。抽象度が低すぎる。こんな記事自分のブログに書きたくないよ。
さらにVisualStudio 2005のauto_ptrのバグを見つけた operator = にポインタを渡すとおかしくなる。これは本来コンパイルエラーになるべきで代わりにresetメンバ関数を使用するべきだ。
修正するには<memory>ヘッダのauto_ptr_refのコンストラクタのひとつ上の行(642行目)に private: template<class T> friend class auto_ptr; を挿入する。
第1章 プログラミング概念入門 1.1 計算器 1.2 変数 1.3 関数 1.4 リスト 1.5 リストについての関数 1.6 プログラムの正しさ 1.7 計算量 1.8 遅延計算 1.9 高階プログラミング 1.10 並列性 1.11 データフロー 1.12 明示的状態 1.13 オブジェクト 1.14 クラス 1.15 非決定性と時間 1.16 原子性 1.17 ここからどこへ行くのか？ 1.18 練習問題 第1部 一般的計算モデル 第2章 宣言的計算モデル 2.1 実用的プログラミング言語の定義 2.1.1 言語の構文 2.1.2 言語の意味 2.2 単一代入格納域 2.2.1 宣言的変数 2.2.2 値格納域 2.2.3 値生成 2.2.4 変数識別子 2.2.5 識別子を使う値生成 2.2.6 部分値 2.2.7 変数の，変数への束縛 2.2.8 データフロー変数 2.3 核言語 2.3.1 構文 2.3.2 値と型 2.3.3 基本型 2.3.4 レコードと手続き 2.3.5 基本操作 2.4 核言語の意味 2.4.1 基本概念 2.4.2 抽象マシン 2.4.3 待機不能な文 2.4.4 待機可能な文 2.4.5 基本概念再訪 2.5 メモリ管理 2.5.1 末尾呼び出し最適化 2.5.2 メモリライフサイクル 2.5.3 ガーベッジコレクション 2.5.4 ガーベッジコレクションは魔術ではない 2.5.5 Mozartのガーベッジコレクタ 2.6 核言語から実用的言語へ 2.6.1 構文上の便宜 2.6.2 関数(fun文) 2.6.3 対話的インターフェース(declare文) 2.7 例外 2.7.1 動機と基本概念 2.7.2 例外を持つ宣言的モデル 2.7.3 親言語の構文 2.7.4 システム例外 2.8 進んだ話題 2.8.1 関数型プログラミング言語 2.8.2 単一化と内含(entailment) 2.8.3 動的型付けと静的型付け 2.9 練習問題 第3章 宣言的プログラミング技法 3.1 宣言的とはどういうことか？ 3.1.1 宣言的プログラムの分類 3.1.2 仕様記述言語 3.1.3 宣言的モデルにおいてコンポーネントを実装すること 3.2 反復計算 3.2.1 一般的図式 3.2.2 数についての反復 3.2.3 局所的手続きを使うこと 3.2.4 一般的図式から制御抽象へ 3.3 再帰計算 3.3.1 スタックの大きさの増加 3.3.2 代入ベースの抽象マシン 3.3.3 再帰計算を反復計算に変換すること 3.4 再帰を用いるプログラミング 3.4.1 型の記法 3.4.2 リストについてのプログラミング 3.4.3 アキュムレータ 3.4.4 差分リスト 3.4.5 キュー 3.4.6 木 3.4.7 木を描画すること 3.4.8 構文解析 3.5 時間効率と空間効率 3.5.1 実行時間 3.5.2 メモリ使用量 3.5.3 償却的計算量 3.5.4 性能についての考察 3.6 高階プログラミング 3.6.1 基本操作 3.6.2 ループ抽象 3.6.3 ループの言語的支援 3.6.4 データ駆動技法 3.6.5 明示的遅延計算 3.6.6 カリー化 3.7 抽象データ型 3.7.1 宣言的スタック 3.7.2 宣言的辞書 3.7.3 単語出現頻度アプリケーション 3.7.4 安全な抽象データ型 3.7.5 安全な型を備えた宣言的モデル 3.7.6 安全な宣言的辞書 3.7.7 資格とセキュリティ 3.8 宣言的でない必要物 3.8.1 ファイルを伴うテキスト入出力 3.8.2 グラフィカルユーザインタフェースを伴うテキスト入出力 3.8.3 ファイルとの状態なしデータI/O 3.9 小規模プログラム設計 3.9.1 設計方法 3.9.2 プログラム設計の例 3.9.3 ソフトウェアコンポーネント 3.9.4 スタンドアロンプログラムの例 3.10 練習問題 第4章 宣言的並列性 4.1 データ駆動並列モデル 4.1.1 基本概念 4.1.2 スレッドの意味 4.1.3 実行列 4.1.4 宣言的並列性とは何か？ 4.2 スレッドプログラミングの基本的技法 4.2.1 スレッドを生成すること 4.2.2 スレッドとブラウザ 4.2.3 スレッドを使うデータフロー計算 4.2.4 スレッドのスケジューリング 4.2.5 協調的並列性と競合的並列性 4.2.6 スレッド操作 4.3 ストリーム 4.3.1 基本的生産者／消費者 4.3.2 変換器とパイプライン 4.3.3 資源を管理し，処理能力を改善すること 4.3.4 ストリームオブジェクト 4.3.5 ディジタル論理のシミュレーション 4.4 宣言的並列モデルを直接使うこと 4.4.1 順序決定並列性 4.4.2 コルーチン 4.4.3 並列的合成 4.5 遅延実行 4.5.1 要求駆動並列モデル 4.5.2 宣言的計算モデル 4.5.3 遅延ストリーム 4.5.4 有界バッファ 4.5.5 ファイルを遅延的に読み込むこと 4.5.6 ハミング問題 4.5.7 遅延リスト操作 4.5.8 永続的キューとアルゴリズム設計 4.5.9 リスト内包表記 4.6 甘いリアルタイムプログラミング 4.6.1 基本操作 4.6.2 ティッキング(ticking) 4.7 Haskell言語 4.7.1 計算モデル 4.7.2 遅延計算 4.7.3 カリー化 4.7.4 多態型 4.7.5 型クラス 4.8 宣言的プログラムの限界と拡張 4.8.1 効率性 4.8.2 モジュラ性 4.8.3 非決定性 4.8.4 現実世界 4.8.5 正しいモデルを選ぶこと 4.8.6 拡張されたモデル 4.8.7 異なるモデルを一緒に使うこと 4.9 進んだ話題 4.9.1 例外を持つ宣言的並列モデル 4.9.2 さらに遅延実行について 4.9.3 通信チャンネルとしてのデータフロー変数 4.9.4 さらに同期について 4.9.5 データフロー変数の有用性 4.10 歴史に関する注記 4.11 練習問題 第5章 メッセージ伝達並列性 5.1 メッセージ伝達並列モデル 5.1.1 ポート 5.1.2 ポートの意味 5.2 ポートオブジェクト 5.2.1 NewPortObject抽象 5.2.2 例 5.2.3 ポートオブジェクトに関する議論 5.3 簡単なメッセージプロトコル 5.3.1 RMI(遠隔メソッド起動) 5.3.2 非同期RMI 5.3.3 コールバックのあるRMI(スレッド使用) 5.3.4 コールバックのあるRMI(継続のためのレコード使用) 5.3.5 コールバックのあるRMI(継続のための手続き使用) 5.3.6 エラー報告 5.3.7 コールバックのある非同期RMI 5.3.8 二重コールバック 5.4 並列性のためのプログラム設計 5.4.1 並列コンポーネントを使うプログラミング 5.4.2 設計方法 5.4.3 並列性パターンとしての機能的構成要素 5.5 リフト制御システム 5.5.1 状態遷移図 5.5.2 実装 5.5.3 リフト制御システムの改良 5.6 メソッド伝達モデルを直接使用すること 5.6.1 1つのスレッドを共有する複数のポートオブジェクト 5.6.2 ポートを使う並列キュー 5.6.3 終点検出を行うスレッド抽象 5.6.4 直列依存関係の除去 5.7 Erlang言語 5.7.1 計算モデル 5.7.2 Erlangプログラミング入門 5.7.3 receive操作 5.8 進んだ話題 5.8.1 非決定性並列モデル 5.9 練習問題 第6章 明示的状態 6.1 状態とは何か？ 6.1.1 暗黙的(宣言的)状態 6.1.2 明示的状態 6.2 状態とシステム構築 6.2.1 システムの性質 6.2.2 コンポーネントベースプログラミング 6.2.3 オブジェクト指向プログラミング 6.3 明示的状態を持つ宣言的モデル 6.3.1 セル 6.3.2 セルの意味 6.3.3 宣言的プログラミングとの関係 6.3.4 共有と同等 6.4 データ抽象 6.4.1 データ抽象を組織する8つの方法 6.4.2 スタックの変種 6.4.3 多態性 6.4.4 引数受け渡し 6.4.5 取り消し可能資格 6.5 状態ありコレクション 6.5.1 インデックス付きコレクション 6.5.2 インデックス付きコレクションを選ぶこと 6.5.3 その他のコレクション 6.6 状態に関する推論 6.6.1 不変表明 6.6.2 例 6.6.3 表明 6.6.4 証明規則 6.6.5 正常終了 6.7 大規模プログラムの設計 6.7.1 設計方法 6.7.2 階層的システム構造 6.7.3 保守性 6.7.4 将来の発展 6.7.5 さらに深く知るために 6.8 ケーススタディ 6.8.1 遷移的閉包 6.8.2 単語出現頻度(状態あり辞書を使用する) 6.8.3 乱数を生成すること 6.8.4 口コミシミュレーション 6.9 進んだ話題 6.9.1 状態ありプログラミングの限界 6.9.2 メモリ管理と外部参照 6.10 練習問題 第7章 オブジェクト指向プログラミング 7.1 継承 7.2 完全なデータ抽象としてのクラス 7.2.1 例 7.2.2 この例の意味 7.2.3 クラスとオブジェクトを定義すること 7.2.4 クラスメンバ 7.2.5 属性を初期化すること 7.2.6 第1級メッセージ 7.2.7 第1級の属性 7.2.8 プログラミング技法 7.3 漸増的データ抽象としてのクラス 7.3.1 継承グラフ 7.3.2 メソッドアクセス制御(静的束縛と動的束縛) 7.3.3 カプセル化制御 7.3.4 転嫁と委任 7.3.5 内省 7.4 継承を使うプログラミング 7.4.1 継承の正しい使い方 7.4.2 型に従って階層を構成すること 7.4.3 汎用クラス 7.4.4 多重継承 7.4.5 多重継承に関するおおざっぱな指針 7.4.6 クラス図の目的 7.4.7 デザインパターン 7.5 他の計算モデルとの関係 7.5.1 オブジェクトベースプログラミングとコンポーネントベースプログラミング 7.5.2 高階プログラミング 7.5.3 関数分解と型分解 7.5.4 すべてをオブジェクトにすべきか？ 7.6 オブジェクトシステムを実装すること 7.6.1 抽象図 7.6.2 クラスを実装すること 7.6.3 オブジェクトの実装 7.6.4 継承の実装 7.7 Java言語(直列部分) 7.7.1 計算モデル 7.7.2 Javaプログラミング入門 7.8 能動的オブジェクト 7.8.1 例 7.8.2 NewActive抽象 7.8.3 フラウィウス・ヨセフスの問題 7.8.4 その他の能動的オブジェクト抽象 7.8.5 能動的オブジェクトを使うイベントマネージャ 7.9 練習問題 第8章 状態共有並列性 8.1 状態共有並列モデル 8.2 並列性を持つプログラミング 8.2.1 さまざまな手法の概観 8.2.2 状態共有並列モデルを直接使うこと 8.2.3 原子的アクションを使うプログラミング 8.2.4 さらに読むべき本 8.3 ロック 8.3.1 状態あり並列データ抽象を構築すること 8.3.2 タプル空間(Linda) 8.3.3 ロックを実装すること 8.4 モニタ 8.4.1 定義 8.4.2 有界バッファ 8.4.3 モニタを使うプログラミング 8.4.4 モニタを実装すること 8.4.5 モニタの別の意味 8.5 トランザクション 8.5.1 並列性制御 8.5.2 簡易トランザクションマネージャ 8.5.3 セルについてのトランザクション 8.5.4 セルについてのトランザクションを実装すること 8.5.5 トランザクションについてさらに 8.6 Java言語(並列部分) 8.6.1 ロック 8.6.2 モニタ 8.7 練習問題 第9章 関係プログラミング 9.1 関係計算モデル 9.1.1 choice文とfail文 9.1.2 探索木 9.1.3 カプセル化された 9.1.4 Solve関数 9.2 別の例 9.2.1 数値例 9.2.2 パズルとnクイーン問題 9.3 論理型プログラミングとの関係 9.3.1 論理と論理型プログラミング 9.3.2 操作的意味と論理的意味 9.3.3 非決定性論理型プログラミング 9.3.4 純粋Prologとの関係 9.3.5 他のモデルにおける論理型プログラミング 9.4 自然言語構文解析 9.4.1 簡単な文法 9.4.2 この文法に従う構文解析 9.4.3 構文木を生成すること 9.4.4 限定記号を生成すること 9.4.5 パーサを走らせること 9.4.6 パーサを「逆向きに(backward)」走らせること 9.4.7 単一化文法 9.5 文法インタプリタ 9.5.1 簡単な文法 9.5.2 文法のコード化 9.5.3 文法インタプリタを走らせること 9.5.4 文法インタプリタを実装すること 9.6 データベース 9.6.1 関係を定義すること 9.6.2 関係を使って計算すること 9.6.3 関係を実装すること 9.7 Prolog言語 9.7.1 計算モデル 9.7.2 Prologプログラミング入門 9.7.3 Prologプログラムを関係プログラムに翻訳すること 9.8 練習問題 第2部 特殊化された計算モデル 第10章 グラフィカルユーザインタフェースプログラミング 10.1 宣言的／手続き的方法 10.2 宣言的／手続き的方法を使うこと 10.2.1 基本的ユーザインタフェースの要素 10.2.2 GUIを構築すること 10.2.3 宣言的座標 10.2.4 リサイズ時の宣言的振る舞い 10.2.5 ウィジェットの動的振る舞い 10.3 対話的学習ツールPrototyper 10.4 ケーススタディ 10.4.1 簡単なプログレスモニタ 10.4.2 簡単なカレンダウィジェット 10.4.3 ユーザインタフェースの動的生成 10.4.4 状況順応時計 10.5 GUIツールを実装すること 10.6 練習問題 第11章 分散プログラミング 11.1 分散システムの分類 11.2 分散モデル 11.3 宣言的データの分散 11.3.1 オープン分散と大域的ネーミング 11.3.2 宣言的データを共有すること 11.3.3 チケット配布 11.3.4 ストリーム通信 11.4 状態の分散 11.4.1 単純状態共有 11.4.2 分散字句的スコープ 11.5 ネットワークアウェアネス 11.6 共通分散プログラミングパターン 11.6.1 静的オブジェクトとモバイルオブジェクト 11.6.2 非同期的オブジェクトとデータフロー 11.6.3 サーバ 11.6.4 クローズド分散 11.7 分散プロトコル 11.7.1 言語実体 11.7.2 モバイル状態プロトコル 11.7.3 分散束縛プロトコル 11.7.4 メモリ管理 11.8 部分的失敗 11.8.1 失敗モデル 11.8.2 失敗処理の簡単な場合 11.8.3 回復可能サーバ 11.8.4 アクティブフォールトトレランス 11.9 セキュリティ 11.10 アプリケーションを構築すること 11.10.1 まずは集中，後に分散 11.10.2 部分的失敗に対処すること 11.10.3 分散コンポーネント 11.11 練習問題 第12章 制約プログラミング 12.1 伝播・探索法 12.1.1 基本的考え方 12.1.2 部分情報を使って計算すること 12.1.3 例 12.1.4 この例を実行すること 12.1.5 まとめ 12.2 プログラミング技法 12.2.1 覆面算 12.2.2 回文積再訪 12.3 制約ベース計算モデル 12.3.1 基本的制約と伝播子 12.3.2 計算空間の探索をプログラムすること 12.4 計算空間を定義し，使うこと 12.4.1 深さ優先探索エンジン 12.4.2 検索エンジンの実行例 12.4.3 計算空間の生成 12.4.4 空間の実行 12.4.5 制約の登録 12.4.6 並列的伝播 12.4.7 分配(探索準備) 12.4.8 空間の状態 12.4.9 空間のクローン 12.4.10 選択肢を先に任せること 12.4.11 空間をマージすること 12.4.12 空間失敗 12.4.13 空間に計算を注入すること 12.5 関係計算モデルを実装すること 12.5.1 choice文 12.5.2 Solve関数 12.6 練習問題 第3部 意味 第13章 言語意味 13.1 一般的計算モデル 13.1.1 格納域 13.1.2 単一代入(制約)格納域 13.1.3 抽象構文 13.1.4 構造的規則 13.1.5 直列実行と並列実行 13.1.6 抽象マシンの意味との比較 13.1.7 変数導入 13.1.8 同等性の強制(tell) 13.1.9 条件文(ask) 13.1.10 名前 13.1.11 手続き抽象 13.1.12 明示的状態 13.1.13 by-need同期 13.1.14 読み出し専用変数 13.1.15 例外処理 13.1.16 失敗値 13.1.17 変数置き換え 13.2 宣言的並列性 13.2.1 部分停止と全体停止 13.2.2 論理的同値 13.2.3 宣言的並列性の形式的定義 13.2.4 合流性 13.3 8つの計算モデル 13.4 よくある抽象の意味 13.5 歴史に関する注記 13.6 練習問題
以前知り合った縁のある方から、出会い系攻略について聞かれたので
長くなったし、メールには残したくないし、もしかすると誰か他の人の
役に立つかもしれないと思ったので、ここに書いておきます。
【目次】
・まず決定しておくべきこと
・行動する上で心がけること
・具体的に何をすべきか
・その他配慮すべきことはあるか。
→サバ読み、一人か複数か、狙い目
【ア】まず決定しておくべきこと
1.目的
無目的で海に行っても、ぼーっと海を眺めて終わるだけ。
楽しみたいなら目的をはっきりさせる。
出会い系も同じ、目的はメル友なのかお茶友なのかセフレなのかはっきりさせる。
後述するように、目的が明確だと行動にブレがなく効率的な攻略が可能となる。
2.ターゲット
仮に目的を「釣り」として、ありきたりな竿、ありきたりな仕掛け、
ありきたりの餌で堤防から糸を垂らしても、魚が釣れるわけがない。
よしんば釣れたとして、①効率が悪い②なぜ釣れたのか分からないので
再現性が悪い、という問題がある。
なので、例えば「クロダイ」「マグロ」等、何を釣りたいのかはっきりさせる必要がある。
そうすれば、適切な竿、専用の仕掛け、最適な餌と釣り場を選択することが出来る。
出会い系も同じ。「JK」「主婦」等、誰を狙うのかをはっきりさせておく。
例）『東京２３区内もしくは神奈川東部在住の３０代後半の独身OL、親元から離れて
一人暮らしをしている。彼氏はいるが惰性でつきあっており、割と時間がある。
好奇心が強く、危ないと分かっていてもつい踏み込んでしまうことが良くある。
好きな作家は酒井順子、最近上野千鶴子も手に取ってみるようになった。』
ターゲットをこう決めたら、それ以外の女性はすべてスルーするのが鉄則。
3.自己分析
目的を「釣り」、ターゲットを「クロダイ」と決定しても必ずしも釣れるとは限らない。
なぜなら、出会い系において針に付ける餌は「自分自身」だから。
自分の強みと弱みを明確に自覚し、ターゲットのニーズを満たせるか考える。
もし、あなたの強みがグルメなら「スイーツ（）」のニーズを満たしやすい。
もし、あなたの強みが平日昼間休みなら「主婦」のニーズを満たしやすい。
※これら３つをを決定しておくメリット
・「○○だから上手くいった（いかなかった）」等、分析が出来る→次回に活かせる
・結果が平準化される→いつでもどこでも使える。ビジネスにも、リアルナンパにも。
結局のところ出会えない人というのは、この３つの事柄に対して無自覚、なのだ。
【イ】行動する上で心がけること
「クロダイを釣る」と決めたなら、心がけたいのは「良き釣り人」であること。
良い釣り人とは、魚の習性を熟知し、魚の好む竿さばきが出来る人のこと。
相手を良く知り、相手の好む行動が出来る人、ビジネスではそれを顧客志向と言う。
相手を知るつもりがなく、自分の好みを押し付ける人、それはたんなるわがまま。
例えば、読めない名前や口にしにくい名前をプロフィールに設定している人
「GSXR１０００」とか「メルルのアトリエ」とか。
第一に、ターゲットに訴えかけないよね？
第二に、会ったときになんて呼ばせるつもりなの？
2.活動期間を限定する
「良き釣り人としてクロダイを狙え」ば、かならず釣果を得ることができる。
しかし同じ場所でずっと釣りをしていると、いずれ魚はあなたに慣れ、釣果が
同様に、いずれアカウントは飽きられ、反応が悪くなる。
てっとり早いのは退会して新しいアカウントを新しく取ること。
これなら同目的、同ターゲットでも新鮮味を演出でき、釣果が戻ってくる。
では新規登録〜退会までの期間はどの程度か？経験則では３ヶ月がメドだろう。
３ヶ月経過したら、釣果を確認し、反省点を踏まえ新しいアカウントを作成する。
もちろん、素晴らしい相手を見つけたならば、退会してそれで終わりも良いだろう。
【ウ】具体的に何をすべきか
使うツールは基本３つしかない。「プロフィール」「日記（掲示板）」「メール」
見栄えが悪くなければそれで良し。名前もアバターもごく普通で構わない。
たまに派手なアバターやプロフィールを見かけるが、そんな「ドヤ顔」は必要ない。
自分のターゲットが誰なのか、自分の強みは何か、さらっと書いておくと良いだろう。
仕事がら全国いろいろなところへ行きますが、そういったところで
出会う美味しいもの美しい風景を日記に書いていこうと思ってます。
一人暮らしをしているので、同じように一人暮らししてる方と仲良くなりたいです^^』
最も難しく、コアな部分と言えるだろう。ターゲットの心に響かなくてはならない。
何を書くかよりも、書く内容をブラッシュアップさせる方法を見つける必要がある。
指針とすべきは「閲覧数」と「閲覧数に占めるコメントの率」。
過去の日記の数値を確認し、良かった日の日記のどこが良かったのか
なお、ハッピーメールではコメント率１０％、ASOBOならコメント率４％が目安。
相手と仲良くなることは意識しない。自分の望む条件かどうか、相手が
仲良くなることを意識するのは、「直メ」「電話」フェーズである。
サイト内でのメールは、１回の量にもよるが、１０回前後だろう。
直メへ移行すれば、会う確率はかなり高まる。
【エ】その他配慮すべきことはあるか。
1.サバを読むべきか
サイトでは、年齢をサバ読む人が非常に多い。男女問わず若い子が好まれるためだ。
半数程度の人間が、自分のプロフィールをサバ読みしていると考えて差し支えない。
自分がやるかは目的による。継続的な関係を望むならやるべきではない。
2.一人に絞るか複数を狙うか
これは複数が良い。一人だとつい入れこんでしまうし、リスクヘッジになる。
お手玉やジャグリングのように、リズム良く進めると良いだろう。
3.どんな人が釣れやすいか
はじめたばかりの人がもっとも狙い目。観察していると「初日記」「初書き込み」
は非常に人気が集まっている。前述したように、自分のアカウントは常に始めて
３ヶ月以内なのだから、「私もはじめたばっかりなんですよ^^」と、
相手との共通項を作れるメリットもある。
以上、私なりの攻略法でした。
何が難しいって設定やら用語やらだよ。
PC自体そこまでわからない自分からしたらフォルダの探し方からわかんない。
設定の仕方とかも全然わかんない。
それに用語がわかんない。
初心者向けの本を読んでても用語すらわかんないよ。
「この言語はこういうものでこういう理由で優れている」という説明がまずわからない。
これってみんな最初どうしたんだ？
正直言うといまいちPCについてわかってない。関係無い話だけどさ。
ほんと技術者には頭が下がるよ。
技術者が周りに多いんだけど、みんなで話してると大概技術の話になって自分が全く話しについていけなくなる。
ほんと異星人のように思えるわ。
彼らも自分と同じような頃があったのだろうか。いやあったんだろう。
自分は技術で食ってくつもりはないけど彼らの言ってる事が理解できるようになりたいし追いつきたい。
でも追いつけんのかなぁ・・スタートも遅いし。
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
第1章 有限オートマトン D.Perrin：橋口攻三郎 1. 序論 2. 有限オートマトンと認識可能集合 3. 有理表現 4. Kleeneの定理 5. 星の高さ 6. 星自由集合 7. 特殊なオートマトン 8. 数の認識可能集合 第2章 文脈自由言語 J.Berstel and L.Boasson：富田 悦次 1. 序論 2. 言語 2.1 記法と例 2.2 Hotz 群 2.3 曖昧性と超越性 3. 反復 3.1 反復補題 3.2 交換補題 3.3 退化 4. 非生成元の探求 4.1 準備 4.2 生成元 4.3 非生成元と代入 4.4 非生成元と決定性 4.5 主錐の共通部分 5. 文脈自由群 5.1 文脈自由群 5.2 Cayleyグラフ 5.3 終端 第3章 形式言語とべき級数 A.Salomaa：河原 康雄 1. 序論 2. 準備 3. 書換え系と文法 4. Post正準系 5. Markov系 6. 並列書換え系 7. 射と言語 8. 有理べき級数 9. 代数的べき級数 10. べき級数の応用 第4章 無限の対象上のオートマトン W.Thomas：山崎 秀記 序論 Ⅰ部 無限語上のオートマトン 記法 1. Buchiオートマトン 2. 合同関係と補集合演算 3. 列計算 4. 決定性とMcNaughtonの定理 5. 受理条件とBorelクラス 6. スター自由ω言語と時制論理 7. 文脈自由ω言語 Ⅱ部 無限木上のオートマトン 記法 8. 木オートマトン 9. 空問題と正則木 10. 補集合演算とゲームの決定性 11. 木の単項理論と決定問題 12. Rabin認識可能な集合の分類 12.1 制限された単項2階論理 12.2 Rabin木オートマトンにおける制限 12.3 不動点計算 第5章 グラフ書換え：代数的・論理的アプローチ B.Courcelle：會澤 邦夫 1. 序論 2. 論理言語とグラフの性質 2.1 単純有向グラフの類S 2.2 グラフの類D(A) 2.3 グラフの性質 2.4 1階のグラフの性質 2.5 単項2階のグラフの性質 2.6 2階のグラフの性質 2.7 定理 3. グラフ演算とグラフの表現 3.1 源点付きグラフ 3.2 源点付き超グラフ 3.3 超グラフ上の演算 3.4 超グラフの幅 3.5 導来演算 3.6 超辺置換 3.7 圏における書換え規則 3.8 超グラフ書換え規則 4. 超グラフの文脈自由集合 4.1 超辺置換文法 4.2 HR文法に伴う正規木文法 4.3 超グラフの等式集合 4.4 超グラフの文脈自由集合の性質 5. 超グラフの文脈自由集合の論理的性質 5.1 述語の帰納的集合 5.2 論理構造としての超グラフ 5.3 有限超グラフの可認識集合 6. 禁止小グラフで定義される有限グラフの集合 6.1 小グラフ包含 6.2 木幅と木分解 6.3 比較図 7. 計算量の問題 8. 無限超グラフ 8.1 無限超グラフ表現 8.2 無限超グラフの単項性質 8.3 超グラフにおける等式系 8.4 関手の初期不動点 8.5 超グラフにおける等式系の初期解 8.6 等式的超グラフの単項性質 第6章 書換え系 N.Dershowitz and J.-P.Jouannaud：稲垣 康善，直井 徹 1. 序論 2. 構文論 2.1 項 2.2 等式 2.3 書換え規則 2.4 決定手続き 2.5 書換え系の拡張 3. 意味論 3.1 代数 3.2 始代数 3.3 計算可能代数 4. Church-Rosser性 4.1 合流性 4.2 調和性 5. 停止性 5.1 簡約順序 5.2 単純化順序 5.3 経路順序 5.4 書換え系の組合せ 6. 充足可能性 6.1 構文論的単一化 6.2 意味論的単一化 6.3 ナローイング 7. 危険対 7.1 項書換え 7.2 直交書換え系 7.3 類書換え 7.4 順序付き書換え 7.5 既約な書換え系 8. 完備化 8.1 抽象完備化 8.2 公平性 8.3 完備化の拡張 8.4 順序付き書換え 8.5 機能的定理証明 8.6 1階述語論理の定理証明 9. 書換え概念の拡張 9.1 順序ソート書換え 9.2 条件付き書換え 9.3 優先度付き書換え 9.4 グラフ書換え 第7章 関数型プログラミングとラムダ計算 H.P.Barendregt：横内 寛文 1. 関数型計算モデル 2. ラムダ計算 2.1 変換 2.2 計算可能関数の表現 3. 意味論 3.1 操作的意味論：簡約と戦略 3.2 表示的意味論：ラムダモデル 4. 言語の拡張 4.1 デルタ規則 4.2 型 5. 組合せ子論理と実装手法 5.1 組合せ子論理 5.2 実装の問題 第8章 プログラミング言語における型理論 J.C.Mitchell：林 晋 1. 序論 1.1 概論 1.2 純粋および応用ラムダ計算 2. 関数の型をもつ型付きラムダ計算 2.1 型 2.2 項 2.3 証明系 2.4 意味論と健全性 2.5 再帰的関数論的モデル 2.6 領域理論的モデル 2.7 カルテシアン閉圏 2.8 Kripkeラムダモデル 3. 論理的関係 3.1 はじめに 3.2 作用的構造上の論理的関係 3.3 論理的部分関数と論理的同値関係 3.4 証明論的応用 3.5 表現独立性 3.6 論理的関係の変種 4. 多相型入門 4.1 引数としての型 4.2 可述的な多相的計算系 4.3 非可述的な多相型 4.4 データ抽象と存在型 4.5 型推論入門 4.6 型変数をもつλ→の型推論 4.7 多相的宣言の型推論 4.8 他の型概念 第9章 帰納的な関数型プログラム図式 B.Courcelle：深澤 良彰 1. 序論 2. 準備としての例 3. 基本的な定義 3.1 多ソート代数 3.2 帰納的な関数型プログラム図式 3.3 同値な図式 4. 離散的解釈における操作的意味論 4.1 部分関数と平板な半順序 4.2 離散的解釈 4.3 書換えによる評価 4.4 意味写像 4.5 計算規則 5. 連続的解釈における操作的意味論 5.1 連続代数としての解釈 5.2 有限の極大要素と停止した計算 6. 解釈のクラス 6.1 汎用の解釈 6.2 代表解釈 6.3 解釈の方程式的クラス 6.4 解釈の代数的クラス 7. 最小不動点意味論 7.1 最小で唯一の解を得る不動点理論 7.2 Scottの帰納原理 7.3 Kleeneの列と打切り帰納法 8. プログラム図式の変換 8.1 プログラム図式における同値性の推論 8.2 畳込み，展開，書換え 8.3 制限された畳込み展開 9. 研究の歴史，他の形式のプログラム図式，文献ガイド 9.1 流れ図 9.2 固定された条件をもつ一様な帰納的関数型プログラム図式 9.3 多様な帰納的関数型プログラム図式 9.4 代数的理論 9.5 プログラムの生成と検証に対する応用 第10章 論理プログラミング K.R.Apt：筧 捷彦 1. 序論 1.1 背景 1.2 論文の構成 2. 構文と証明論 2.1 1階言語 2.2 論理プログラム 2.3 代入 2.4 単一化子 2.5 計算過程―SLD溶融 2.6 例 2.7 SLD導出の特性 2.8 反駁手続き―SLD木 3. 意味論 3.1 1階論理の意味論 3.2 SLD溶融の安全性 3.3 Herbrand模型 3.4 直接帰結演算子 3.5 演算子とその不動点 3.6 最小Herbrand模型 3.7 SLD溶融の完全性 3.8 正解代入 3.9 SLD溶融の強安全性 3.10 手続き的解釈と宣言的解釈 4. 計算力 4.1 計算力と定義力 4.2 ULの枚挙可能性 4.3 帰納的関数 4.4 帰納的関数の計算力 4.5 TFの閉包順序数 5. 否定情報 5.1 非単調推論 5.2 閉世界仮説 5.3 失敗即否定規則 5.4 有限的失敗の特徴付け 5.5 プログラムの完備化 5.6 完備化の模型 5.7 失敗即否定規則の安全性 5.8 失敗即否定規則の完全性 5.9 等号公理と恒等 5.10 まとめ 6. 一般目標 6.1 SLDNF-溶融 6.2 SLDNF-導出の安全性 6.3 はまり 6.4 SLDNF-溶融の限定的な完全性 6.5 許容性 7. 層状プログラム 7.1 準備 7.2 層別 7.3 非単調演算子とその不動点 7.4 層状プログラムの意味論 7.5 完全模型意味論 8. 関連事項 8.1 一般プログラム 8.2 他の方法 8.3 演繹的データベース 8.4 PROLOG 8.5 論理プログラミングと関数プログラミングの統合 8.6 人工知能への応用 第11章 表示的意味論 P.D.Mosses：山田 眞市 1. 序論 2. 構文論 2.1 具象構文論 2.2 抽象構文 2.3 文脈依存構文 3. 意味論 3.1 表示的意味論 3.2 意味関数 3.3 記法の慣例 4. 領域 4.1 領域の構造 4.2 領域の記法 4.3 記法上の約束事 5. 意味の記述法 5.1 リテラル 5.2 式 5.3 定数宣言 5.4 関数の抽象 5.5 変数宣言 5.6 文 5.7 手続き抽象 5.8 プログラム 5.9 非決定性 5.10 並行性 6. 文献ノート 6.1 発展 6.2 解説 6.3 変形 第12章 意味領域 C.A.Gunter and D.S.Scott：山田 眞市 1. 序論 2. 関数の帰納的定義 2.1 cpoと不動点定理 2.2 不動点定理の応用 2.3 一様性 3. エフェクティブに表現した領域 3.1 正規部分posetと射影 3.2 エフェクティブに表現した領域 4. 作用素と関数 4.1 積 4.2 Churchのラムダ記法 4.3 破砕積 4.4 和と引上げ 4.5 同形と閉包性 5. べき領域 5.1 直観的説明 5.2 形式的定義 5.3 普遍性と閉包性 6. 双有限領域 6.1 Poltkin順序 6.2 閉包性 7. 領域の帰納的定義 7.1 閉包を使う領域方程式の解法 7.2 無型ラムダ記法のモデル 7.3 射影を使う領域方程式の解法 7.4 双有限領域上の作用素の表現 第13章 代数的仕様 M.Wirsing：稲垣 康善，坂部 俊樹 1. 序論 2. 抽象データ型 2.1 シグニチャと項 2.2 代数と計算構造 2.3 抽象データ型 2.4 抽象データ型の計算可能性 3. 代数的仕様 3.1 論理式と理論 3.2 代数的仕様とその意味論 3.3 他の意味論的理解 4. 単純仕様 4.1 束と存在定理 4.2 単純仕様の表現能力 5. 隠蔽関数と構成子をもつ仕様 5.1 構文と意味論 5.2 束と存在定理 5.3 隠蔽記号と構成子をもつ仕様の表現能力 5.4 階層的仕様 6. 構造化仕様 6.1 構造化仕様の意味論 6.2 隠蔽関数のない構造化仕様 6.3 構成演算 6.4 拡張 6.5 観測的抽象化 6.6 構造化仕様の代数 7. パラメータ化仕様 7.1 型付きラムダ計算によるアプローチ 7.2 プッシュアウトアプローチ 8. 実現 8.1 詳細化による実現 8.2 他の実現概念 8.3 パラメータ化された構成子実現と抽象化子実現 8.4 実行可能仕様 9. 仕様記述言語 9.1 CLEAR 9.2 OBJ2 9.3 ASL 9.4 Larch 9.5 その他の仕様記述言語 第14章 プログラムの論理 D.Kozen and J.Tiuryn：西村 泰一，近藤 通朗 1. 序論 1.1 状態，入出力関係，軌跡 1.2 外的論理，内的論理 1.3 歴史ノート 2. 命題動的論理 2.1 基本的定義 2.2 PDLに対する演繹体系 2.3 基本的性質 2.4 有限モデル特性 2.5 演繹的完全性 2.6 PDLの充足可能性問題の計算量 2.7 PDLの変形種 3. 1階の動的論理 3.1 構文論 3.2 意味論 3.3 計算量 3.4 演繹体系 3.5 表現力 3.6 操作的vs.公理的意味論 3.7 他のプログラミング言語 4. 他のアプローチ 4.1 超準動的論理 4.2 アルゴリズム的論理 4.3 有効的定義の論理 4.4 時制論理 第15章 プログラム証明のための手法と論理 P.Cousot：細野 千春，富田 康治 1. 序論 1.1 Hoareの萌芽的な論文の解説 1.2 C.A.R.HoareによるHoare論理のその後の研究 1.3 プログラムに関する推論を行うための手法に関するC.A.R.Hoareによるその後の研究 1.4 Hoare論理の概観 1.5 要約 1.6 この概観を読むためのヒント 2. 論理的，集合論的，順序論的記法 3. プログラミング言語の構文論と意味論 3.1 構文論 3.2 操作的意味論 3.3 関係的意味論 4. 命令の部分正当性 5. Floyd-Naurの部分正当性証明手法とその同値な変形 5.1 Floyd-Naurの手法による部分正当性の証明の例 5.2 段階的なFloyd-Naurの部分正当性証明手法 5.3 合成的なFloyd-Naurの部分正当性証明手法 5.4 Floyd-Naurの部分正当性の段階的な証明と合成的な証明の同値性 5.5 Floyd-Naurの部分正当性証明手法の変形 6. ライブネスの証明手法 6.1 実行トレース 6.2 全正当性 6.3 整礎関係，整列集合，順序数 6.4 Floydの整礎集合法による停止性の証明 6.5 ライブネス 6.6 Floydの全正当性の証明手法からライブネスへの一般化 6.7 Burstallの全正当性証明手法とその一般化 7. Hoare論理 7.1 意味論的な観点から見たHoare論理 7.2 構文論的な観点から見たHoare論理 7.3 Hoare論理の意味論 7.4 構文論と意味論の間の関係：Hoare論理の健全性と完全性の問題 8. Hoare論理の補足 8.1 データ構造 8.2 手続き 8.3 未定義 8.4 別名と副作用 8.5 ブロック構造の局所変数 8.6 goto文 8.7 （副作用のある）関数と式 8.8 コルーチン 8.9 並行プログラム 8.10 全正当性 8.11 プログラム検証の例 8.12 プログラムに対して1階論理を拡張した他の論理 第16章 様相論理と時間論理 E.A.Emerson：志村 立矢 1. 序論 2. 時間論理の分類 2.1 命題論理 対 1階述語論理 2.2 大域的と合成的 2.3 分岐的 対 線形 2.4 時点と時区間 2.5 離散 対 連続 2.6 過去時制 対 未来時制 3. 線形時間論理の技術的基礎 3.1 タイムライン 3.2 命題線形時間論理 3.3 1階の線形時間論理 4. 分岐的時間論理の技術的基礎 4.1 樹状構造 4.2 命題分岐的時間論理 4.3 1階の分岐的時間論理 5. 並行計算：その基礎 5.1 非決定性と公平性による並列性のモデル化 5.2 並列計算の抽象モデル 5.3 並列計算の具体的なモデル 5.4 並列計算の枠組みと時間論理の結び付き 6. 理論的見地からの時間論理 6.1 表現可能性 6.2 命題時間論理の決定手続き 6.3 演繹体系 6.4 モデル性の判定 6.5 無限の対象の上のオートマトン 7. 時間論理のプログラムの検証への応用 7.1 並行プログラムの正当性に関する性質 7.2 並行プログラムの検証：証明論的方法 7.3 時間論理による仕様からの並行プログラムの機械合成 7.4 有限状態並行システムの自動検証 8. 計算機科学における他の様相論理と時間論理 8.1 古典様相論理 8.2 命題動的論理 8.3 確率論理 8.4 不動点論理 8.5 知識 第17章 関係データベース理論の構成要素 P.C.Kanellakis：鈴木 晋 1. 序論 1.1 動機と歴史 1.2 内容についての案内 2. 関係データモデル 2.1 関係代数と関係従属性 2.2 なぜ関係代数か 2.3 なぜ関係従属性か 2.4 超グラフとデータベーススキーマの構文について 2.5 論理とデータベースの意味について 3. 従属性とデータベーススキーマ設計 3.1 従属性の分類 3.2 データベーススキーマ設計 4. 問合わせデータベース論理プログラム 4.1 問合わせの分類 4.2 データベース論理プログラム 4.3 問合わせ言語と複合オブジェクトデータモデル 5. 議論：関係データベース理論のその他の話題 5.1 不完全情報の問題 5.2 データベース更新の問題 6. 結論 第18章 分散計算：モデルと手法 L.Lamport and N.Lynch：山下 雅史 1. 分散計算とは何か 2. 分散システムのモデル 2.1 メッセージ伝達モデル 2.2 それ以外のモデル 2.3 基礎的概念 3. 分散アルゴリズムの理解 3.1 挙動の集合としてのシステム 3.2 安全性と活性 3.3 システムの記述 3.4 主張に基づく理解 3.5 アルゴリズムの導出 3.6 仕様記述 4. 典型的な分散アルゴリズム 4.1 共有変数アルゴリズム 4.2 分散合意 4.3 ネットワークアルゴリズム 4.4 データベースにおける並行性制御 第19章 並行プロセスの操作的および代数的意味論 R.Milner：稲垣 康善，結縁 祥治 1. 序論 2. 基本言語 2.1 構文および記法 2.2 操作的意味論 2.3 導出木と遷移グラフ 2.4 ソート 2.5 フローグラフ 2.6 拡張言語 2.7 その他の動作式の構成 3. プロセスの強合同関係 3.1 議論 3.2 強双模倣関係 3.3 等式による強合同関係の性質 3.4 強合同関係における置換え可能性 3.5 強等価関係上での不動点の唯一性 4. プロセスの観測合同関係 4.1 観測等価性 4.2 双模倣関係 4.3 観測合同関係 4.4 プロセス等価性上での不動点の唯一性 4.5 等式規則の完全性 4.6 プロセスの等価性に対するその他の概念 5. 双模倣等価関係の解析 5.1 等価性の階層構造 5.2 階層構造の論理的特性化 6. 合流性をもつプロセス 6.1 決定性 6.2 合流性 6.3 合流性を保存する構成子 7. 関連する重要な文献
http://d.hatena.ne.jp/yuhka-uno/20110901/1314876472
この記事に関する違和感をようやく理解。
この人と私では同じ現象を見ても、根本的にみる軸も方向性も違うのだ。
「自己嫌悪につぶされるくらいなら自分に優しく」というだけのことを言うために
こんだけ人をボコスカに貶めなければいけない人というのは、戦国時代ならともかく現代では生きづらそうで気の毒だ。
気の毒なだけならともかく、そのボコスカ部分をを敷衍しようとかしてるなら母親以上に有害な存在になりかねない
（文章中から判断するに今のところそこまでは考えてないっぽいが、今後も周囲から理解されてないと感じ続けたなら原理主義者に化ける素質は十分ある）
いわゆるこの手のタイプ ＞ http://homepage1.nifty.com/eggs/iryou/gihou/projectiv_id.html
私は彼女が上げている事例を見て、
「自分が嫌われないために気を使う人」なんてどこにいるんだ？と思った。
彼女が敵意を持って恣意的に解釈しているだけで、彼女の母親の行為は彼女の解釈では説明できないと思った。
なぜなら、「自分が嫌われないために気を使う」ことと「身内をぞんざいに扱うこと」はイコールではないからだ。
前者にエネルギーを使いすぎて後者は手抜きしてしまうってもっともらしい説明が書かれていたが、説明として不十分。
さて、この「なぜ？」という問は、どういう目的で問いかけるかによって全く効果が違う。
解決不可能な「性格」を持って結論とする上の記事は、相手を絶対悪に貶めるという意味で非常に気分の良いものでしょう。
そして、その影響により自分の性格も歪んでしまったので、もうそのまま生きて行くしかないという開き直りも自分にだけは心地良いものでしょう。
そういう目的でなされた「なぜ？」は非常にキレイな答えを出してくれます。なんせ変数が相手だけだからね。
でも、その「なぜ？」は常に後ろ向きなアイデアを生み出します。そしてクソの役にもタチません。ただの精神的麻薬にしかならない。
あとこの記事に幾重にも塗りこめられた無自覚な悪意が、ゲロ吐きそうなくらい気持ち悪い。
その後徐々にポロポロと自覚的に悪意を顕にしていってるけど、最初の文章だけでこの人の「普通の人」に対する悪意は駄々漏れ。
どうせ母親が悪い→母親をこんなにした世の中が悪い（そしてその中に自分は含まれてない。私はただの被害者）的な妄想があるんだろう。
基本的に「暗い人間」の書く文章は、よほど洗練されない限り表に出すもんじゃねーな、と。嵐が丘を読み直したくなったわ。
http://d.hatena.ne.jp/tyokorata/20110906/1315341364
「教えてもらってない」人が人材を教育した場合、教えてもらってない人に怒られた人が受け取ることは「自己嫌悪」と「萎縮」です。
そして、そうしたことを学んだ人がそうした萎縮や自己嫌悪から来る態度を自然に外に出した時、また人材教育者が怒るという悪循環を繰り返します。
その結果、そうした教えを受けた、本来真っ白であった人はドス黒い魂を受け継いで同じことを他の誰かに受け継がせるのです。
（中略）
それは「気付き」と「考える」ことの不在から来る連鎖でもあったわけです。そうした水を飲ませない体育の授業の構図は今も続いています。
ぶっちゃけ上の記事を読んだ時に「どこの彼氏彼女の事情」だよと思ったし、その他１０くらいのマンガやラノベがすぐに頭に浮かびました。
いっちゃなんだが、どこにでもある話である。
もちろん当事者にとってはありきたりのパターンでも大変なことだったことは理解できるが、
そのくせ、これみよがしになされた分析においては、自分の当事者性が欠片も考慮されていない。
母親と自分の関係として捉えるのではなく、母親の異常性だけにクローズアップする少女漫画的な安易な発想。
一見前向きだけれど、レミングスの行進を促しているようにしか見えない記事の結論。
（「私は私のままでいいんだ」ってのは一見救いのヒントのようだけど、そういう考えをこそ母親は心配してたんじゃないの？
それが許されるのは天才だけで、凡才がその道を進むには一度諦観を乗り越えて、報われぬ人生を覚悟の上で選びとる必要があるってわかってんのだろうか
普通の自分に誇りを持って生きるって、そう並大抵のコトじゃないぞ？ だから私は「普通」の父親母親を尊敬するが、あなたのことはガキだと思う。）
ガキくさい上に、これが結論と言わんばかりのがんこぶり。
いろんな意味で「若さ」がダメな方向に結晶した記事だと思った。
最後に。
何でも暴力あつかい、何でもハラスメント扱い、何でも差別扱いと、自分と違うものを悪として自分から切り離すと、生きて行けないよ。
この人の文章にはとにかく「自分」が存在しない。「私は私のままでいいんだ」はどこいった
高校卒業前に、こういう「キレイなままでいたい症候群」にかかって自殺まで発展する奴いるけど、さすがに社会人になってこの幼さはちょっと痛々しい。
この記事を読んでもやもやを晴らしておきたかったので書いただけで、もっとも、ただの好き嫌いの問題かつ、年齢の違いに拠るものだと思う。
「私はこの記事が嫌いだ。私は後者の記事を支持する」は、「この記事が絶対的に間違っている」というものではない。
私がこの記事をキライで、著者を軽蔑しているからと言って、他の人にとってこの記事の存在価値がないとは思わないし、著者の人生が間違っていることにはなるまい。
最後に、宇野は「〈いま・ここ〉だけが無限に広がるこのリトル・ピープルの時代の新しい世界においては、私たちは〈いま・ここ〉に「潜る」こと、徹底して内在的であることが逆説的に超越に接近してしまう」と語るけど、このレトリックって、大澤真幸が麻原彰晃に対して指摘した、
徹底した俗物性、過剰なまでの〈内在性〉が、逆に、麻原の〈超越性〉の根拠になっているのではないか。（大澤真幸『虚構時代の果て』）
とまったく同じなのだけど、これは本人的には大丈夫なのかしら。
ttp://blog.livedoor.jp/toshihirock_n_roll/archives/51653048.html
たとえば『完全自殺マニュアル』の鶴見済氏やオウム真理教の麻原彰晃は、「革命」を失った今、世界を変えるのではなく自分を変えようとしたわけですよね。ドラッグや「修行」によって。麻原は鶴見さんほど徹底できなかったヘタレだから革命のでき損ないに走っちゃったわけです。しかし、彼らのやったことはまさに「内在」的なアプローチだったと思う。だって、世界変革を「諦めて」自分をチューニングするんだから。
でも、ぼくがこの本で書いた「拡張現実の時代」においては、先ほどのゲームの例が代表するようにネットワーク的なものに支援されて超越―内在といった図式自体が崩壊していて、徹底的に内在することが超越に近づくというモチーフが頻出する。「ここではない、どこか」ではなく「いま、ここ」に留まったままゲームのルールを書き換えるための想像力の行使に焦点を合わせているわけ。それはそのまま「虚構の時代」（鶴見・麻原）と「拡張現実の時代」の違いでもある。ここもポイントで、「外部」を断念するというとすぐに鶴見・麻原的なものを年長世代自体は想像しちゃうけれど、それは90年代で時間が止まっている思考ですね。21世紀的な現実は「徹底して内在することによる超越」が、自意識のチューニングではなく現実のコミュニケーションとして創作物の生成や社会変革の可能性の方向に向かっている。これがまさに「仮想現実から拡張現実へ」ということ。
いやいやいや。。。ちょっとウノさん、何言ってるんですか・・・・。「内在」っていうこれまで批評用語としては、「超越-内在」っていう二項対立の一項として使われてきた用語を、かなり強引に自分タームの「内在」（これってむしろ「組織のインサイダー＝内在者」っていう意味に近いと思うんだけど）に引きつけて使ってて、不要に名前空間のコンフリクトを起こしてる気がする。まさに、
人文系の評論はすぐに一般名詞を専門用語化する傾向がある。しかも、その本だけでしか通用しない専門用語をすぐにつくっちゃうのだ。”壁_temp”とか、”想像力_temp”とかいう名前にしてくれればわかりやすいのだが、我慢して慣れてみよう。
っていう奴。今まで現代思想界にはCritique.naizaiっていう広く使われてる変数なり関数なりがあったのに、そこにまた紛らわしいUno.naizaiっていう変数なり関数なりを持ってきてて、そこでCritique.naizaiをUno.naizaiと間違えてコンパイルした人に、「お前はUnoパッケージをインポートしてないから俺の本が読めてない」って文句言うのはちょっと無理筋過ぎないか。
まあ、用語の問題を脇に置けば宇野常寛の言いたいことも分からなくはない。現代思想や社会理論がこれまで、超越（トップダウンの理想主義的な社会モデル）か、内在（個々人の内面＝インナースペースからの改革）か、という二項対立に拘泥したきたのに対して、組織の内在者＝インサイダーが、組織へのハッキング的なコミュニケーションによるアプローチをかけることによって、ゆるやかに社会を変えていきましょう、ってのが彼の言いたいことなんだろうなあ、と思う。だけどそこで、現代思想のこれまで数十年の歴史のある用語体系に土足で踏み込んで、「内在」なんていう一般名詞を無理やり自分タームで使うのは無理筋だし、これまでその用語体系を使ってきた人の名前空間を不必要に混乱させる振る舞いだと思う。せめて「内在者（インサイダー）的アプローチ」くらいの用語にしておいてくれれば分かりやすいのにねえ・・・
「場」に参加する人間が買い手となり、売り手となる瞬間は間違い無く存在する。
しかし、それは複層的なもので、「買い手であり、売り手である」状態が継続しているといえよう。
ネット社会が発達するに連れ、「お客様」を諌める流れがより可視化されるようになった。
時に作り手、時に買い手となるマーケットにおいて、よく言われてきたことだ。
あるいは、まずコミケがあり、ネット文化が発達するに従い、オタクという媒介変数を通して文化文脈の共有が生まれた、ということもあるのかもしれない。
いずれにせよ、今は「場」において「お客様」と居直る人は、いわゆる日系企業的ビジネスシーンほどには構ってもらえない、というわけだ。
少し、話を飛躍、発展させる。
誰もが作り手になれ、誰もが買い手になれる流動性の高いマーケットにおいて先述した「お客様害悪論」は有効に機能するとは思う。
しかし、相互の分断が技術的、特権的な参入障壁の高さによってかなり決定的であった場合、果たしてこれは有効に機能するだろうか？
私は、そうは思えない。
たとえば、コンビニのバイトにいちゃもんをつける客がいたとしよう。
このとき、コンビニのバイト経験がある人からすれば、同情、あるいは不当ないちゃもんであると喝破できるようなケースもあるだろう。
しかし、コンビニのバイト経験に限らず、日本人はあまり多種多様な職業に携わり難い環境にあると言える。公務員ならまだしも、一般企業社員さえ副業をしている余裕はない。つまり、流動性ある複層関係が、固定化される単層関係に置き換わるわけだ。
こういう場合、互いが互いのバックボーンを知りえない事が多く、自分の立場を正当せしめようとする動きが心中に生まれる。このパワーバランスのせめぎあいの結果、これまでの日本ではお客様至上主義に傾き、固定化された、という見地に私は至った。
流動性を「場」が維持するには、膨大なエナジーを「場」が御しきり、かつ「場」に参与する複数の個人が自律した行動を取ることが求められる。ゆえに、そこにあるのは非常に強力なメンタルを持った個々人の集合体であり、統一された目標に向けて、エナジーを爆散させる。かくて活況となる「場」は時に外部にまで波及するほどのバイタリティを持つのである。
しかしながら、先に書いたとおり、これはかなりレベルの高い要求である。個々人のメンタリティ、バイタリティは様々であり、自律の程度においてもまた同様である。
また、人の省力的行動は、流動性を失わせる方へ作用させ、自律作用を失わせることも事実である。一度お客様の旨みを味わったものがなかなかに脱し切れないのは、ここが理由である。
さらに話を飛躍させれば、今の国政において我々国民の殆どはお客様同然である。我々も国政に積極的に参与できるのであるが、それに参与するためだけでもより高い体力が必要だろう。投票システムはこの分断を決定的にする。投票するだけで国政に参加できるなどと吹聴させられれば、より省力的手段としてそちらになびくのは仕方ないだろう。
http://anond.hatelabo.jp/20110811033545
自分ではそう思ってないけど、人から見ると負け犬の遠吠えに見えるから、
冷めた目で見てもらってかまわないです。
俺はいわゆる今まででプログラムできたことない（年齢＝プログラム作れない暦）。
小中高とパソコンなかったから大学ではがんばってプログラム作ろうと思ってた
んだけど、文系の大学でハッカー全然いないから、友達に結構紹介してもらった。
まず、なんで俺がプログラムを作りたかったかというと。世間体を気にしていて、
早く口だけハッカーというレッテルをとりたかったから作りたかった。
まあそんな男が持てる分けないんだけど。
友達にも口だけ口だけってネタにされて（まあ冗談ってわかってるけど）、
まあ察してると思うけど、プログラムはできなかった・・・一応コンパイルまでこぎ着けて
全部 fatal error でさようならが８本（８連敗）、全く後に続かなかった。
１本目は、うまれて初めてパソコンの前でまともなコーディングをしたから完全に舞い上がって
ものすごい労力をつぎ込んだ。ハウツー本でエクセルマクロと同じ感覚でコーディングすると良い
と書いてあったから、俺が打った五行がコンパイルエラーしたら五行を書き直したり、
１０行がコンパイルエラーしたら１０行を直したり、１５g(ry というやり取りをしていた。
（まあ内容は置いといて・・・）
OSの反応が途絶えてからパソコンの前で待ってて来るかな来るかな、って３時間くらい
待ってたこともあった。そして、無限ループで変数を増やしまくってたらしく
「このプログラムは不正な処理を行ったので強制終了されます。[詳細] をクリックすると、次のエラー メッセージが表示されます。」
っていわれて１本目撃沈。
それから友達から指摘を受けて、言語の扱い方を学んで次のコード次のコードへ
どんどんアプローチをかけていった。
２～６本目位までは１本目と同じくらいか、少し少ない熱意を持って
やったがそれも全て撃沈。
７～８本目位になったあたりで精神が病んできちゃって、８本目が撃沈した
次の日位から、食事が喉を通らなくなった。食べてもほぼ１００％吐いてた。
なんで自分は書けないのか？書けなさすぎて劣悪な遺伝子だな、頭も悪いし
こんな遺伝子残さない方がいいんじゃないか、という劣等感を感じるようになった。
大学はそのときまで全然さぼらなかったんだけど、あまりのだるさに１日さぼって、
次の日は学校行っただけでダウン、ついた瞬間保健室へ駆け込み、休憩して授業を
受けずにそのまま帰宅。一週間で飯は食えるようになったけどそれでも前に比べる
とかなり小食になった。
そして、自分の気持ちの中でいくつかの結論が出た。
自分は本当に書けない、やればやるほど空回りする。そして、無理すればするほど
ぼろぼろになっていく。努力して、プログラムの為に尽くしてもプログラムが完成しないことに気づいた。
完全に逃げてるけど、俺の中でプログラム作ることはただたんにレッテルをとりたいだけ
そう思ってて今日まで過ごしてきたら、韓国戦見てたときに母さんが「あんたプログラム作らんの？」って
言ってきて「俺はもう作るのあきらめた」と言ったら、弾小飼がいかに Perl がすばらしい
か説いてきた。それと「一回もできたことない奴が分かったような口聞くな」とか
「そんなの負け犬の遠吠えだ」などと言ってきた。それでこっちの
意見を全く聞こうせず、ずっと MacBook Air のすばらしさを熱弁してくれた。
自分で逃げてるなんて百も承知、俺はもう疲れたんだよ。
日々見下されてて、俺に対する態度がひどくて劣等感を感じて、バイトは土日絶対１日入って、
それでコーディングするだけでも多大な労力を使ったのに、それが就職したら
毎日設計書書き？毎月の生活苦しいのに、定期的に設計書書いて誤字とかどうでもいいダメ出しをもらう？
そもそも好きって感情がわからんからプログラミングに意味を見い出せない。
だから今はもう一生口だけブックマーカーでいいかなと思っています。
思うと少し残念な気持ちに成る。
http://d.hatena.ne.jp/nakamurabashi/20110726/1311653472
知性というのは、俺の使いかたにしたがっていえば、社会的な知識や知恵、生きるために必要な能力、対人関係に応ずる能力などとは違う。むしろ俺は、それらを問い直す能力のことを言っている。
最近の学習至上主義に真っ向から喧嘩売る定義。その定義に基づく三段論法がすごく私好み。
理性的でない、というのは、
１．世界に対する自分の比重が大きくなってしまった状態のことだ。年を取ると子供に戻るというのは、このためかもしれない。自他の関係を健全に把握することができない。
（中略）
２、自分が自分であり、社会がこのようであることに疑いを抱いたことのない人。自分が泣き、笑い、怒ることに疑いがなく生きてきたような人。おそらく学習効率の極めていい動物
（中略）
３、悩みや苦しみには、まだ隙間がある。しかし知性を失うことを想像すると、これは真っ暗だ。死にも似ている。（そういうときはだれかがさっくりと刺してくれることを祈りますね。刺されるこっち側に傷口を察知するだけの感受性が残ってればの話ですが。自分を救うだけの知性が残ってればいいですね）
なぜこんなにライフハックを疑わずに信じちゃう人が多いのか。自己啓発で自分を救えると思える人が多いのか、
なんというか自分以外の変数を考慮せずに世界を把握しちゃえる人が多くなってるのかな。よくわからんけど。
そして、締めの
特例がないってことほどクソむかつくことはない
個々のケースの判断で例外を無視する（統計的な平均だけで判断する）のは馬鹿だと思うよ。
でも例えば企業の採用活動とかでは、いちいち外れ値をチェックするのはコストがかかりすぎるから、統計的判断でバッサリ切るというのは合理的だと思う。
同様に、それなりに良い家柄の人が結婚相手を探す場合に統計を判断に入れるのもまぁアリだと思う。結婚する個人の責任だけじゃリスクを吸収できないからね。
逆に「最近は離婚率が高いんだから結婚する奴は馬鹿だね」とかいう主張をする非モテは馬鹿過ぎると思う（実際は負け惜しみでやってるだけだろうけど）。
背景にあるその他の情報（確率変数）が全て周辺化（積分して平均値で代表することと思えばよい）されてるということを理解してないなと思う。
2枚のコインが本当に物理的に区別できない場合は、量子力学で言うところのボーズ統計みたいな確率構造になると思うよ。
「各コインの表裏」ではなく「表の出るコインの枚数、裏の出るコインの枚数」だけが意味のある確率変数（量子力学の言葉で言うと量子数）になる。
確率空間の一般論はhttp://ja.wikipedia.org/wiki/%E7%A2%BA%E7%8E%87%E7%A9%BA%E9%96%93みたいな感じになるけど、
ここで言う標本空間にどういう集合を設定するかと、標本空間上のボレル集合(問題文の言葉で言うと「部分集合」)に対して定義した確率測度が現実の物理現象にきちんと対応してるかだけが問題。
ボレル集合としてσ={φ、(表、表)、（表、裏）、（裏、裏）}だけ（φは空集合）を考えた確率空間を構成しても多分大丈夫だけど、その場合はP((表、表))=P((裏、裏))=1/4,P((表、裏))=1/2としないと
確率測度の条件を満たさないし、現実にもマッチしないということ。
どうしてそれが「現実にマッチ」するのか分からなかったら、2枚コインを用意してひたすら投げまくるか、以下のRコードを実行するとわかると思うよ。Rは適当にインストールしてくれ。
（増田のうんこ仕様のおかげで＜と＆を全角入力せざるを得ないので、そのままコピペはできないのに気をつけてね）
x1 ＜- ifelse(runif(1000)＜=0.5,1,-1) x2 ＜- ifelse(runif(1000)＜=0.5,1,-1) z ＜- mapply(function(x,y){if(x==1 ＆＆ y==1){1}else if(x==-1 ＆＆ y==-1){3}else{2}},x1,x2) hist(z)