「計算機科学」を含む日記 RSS

はてなキーワード: 計算機科学とは

2017-04-17

知能を上げる方法

わたしの知っている知能の高い人たち(wais-iiiでIQ140~くらい出す人たち)はみんな興味のないことが全然できない。

好きなことばっかりやってて、どうでもいいことに対してはすごく冷淡。

でこれまでわたしは彼らのそういう性質は知能の代償なのかなって思ってたんだけど、実は因果の向きが逆で、好きなことしかできないから彼らは知能が高いんじゃないかって思うようになった。

そう考える理由ちょっと説明してみたい。

まず人類学問の体系は、だいたいどんな分野であれ似たような方法論に依っている。

物理学でも文化人類学でも計算機科学でもやっていることはだいたい同じだ。

で、知能というのはそこで共通する一般的思考の枠組み、もの見方だと思われる。

少なくとも知能検査で測られる知能っていうのは、そういう性質抽象して測るために作られているはずだ。

そしてこの方法論を学ぶには、浅く広く物事を知るよりも、ひとつ分野を定めて深く掘り下げるほうが効率が良い。

というのも、分野に関係なく、ある程度の深さまで達しないと現れてこず習得もできない思考の仕方というものがあるからだ。

そう考えると、一つの興味をひたすら追求しそれ以外を無視するような知性のほうが、広くこつこつと学んでいく知性よりはやく高度な思考法を獲得するのは当然だということになる。

というわけで、賢くなりたい人はいろんな分野に浮気せず、ひとつ学問を究めてみると良いんじゃないかな。

おすすめ数学哲学です。

(追記)

なんか誤解されているみたいだけど、頭の良い人がみんな専門馬鹿だと言ってるわけではなくて、

一度一つのことを深く追求して得た一般的方法はわりと応用が効くよ、知能ってつまりそういう能力じゃない?ということが言いたかった。

で興味が偏ってる人はそういう発達過程を経やすいんじゃないか、というのがわたしの推論。

もちろん万能っぽい人も中にはいるけど、彼らは興味の幅がそれなりに広いだけで、

やっぱりそれ以外のところでかなり欠落してたりする。

それから、waisでほんとの知能を測定できるかって話になると、そもそも知性とはなんぞやという議論になってしまうわけだけど、

それはあまりに複雑な話題から書かない。

ただしwaisで高いスコアを出す人たちの能力思考法が傍から見ていてそれなりに便利なものであるのは間違いなく、

彼らがそれをどうやって身につけてきたのか、なにが要因としてあるのか考えるのには意味がある、と思った。

知能に直接関与する遺伝子は見つかってないみたいだしね。

2017-03-23

http://anond.hatelabo.jp/20170323162129

ここに書かれていることは概ね正しい.この方は自分モチベーションが低下したことを嘆いておられる.そういう方々は大学に多くいる.しかし,日本大学にはこのような劣悪の環境の中で,モチベーションが低下せずに生き延びている集団も一部存在する.それは最近流行りの言葉で言えば,サイコパス教授だ.学生ポスドク助教そのすべてを人間として扱わず自分出世or地位or名誉のために利用する.そのため,この劣悪な日本環境の中でもそれなりの成果が出る.その業績を元手に,大型予算が当たる.更に悲劇が拡大する.私の少ない知り合いである若手研究者と話しただけでも,医学系や生命科学系,工学系(の中のどの分野でも),農学系.どこにでもいる.比較若い分野である情報/計算機科学にもいる.

最近の若手研究者は目が死んでいる.最近医学の発展により,これらの教授寿命は長い.国立大退官後も院政を引いて分野内で君臨する.偉い先生基調講演をさせるためだけの謎のシンポジウム企画される.下々の者が奔走する.ポスドク助教が偉い先生パワポをつくったり,大型予算提案書や報告書をつくったりしている.そして,外部向けには「うちのラボ生産性の高さの秘訣は若手研究者自由環境を与えることです」みたいなことを言っちゃう.若手研究者マジで国外研究機関に行った方が良いと思う.

ちなみに私は,飲み会の場で(直接の上司ではない別の教授に)口が滑って,「海外大学で働きたいっすわ.研究だけしたいっすわ.(研究上ではない上司の尻拭いの)雑用もう嫌っすわ」と言ってしまい,(直接の利害関係がない)その教授にブチ切れられた.いま思えば,自分がそういうことをしたら,周りの若手が真似をする負の外部効果があるからだろう.

海外大学研究者と話すたびに「日本大学ってなんであんなにヒエラルキー構造なの?バカなの?死ぬの?」と言われる.そのたびに儒教の影響じゃないっすかねと言っている.(とはいえ,私はよく知らないが,バイオ化学であれば,海外ラボも完全なヒエラルキー構造なのだろうと思う)

念のために書いておくと,私は海外大学で働くことを決めた.じゃあ,いいじゃんと言われるかもしれないが,自分母国に愛は当然あるし,母校にも愛はある.なので,国内大学の質が上がったり,生産性が上がることは素直に嬉しい.どうにかしたいとは思う.が,個人の力でできることは本当に少ない.ただただ悲しい.

2017-01-18

プログラミングって「得体がしれない」よな

プログラミングって、これから始めてみようっていうとき、なんだか「得体のしれない行為」っていう感覚がありませんか?


ぼく自身は、プログラムを書いてる側の人間で、いまでこそ少しはプログラミング本質的な難しさをわかってる気になってます。でもつい数年前までは、プログラミングは難しくはないけど得体がわからない、という感じでした。

そのへんのコードを組み合わせて動くものはできるけど、何がどうなっているのかは知らんし、ググって分からないものはできない、という方向で、「プログラミングは難しい」と思ってました。


最近になって、プログラミング義務教育必修化の話題とか、コピペプログラマー話題とかを目にするたびに、かつて自分プログラミングに対して抱いていた「得体のしれない行為」という感覚が思い出されてしまい、少しざわざわした気持ちになったので、ちょっとここに書きなぐらせてください。


だいたいが個人的な話なので、そういうのがうっとうしい人は無視してください。


ぼくが世の中にパソコンという道具があることを知ったのは、たぶん中学生ときです。30年くらい前。当時、電気屋の売り場ではけっこうな床面積を使ってワープロ文章入力する専用マシン)が陳列されてました。文章を書くのは好きだったけど、字を書くのが死ぬほどめんどくさかった自分は、ワープロさえあれば自分小説とか書くのになあと思いながら指をくわえて電気屋の店内をうろうろしてました。しかし、ファミコンすら買ってもらえなかった家計ではワープロなんぞ買ってもらえるわけもありません。そのうち巡回してた電気からワープロが消え、それに代わってパソコンのコーナーが広がっていきました。このパソコンというのは、よくわからないけどワープロとして使えるっぽいし、どうやらファミコンを持っていない僕にもゲームができるらしい、おれに必要なのはこれだ、というわけで、中学生だった自分パソコンという存在に興味を抱くようになったのでした。


はいえ、だからといってパソコンを買ってもらえるような家計ではなかったわけなので、カタログを熱心に眺めるだけの毎日が続きました。その当時の自分にとって、パソコンが欲しいといったら、それはNECを買うかエプソンを買うかという選択でした。冨士通からパソコンが出ていることは知りませんでした。マッキントッシュっていうやつもあって、このPerformaっていうやつはなぜか安いとか、よくわからないけどシャープとかソニー独自パソコンを作っているぞとか、そういう情報パソコンに対する認識のすべてでした。当時の自分にとってのパソコンは、電気メーカーから発売されている商品一種であり、ラジカセとかテレビと同列の存在でした。


なんでこんな話がプログラミングにつながるかというと、ひょっとして自分プログラミングにずっと感じていた「得体のしれなさ」の源泉の一つは、こんなふうにパソコン電化製品として見ていた当時の感覚の延長だったのかもなあと思ってるからです。


ラジカセなら、CDだのテープだのを入れて再生タンを押せば、そのハードウェア機能物理的に体感できます。それに対してパソコンは、プログラミングちょっとやってみても、その行為と、そのハードウェアとが、感覚的に結びつきません。もちろん、プログラミングというのは、物理的なデバイスに結びつけて考えなければできない行為ではありません。しかし、パソコンを「カタログ商品」として見るところから入ってるばかりに、そこでやるプログラミングという行為ハードウェアとの結びつきが見えにくい状態に、なんとなく居心地の悪さを感じていたように思うのです。


もし自分スタート地点が、パソコンを使って文筆やゲームをするところだったら、パソコンは文筆やゲームのための箱だったでしょう。その後でプログラミングを始めていたなら、プログラミングという行為を、文筆やゲームに関連した創造的な活動として学べたかもしれません。


ところが実際には、自分はつい数年前まで、パソコンという電化製品に対する漠然とした行為としてプログラミングを捉えてた気がします。


プログラミングを始めたのは、高校生になって誰も使わないFM77が部室に置いてあったので立ち上げてみたらF-BASICインタプリタが起動したからでした。とくに何をプログラミングすればいいかもわからなかったので、教科書雑誌コードを転記したり、ループで線画を書いたりして遊んでいました。大学に入ってからも、授業でFORTRANとかLispをやらされたけど、基本的自分目的をもってプログラミングするのは数値計算くらいのものでした。そのころになると、本で情報を探して(まだインターネット検索は使い物にならなかった)適当コードをつなぎ合わせるのがプログラミングだと思ってました。そんなん面白くないなあ、とも思ってました。


この感覚、完全に、いま揶揄されているコピペプログラマーのそれだったと思いますちょっと話はそれますが、ブロック遊びとか砂場遊びって、ほとんどの人はわりとコピペプログラミングと似たような感覚でやってるんじゃないでしょうか。パーツを勘で組み合わせたり、とにかく砂を盛っていったりすれば、家みたいなのができるよね、という感覚プログラミングは、自分にとってそれに近い作業でした。学生のころは、内心、自分にもパソコンサンプルコードさえあれば何かすごいものを作れるかもなあ、くらいに思っていたふしもあります


自分バカでした。パソコンがあるとかないとか、関係ないのです。パソコンさえあれば、なんて思う者に、本当のプログラミングがわかるはずがありません。


そんなこんなで、自分はまともにプログラミング経験しないまま社会人になったわけですが、幸いにもプログラミングに対するこの感覚は、仕事パソコンを日々使うようになってから徐々に変わっていきました。

具体的には、パソコンが、自分の中で「カタログ商品から武器」へと変わりました。それと同時に、プログラミングという行為が、武器開発という位置づけになりました。

武器というのは言い過ぎだとしても、ちょっとしたプログラミングは確かに業務上課題を打開しました。それなりに計算機科学教科書を読んで勉強をしたこともあって、いつのまにかプログラミングに対する「得体のしれなさ」も解消してました。


結局のところ、自分にとっては、プログラミングという行為の「得体のしれなさ」から解放されるまでにずいぶん長い時間必要だったことになります自分がそうだったからといって他人もそうだとは限らないですが、たとえば小学校で形だけプログラミングを教わっても、分かるとかわからないとか、好きとか嫌いとか以前に、なんかモヤモヤした気持ちになるだけの子もも少なくないんだろうなあ。それは不憫だなあ。


かといって、自分がいまプログラミングで少しは戦えてるのは、そのむかしパソコンに憧れがあって、得体がしれないなりにプログラミングをする機会が若いときたまたまあったからでもあるので、そういう機会になるなら小学校で形だけでも教えるほうがいいのかなあとも思います


オチがないので、このへんで。

2016-09-06

続、藤沢数希の経歴に関係する情報を集めています

http://anond.hatelabo.jp/20151028235324

去年この時期にこのエントリーを書いた増田です。

あれから色々と藤沢数希についての情報が出て来るようになったので今一度まとめます

何が情報ありましたら教えてください。

//

根拠

1、著作から情報

計算科学物理学博士号を取得後ポスドクを経て

金融機関で計量的な研究モデル作製やリスク管理分析やトレーディングに従事とある

2、ツイッター情報

東京以外出身、年齢は四十台団塊ジュニア中学受験を経て国立大学へ。

大学工学部修士からアメリカへ。大学時代東京南東に住んでいたと思しき情報あり。

プログラマー経験ありと発言

3、ブログから情報

文系でも金融研究職に就ける、営業負け組みではない発言

2005年ブログ開始。

2008年09月会社が駄目になった発言

//

検証

先ず学問的なバックボーン

藤沢には数学物理学素養は一切ない。また工学部で学ぶ基礎的な方程式から理解できない。

物理学研究者と言うのは嘘。伝統的な工学部学科ではなく情報関係専攻と推測。

計算機科学コンピューターサイエンス)か計算科学か。

研究や知能水準からいって、工学系のコンピューティングシミュレーション専攻と推定

金融機関自称専門職であったと言う記述と一致。せいぜい統計屋。

次に大学について。

知能水準から言って中堅国立東京に限れば電通・農工・現首都大

藤沢日本大学いついて無知から批判していた時にその条件に外れていた事、

地理的要因から言って確率が一番高いのは電通大

職業について。

金融全般知識役割や仕組、法律経済学経済政策については無知

そしてネット上の投稿記事を見てもとてもではないが経済に明るいとはいえない。

ワイドショーレベル新自由主義経済政策新書ニュースコピペしかない解説

厳密な区分としてのアナリストではないことは確実。山本一郎氏の発言と一致。

次に自称金融専門職、せいぜい統計屋ですら実際の仕事内容と認識が一致しないこの程度では厳しいことから疑わしい。

現場分析トレードに関しても実務経験から過去無知経験と切り捨てられている。故に詐称であろう。

その発言水準を考えれば研究職も疑わしい。一般職事務のような後方業務確率が一番高いか、あるいは営業

藤沢自分知的水準から職務内容を誤解しているかもしれない。

そして会社山本氏から情報で元国際証券と言うのがある。

そして会社が駄目になったと言う発言と時期が合うのはアムロ銀行

時系列を考えれば国際証券合併以降リストラに会いアムロ転職するもリーマンショック首になり再就職できない可愛そうな人。

最後恋愛経験について。

これはもういうまでもなく男子一貫校から工学部修士から

アメリカへと言う経歴から若い時代には異性に触れてこなかったと思われます

恋愛工学(笑)自身で真に受けて雰囲気も読めずうしじまいい肉に実行し表立って嘲笑されたこと

独身であることから非モテであるのは確定。

//

補論。

藤沢大学外資海外企業と言ったものに纏わる発言は全て作り話が確実。

情実や事例を知っているふりをしているだけ。

実物の藤沢は年相応に老けたどこにでもいる普通のオッサンだろう。

これに加えて藤沢には発達障害疑惑、病的な虚言壁の疑惑が絶えず提訴されている。

//

結論

藤沢数希子供のころからリガ勉強するも頭が悪すぎ中途半端工学部しか進めず

工学いろはから理解できず統計計算処理でお茶を濁し

博士号まで取得するも専門的な仕事や高待遇職業にも就けず

典型的日本や二流企業の木っ端サラリーマン会社都合や景気で真っ先にリストラされお先真っ暗な人間

現在投資家を名乗っているものメルマガの内容がニュースコピペ以上ではないことからしても実態はない無職だと思われます

藤沢数希はそんな自分の惨めな人生を認められず理論物理学者だの証券会社エリートだの嘘を付き

そればかりかコンプレックスから高学歴日本社会普通サラリーマンを延々と作り話で中傷する本物のクズです。

経歴詐称を利用して他人の本のを切り貼りしたゴミ馬鹿に売っている詐欺師

愚にもつかない実用性のない思いつきと成功もしていない俗流成功論・ビジネス論を語るカス

その総決算が、四十半ばのオッサン提唱する強姦指南書こと恋愛工学(笑)です。

2016-06-17

Winnyは悪だろ

Winnyはもう今は誰も使ってないツールだ。

作者である金子氏が故人となって久しい。

彼の早すぎる死は日本計算機科学界の大きな損失だが、それでもWinnyは結局、悪だ。



Winnyについての話題になると、必ず出てくるのは包丁の話だ。

結局使う者の責任だという、あれだ。

しかWinnyはそれとは違う。

彼が2ちゃんねる47氏と呼ばれていた頃のレスを見れば明らかだ。

次世代WinMXとなる為、権利侵害された著作物児童ポルノを、より広く安全に共有する為に作られたのがWinnyスタートだ。



彼は裁判無罪を勝ち取った。

しかし、だとしても彼は悪意をもってWinnyを作りバラ撒いたのは事実だ。

その悪意が、単に法の裁きを受けない性質のものだったというだけだった。



結局彼は死によって悲運な天才となり、全てを肯定された。

しかしだとしても、少なくともWinnyは悪だったのである

俺は彼に生きて欲しかった。

長く生き、年老いた時に実はあれは悪だったと認めて欲しかった。



お尻ぷりんセスより

2015-11-17

http://anond.hatelabo.jp/20151117013512

プログラミング世界では semantic に構文的という訳語を当てることになっているのか」

これは単純ミスかな…。計算機科学において意味(semantics)と構文(syntax)は明確に区別される概念。そもそもSchemeとAlgol 60が構文的に似てるとは思えんし。

2015-07-22

http://anond.hatelabo.jp/20150722001956

競技プログラミングというより、計算機科学実践できるかどうかを問うているんだと思う

全員が計算機科学を修めている必要がある業界はあまりないと思うけど、

計算機科学の知見が足らないと不合理な状態に陥りがちなのでは、とも思う

2015-05-27

拝啓 岡部健

以下のエントリ、読ませて頂きました。



関数型プログラミングと私の著書の正確性についてきちんと議論(論争)します。

http://kenokabe-techwriting.blogspot.jp/2015/05/blog-post.html?m=1



私は岡部健様の学説にいたく感銘を受けております

匿名ダイアリーなど読まれていらっしゃらないかも知れませんが、もしお目に止まりましたら一読くださるよう、お願いします。

また、昨今の岡部健様への風当たりや今後の研究活動について、一つの方針を具申致しとうございます



まず、岡部健様は、今ネット上で繰り広げられている論争に、一切反論をするべきではないかと思われます

なぜなら、岡部健様のご高説は全て正しいものからでございます

しかし、時代の先を行き過ぎていまして、それが正しい形を持って具現しないだけでございます

丁度、チャールズ・バベッジの階差機関が当時の技術で実現できなかったのと同じでございます

100年、200年先において、岡部健様の学説が再評価され広く普及することは間違いのないことでございます

しかすると20年もしたら、どこぞの権威のある学者岡部健様の理論を再発明するかもしれません。

権威主義に取り憑かれた凡骨どもの目が覚めるまで、慈悲の心を持って辛抱強く待つ必要があるかと思われます

言いたい奴には言わせておけばよいのです。

最後に逆転することは目に見えているのですから、何も今躍起になる必要などないではないですか。

ですので、岡部健様の学説により一層の磨きをかけることに尽力するのが人類未来のためであるかと具申いたします。

また、一プログラマとして、益のない批判合戦よりも、岡部健様が岡部健様だけに見ている『論理』の世界について、

一言でも、一文字でも多く語る姿を見ていたく思います



では、なぜ岡部健様の学説が正しく聴衆に伝わらないのか、愚考しましたので申し上げます

岡部健様の見ている『論理』の世界は、完全に、全て、オリジナルのものであり、

アリストテレスデカルトスピノザも、誰も手に入れることのできなかった、真なる物の中の真、究極の真理だからでございます

それを表現する言葉は『イデア』でも『遅延評価』でも『関数』でもなく、完全にオリジナルな物でございます

人類は未だかつて、岡部健様の頭の中にある理論体系を記述する言葉を持たないのでございます

ですので、既存計算機科学における、全ての専門用語を省いた言葉で、全く新たに理論を書き上げて頂きとうございます

誤解を恐れず申し上げれば、岡部健様の提案するプログラミング手法関数型プログラミングではございません。

これは、岡部健プログラミングでございます

プログラミングという言い方も正確ではございません。

岡部健型の真理の記述法とでも呼ぶべきものでございます

なぜなら、プログラムとは「現存する計算機をいかに利用するか」の利用方法を記したものからです。

岡部健様の提唱する理論は、そのような矮小適用範囲に収まらないかと愚考いたします。

現在計算機科学が、現存する計算機をいかに利用するか、などという、矮小範囲に留まっている限り、

岡部健様の見ている世界を、この世に具現化することなど、夢のまた夢でございます

ましてや脳の血の巡りの悪い、権威主義者どもを啓蒙するなど。



ですが、プログラムには岡部健様の理論の一部が顕現しているものと愚慮いたしております

それは、形式的言語である、というただ一点のみにてのことと思います

岡部健様のご考案なされたspinozaもその一つかと思われます

しかしそれも、現存する計算機上で動かなければならないという、極めて瑣末な事情により、

岡部健様の思考を完全に書き下すには、全く不十分なものになっているかと、愚慮愚考いたすものでございます

ですので、岡部健様には、現存する計算機上で動くことを前提としない、全く新しい形式言語をもって、

問題論理』を書き下す手法をご教授願えないかと、お願いするものであります

そうすれば、必ずや岡部健様の学説は後世に評価されることと信じております



重ね重ね、この蒙昧な具申をお読み頂き、感謝いたします。

少しでも偉大なる岡部健様のお力になれたらと、その一念にて出過ぎた真似を致しました。

しかし、これは偽らざる私の本心でございます

どうかお心苦しくなららぬよう、お願い致します。

2015-01-28

http://anond.hatelabo.jp/20150127003906

http://anond.hatelabo.jp/20150127035153

この件、はてな民向きには「計算機科学におけるニセ科学トンデモ案件」と言えば通じるんじゃねえかな。

実際、苦言を呈してた人たちの中にはその分野の専門家研究者が少なからず含まれてる。

相対論とか量子論に湧いてくるようなアレなんだよ、要は。

関数型言語ユーザー)に難アリみたいな反応はちょっと悲しいなあ。

2014-05-13

http://anond.hatelabo.jp/20140511211552

F欄卒の社畜男子です。私も数学勉強中です。



1) 極限と微分

AAが好きなら以下をどうぞ。楽しく読めると思います

http://yaruomatome.blog10.fc2.com/blog-entry-371.html



2)積分

微分の反対と言われますが、よくわからないと思います。残念ながら上記のスレッドにも出てきません。

わかりやすい説明を以前どこかで見たのですが、忘れてしまいました。



3) 行列

xとyの方程式を別の書き方で表したものです。

http://www.eisaijuku.join-us.jp/renritu-houteishiki-no-gyoretu-kai.html



4) なぜ必要

いろいろ意見があると思いますが、工学するためだと思います

微分形式、積分形式で表せる現象は現実世界にとても多いです。

逆に工学しないなら、あまりいらないと思います

工学けが理系じゃないし、確率に興味が出れば統計学の方に進み、

計算機科学に進んでも面白いと思います




ようはなんとなくわかればいいんです。

2014-03-25

http://anond.hatelabo.jp/20140325220012

ウェブ以外のものも急速に簡単になっていくとおもう。

これも増田の言う通りですよ。

計算機科学とか数学とかアセンブラがどうとか、

あんまり関係ない話だと思うんですけど・・・



「難しいことを簡単にすることがお金を儲ける一つの方法」で

あることは間違いないです。



ただし、「その難しいこと」、が

需要が少ない場合、もしくは、技術的に本当に難しい場合のみ、

なかなか簡単になりません。



ということは、

自分需要が多いと思う、のであれば、または

自分ならば技術的に難しくない、と考えるならば、

それは立派なビジネスチャンス、ということですね。

http://anond.hatelabo.jp/20140325221535

君その何も分かってないのに思い込みだけで断定して論を進めようとすんのやめろ。

計算機科学の基礎なり数学の基礎なりを少しは勉強してみてから口を開け。

2013-10-26

http://anond.hatelabo.jp/20131026142229

いやD-waveマシンは実際に販売されてるから

その程度も理解してない人間は「あらゆること」なんて言っちゃだめだよ。

その調子だとラムダ計算とか圏論とかの計算機科学の基礎すら怪しそうだな。

「あらゆること」なんてぶち上げるくらいだから流石にその程度はマスターしてるんだろうと思って触れなかったんだけど。

ちなみにクリフォード代数とかconformal algebraとかは分かってる?

CGとかやるとき結構重要なんだけど。

2013-07-04

計算機科学学問じゃない

http://anond.hatelabo.jp/20130703205623

知り合いの話を聞いた感じでは、計算機科学研究って数学基礎論二次創作みたいな感じなんだな。

なんかのロジックについて延々論文を書くだけで研究になるんだから

少なくとも学問じゃないよね。

別に趣味ならいいけどさ、国の金もらってやることか?

税金二次創作やるって恥ずかしくないんだろうか?

生きていることが恥ずかしくなったりしないんだろうか?

金回すべきところは他にいくらでもあるだろ。

まああの人たちは、本質()とか真理()とか分かってるから世界が違って見えるんだろうな。

幸せそうで羨ましいことだ。

2013-04-30

http://anond.hatelabo.jp/20130430233611

その中でも数学なんて食えない筆頭だろ

数学金融でも保険でも使われてる。

計算機科学やその他の工学の基礎だし、社会科学でも欠かせない。

純粋数学でも、暗号理論のように巨額の富を生むことがある。

女は現実的なのでそういうのを好まない、同じ学ぶなら「手に職」を付けられる実学を好む

それだと、文学部や国際関係女子人気が説明できない。

2013-03-28

科学技術計算Python

科学者必要とするもの

必要ものの列挙

現存する解法

どの解法が科学者にとって役に立つのか?

コンパイラ言語:C, C++, Fortran, 等
スクリプト言語Matlab
他のスクリプト言語Scilab, Octave, Igor, R, IDL, 等
Python はどうなの?

2013-03-26

http://anond.hatelabo.jp/20130326050224

プログラミング出来ない奴ちょっと来い」http://anond.hatelabo.jp/20130322031333

う~ん、この人の日記意見は、駄目だな~

特に駄目だと感じるのは、

「というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム

などを作るためにプログラミングするのではない。

目の前の問題を解決するためにプログラミングを行うからだ。」

学んだ計算機科学の知識や、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化は

「手段」であり、「手段」として使いこなせないならプログラマーじゃないね

あと捉えている「上級者レベル」が低すぎ。

2013-03-22

プログラミング出来ない奴ちょっと来い

プログラミング出来る方法教える。


世の中「プログラミング言語」を説く本はごまんとあれど「プログラミング」を説く本やブログはあまりない。

いや実際に "ない" というのはかなり語弊があるかもしれない。

しかし、通常この種の説明している本に辿り着くまでには多くの時間必要だ。

普通の人は、多くの間違った方法を試し、その都度試行錯誤を重ね、プログラミング経験を経ることよって、重要概念を獲得するのだと思う。



例えば、「計算機プログラム構造解釈」や「実用 Common Lisp」、「コンピュータプログラミング概念技法モデル」などの書籍現実の問題に対し "プログラム" をどう書くかという問題に正面から取り組んでいる良書だ。



しかし、どれだけ”普通の”プログラマが上記のような書籍を読んでいるのだろうか。


そして、"普通プログラマ" がプログラミングを学ぶ書籍として、それらは果たして適切と言えるだろうか。

僕はそうは思わない。



というのも、多くの人は計算機科学を学び、効率のよいアルゴリズムデータ構造、美しい階層化・モジュール化されたプログラム、などを作るためにプログラミングするのではない。目の前の問題を解決するためにプログラミングを行うからだ。



それは自分の作りたいアプリだったり、

クライアントから発注されたプロジェクトだったり、

上司から頼まれた仕事だったり、

業務を効率化させるための Excel マクロだったり、

授業で出された宿題だったり、人それぞれだろう。



このような目の前の問題を解決したい人達が、わざわざ LispMozart など何の役に立つのか分からない言語を、根気よく勉強するのだろうか。(ちなみに、LispMozart は上記の書籍で実際に使われている言語である。)


目的現在の問題を解決することであって、

新しいプログラミング言語を学ぶことや、プログラミングの種々の概念を獲得することではない。



もちろんプログラミング言語を上達するためには一つでも多くの概念を会得する必要があるので、あるレベル以上を目指すのであればこれらの書籍を読むことや、抽象化を実現するための様々なツールを手にすることは必須だと思う。

純粋プログラミングを楽しんでいる人やハッカーを目指したい人はこのような文章を読むのではなく、ぜひ上記に挙げた本を実際に購入し、自分の手で動かして確かめてみることを勧める。プログラミングに対する考え方や姿勢が変わるのは間違いないと思う。



今回はそのような”純粋プログラミングを楽しんでいる人”に向けた文章でない。

現実の問題をプログラミングを用いて取り組んでいる人に向けて書いた文章だ。




そのような人の中で、なかなかプログラミングが上達しないという人に向けた文章である

もしプログラミング学習限界を感じているのであれば、プログラミング学習方法が間違っている可能性が高い。

そして残念なことに、初学者向けの書籍では、"プログラミング言語の文法" を説く本はあれど、"プログラミング学習方法や上達するための正しいスタンス" を説く本はほとんどない。




できるだけ多くの人にプログラムをする楽しみを知ってもらうためにも

より多くの人がより生産的にプログラムが出来るようになるためにも

そして特に、右も左も分からなかったプログラミングを始めたばかりの過去自分に対して、

効果的な学習方法プログラムする際の指針を書き記したいと思う。



それらは単に指針を示しているだけなので、

どんなプログラミング言語を使っていようとすぐに実践に移せるはずだ。

後はどれだけそれを実践に移し地道にプログラミングしていくだけである



正しい努力と、ちょっとしたコツさえ知っていれば驚く程生産性を挙げられるはずだと確信している。



プログラマレベルを以下の 3 つに分けてそれぞれについて説明していきたい。



1. 初心者レベル

プログラミング半年未満

・使えるプログラミング言語は一つだけ


ただし以下のことは出来ない。


・500行以上のコードが書けない

エラーが出た時の対処方法が分からない

写経は出来るが、自分プログラムが書けない



2. 中級者レベル

プログラミング半年 〜 3年

・1つ以上のプログラミング言語は使える

オブジェクト指向は理解している


ただし以下に当てはまる。


自分制作しているアプリケーション向けに "実用的なフレームワークライブラリ" を書けない

・1万行以上のコードだとスパゲッティコードになり、保守不能になる

・重複するコードが多く存在する

・適切なサブルーチン化できない



3. 上級者レベル

プログラミング歴 3 年以上

現実の問題に対して適切なデータ構造アルゴリズムを選択できる

抽象化について理解し、可変部分と不変部分を考慮した設計ができる


全てのプログラマはどれかのレベルに属するはずである

またそれぞれのレベルクリアするには明確な壁がある様に思う。

これらの壁を超えるにはどうすればよいかを説明する。


前置きが長くなったが、以下ではまず初級者レベルの人に向けた具体的なアドバイスをする。




初心者レベルの人に向けて


完全に初心者レベルの人はまずどのようにプログラミングを行えばよいのか分からない。一行も書けない。そのため、必然的に以下のような行動を取ると思う。


検索エンジンで似たプログラム検索コピーペーストする

・本に載っているプログラムをそのまま書き写す(いわゆる写経


上のような行動を行なっているだけでは、いつまで経っても自分プログラミングが出来るようにならない。

なぜなら上記のプロセスでは決定的に重要なことが学べないからだ。

それは、【プログラミング言語モデル】を自分の中に作ることである



プログラミング言語ルールの塊である

それは普通言語と同じように文法が存在し、そのしきたりに沿って記述しなければならない。

のしきたりを学べば書けるようになれる。非常に単純だ。



それなのに、なぜいつまで経っても書けないのか?



それは、”書き写す・コピーする” だけでは、そのしきたりが習得できないかである



特に最初のうちのプログラミングは頭を作業使う作業でなく、むしろ "体で覚える" 類のものである

それは例えば、日本語を話すことと似ている。

友達と会話する時、頭を使っているだろうか。

それは簡単な受け答えについては体が覚えているので、考えるより先に日本語が出てくるのではないだろうか。



プログラミングも同様に頭を使うのではなく、こうしたい時はこう書く、という反射神経を育てなければならない。



もちろん日本語話せるだけでは、ミーティングプレゼン出来ないのと同様に、文法が出来ただけではプログラミングが出来るとは言えない。しかし、文法が出来ないと "現実の問題に対処するソフトウェアを作る" というレベルには到底進めない。そのために、まずそのような文法の反射神経やパイプラインを頭の中に作る必要があるのだ。



それには以下の点を意識してプログラミングすればよい。



・"何をしたい時" に "どう書けば正しく動くか" というデータベースプログラミング言語モデル)を自分の中に作ること



このままでは抽象的すぎるので、このような "データベース" や "考える習慣" を自分の中に作るための具体的な指針を以下に挙げる。



1. エラーをたくさん出す

2. デバックの仕方を覚える

3. 小さく動かして確かめ

4. Google を使い倒す



まり、小さく動かして、エラーをいっぱい出し、デバッグを素早く行なって、分からないことは google などの検索エンジンで解決する。これが上達のコツである




これらについては以下で詳しく説明するとして、

まず最初初心者ありがちな間違いをいくつか列挙してする。




関数メソッドをたくさん覚えなければいけない


無理して覚えなくてよい。

プログラマは覚えることが星の数ほどあるので、メソッドなどはリファレンス片手に検索できればよい。

よく使うメソッドなどについては自然に覚えていくので、積極的に覚える必要はなし。それこそ、"体" で覚えるはずである

覚えられないメソッドについてはそもそもあまり使わないから覚えられないので、重要性は低く覚える必要はない。

しろ実現したい処理が既にメソッド関数として提供されていないか、調べる力の方が大事



エラーがいっぱい出てつらい


全く問題ない。

以下で述べるようにエラーとどう付き合うかが非常に重要



写経をしなければならない


教科書や本の中に書いてあることをそのままエディタで書き写し、実行することを写経という。

上記でも述べたように、これからまり無駄努力をしないことを願って言えば、

写経にはほとんど意味がないと思って取り組んだ方がいい。

写経して書いた 10000 行のプログラムより、自分で考えて書いた 100 行のプログラムの方が遥かに意義がある。


なぜならば写経は "作業" だからだ。

そこに "言語モデル" や "思考" が伴わないと意味がない。

”思考” が伴わないとただの書き写す作業をしているだけだ。

自分の中に "モデル" が出来ていないので、いざ自分プログラミングしようと試みても、写経をしているだけでは全く書き出せないだろう。



写経はそもそもプログラミングに対するスタンスプロセスのもの勘違いさせる危険性をはらんでいるいる。

写経する場合、書き写しの間違いがなければプログラムは問題なく動く。

しかし実際のプログラムではコンパイルや実行するまで、そのプログラムが期待通りに動くかどうか、は絶対に分からない。

そして通常は一気に全てを書き上げるのではなく、まず小さなコア部分を書き、少しずつ他のコア以外の部分を書き上げながらプログラム完璧ものにしていく。

書き間違えさえなければ正しく動くと知っているプログラムを、上から一行ずつ書いていくプロセスとは正反対だ。



また、以下で述べるようにエラーが発生した場合デバッグ作業は非常に重要であるだが、そのための作法写経から学ぶことができない。

なぜならば、写経中にエラーが発生した場合教科書自分で書いたプログラム間違い探しをまず一番最初に行うからだ。これはプログラミングに関する作業ではなく、むしろ間違い探し絵本とにらめっこしているに近い内容である

それでは、デバッグ方法言語モデルを作るとても大切なプロセス経験できない。

ゆえにそのようにして完成したプログラムもおそらく正しく動きはするが、得られる経験値は驚くほど低いはずである



とは言え、いきなり自分で書けと言われても書けないと思うので、小さなプログラムを一旦は教科書通り写し、その後自分なりに改変していくのがよいと思う。この場合写経にはほとんどが意味がないと思った方がよい。"自分なりに改変する" というプロセスこそ意味がある。



さて初心者が陥りやすい部分については説明したので、

今度はどのように "言語モデル" を自分の中に作っていくかについて説明する。



1. エラーをたくさん出す

初心者エラーを出さない様にと慎重にプログラミングしようとしがちだ。

はっきり言うと、それは間違ったプログラミングスタイルだ。



特に最初のうちは、エラーをなるべく多く出した方がよい。

なぜならば、エラーを出すごとに、その言語の新しいルールを1つずつ学んでいくことになるからだ。



PHP で例えると、

printf の書式だとか

文末に付けるセミコロンだとか

function はネストできないとか

変数には $ を付けなければならないだとか

グローバル変数関数の中で使う場合は global 宣言するとか

などである



初心者のうちは一切上のようなルールは知らないはずだからエラーを全て踏むかもしれない。

例え今回作っていたプログラムエラーを踏まなかったとしても、回数をこなしていけばいくつかエラーに遭遇するだろう。



しかし、それでよいのだ。



エラーを修正することの繰り返しの中で、その言語モデル自分の中に出来てくる。

そのようなトライアンドエラーを繰り返えすことで、"言語モデル" は文字通り体の中に染み込み、プログラムだんだんと書ける様になっていく。



おそらくこれはは自転車に乗れるようになるプロセスと似たようなものだと思う。

誰しも最初は上手く走れずに転んでばかりいるけれど、何度も何度も転んで起き上がってを繰り返しているうちに少しずつ多くの距離をこげるようになっていくだろう。

そして最終定期には、難なく自転車を乗りこなせるようなっている。



プログラミング言語を学ぶ時も同じである

最初は何度やってもいろいろなエラーが出てくる。

それらのエラーを地道に1つずつ潰して間違いを訂正していくうちに、少しずつ多くの行数の複雑なプログラム書けるようになっていく。

そして最終的には、自由にプログラミング言語を使いこなせるようになっていることに気付くだろう。



自転車も本を読んだだけで乗れるようにはなれないのと同じで

プログラミング言語も本を読んだだけで出来るようになれると思わない方がよい。



それらはトライアンドエラーの繰り返しの中でしか得ることはできないし、誰かから教わる類のスキルでもない。


そして、プログラミングを行うからにはエラーとは一生付き合っていかなければならない。

早めにそれに気付いて受け入れる必要がある。



2. デバッグの仕方を覚える

さてエラー重要性については上で強調した。

実際にエラーに遭遇した時に大事なのはエラーに遭遇した時にいかにその原因を突き止めるかだ。


期待しない動作をした時のデバッグという。


まずいちばん基本的で一番重要デバック方法printf デバックである。これをまず出来るようにする。

怪しい変数をとにかく printf で出力し、変な値が入っていないかを確かめ方法である


僕が常々許せないと思っていることは、初学者向けの書籍にはデバッグ重要性やその具体的な方法論が非常に重要であるにも関わらず、それについては解説すらされていないことである


初心者からこそ、デバッグ方法論や開発環境をきちんと整えるべきである


ほとんどの言語処理系では、デバッグ作業を支援する機能提供している。


からなければ、"言語 デバッグ方法" でグーグル検索してみればよい。


例を挙げると、



C言語だったら、gdb

PHP だったら Xdebug

Ruby だったら pp モジュール

Schemegauche)だったら #?= デバッグ

javascript だったら firebug



言語はいわゆる"定石"と言われるデバッグ方法があるはずで、それらを検索し習得すること。

これは無益時間を過ごさないためにも本当に重要な要素なので、面倒くさがらずに開発環境を整えや方法論をマスターすること。




3 小さく動かして確かめ

最初の内は、基本的にプログラミングする時は小さな部品に別けてから1つずつ確かめながら作る習慣を付けるようにする。


その理由は簡単で、人間は正確無比に物事を進めるのは苦手な一方で、プログラミングでは正確無比に物事を進めることを要求されるからである。そのため、大きなプログラムを一度も実行せずに作成し、一気に確かめようとするとまず間違いなく正しく動作しない。


そして厄介なことに、大きなプログラムを作ってしまうとどこに問題があるのか切り分けすることが困難になるので、ますますデバックが難しくなってしまう。


そのためまず小さく作って小さく確かめ部品を組み合わせてプログラムを作っていくことが大事になる。


一般的に言って、どんなに熟練したプログラマーであろうとも、一つのミスもせずに一定以上の大きさのソフトウェアを作り上げることは不可能である。そのため、ミスエラーはある程度発生することを前提に、少し作っては実行して確かめる、というサイクルをたくさん回す習慣を付ける。


ソフトウェアは一行書き上げた瞬間から指数関数的に複雑性が増大し、気付いた時にはどうにもならなくなっていることも多い。そういう時は思い切って一から作り直すという選択肢検討してみるべきだ。


"Small is Beautiful"


これは非常に有名な unix (という OS)の設計理念である

unix開発者は様々な失敗経験から、このようなソフトウェア開発のベストプラクティスを学んだに違いない。


まだプログラミング経験の浅い人も、これから偉大な開発者経験から学ぶことができるはずである。"Small is Beautiful"。小さく作って動かすこと。




4 Google を使い倒す

先ほどから何度も書いてあるように、プログラミングする上ではエラーとの付き合い方が非常に重要になってくる。


おそらく何らかの上手くいかない場合は何らかのエラーメッセージが出るはずだ。

原因がどうしても分からない場合は、エラーの文章をそのままコピーして検索してみる。そうすると、おそらくエラーの原因と対策方法などが表示されるので、それを足がかりに再度挑戦する。






現実プログラミングは、どんなにスキルが伸びようとも、いつも上手くいかないことばかりだ。それこそ、何をしてもエラーが出てくるし、何をしても上手く動作しない。だから僕は初心者のうちで一番大事能力とは、実は "忍耐力" だろうと少しばかり思っている。


でも悩んでるのはあなただけではなく、おそらく全てのプログラマーが通ってきて道だ。


そして、自分の思い通りに動くプログラムを見た時程うれしいものはない。

ぜひ初心者の人はこれを読んで少しでもプログラミングが出来るようになればと思っている。







2012-07-15

Twitterで知り合った自称Geekの子HTMLの話をしてみたら

なぜかLINEでのやりとり。このあとTwitterでblockされた。

A hi
B yeah
B 学校祭わろた
A おつ。
A 打ち上げ的なものはないの?
B ない
B 学校祭中
A ああ、把握。わろたがおわたに見えた。
B 学校祭ェ••••
B パソコン部の展示なう 誰もけえへんやん
A なるほど
B パソコン部だけ学校雰囲気じゃねーww
A そんなもんや…
B あっちで音ゲー こっちでぽけも
B 君もパソコンかい
B 友達こねーくそわろ
A んにゃ、高校のときは※※と〒〒やってたねえ。
B 学校祭の新しい形ですね
B 学校祭なんてお客さんが楽しむもので、生徒が楽しむものではない、生徒は楽しませる側です
A 僕んところの高校のパソコン部とか何やってたんだろうねえ。
A Twitterとか見てると灘校のパソコン部展示とかは相当盛り上がってたみたいだけど。
B 君は神学校出身かい
B 灘高は秀才から
A いや、ずっと公立だね。
B つくこま のパソコン部もハイレベルやで
B 偏差値は?
A 僕の偏差値? 学校入試偏差値?
B 私は地方進学校(笑)です
B 学校と君の
A 同じく地方進学校ってとこだね。もっと田舎から高校入試は大した競争はないんだけど。
B 数学できんねやろ?
A 入試偏差値はさすがに新聞か高校入試情報誌バックナンバーあたらんとわからんなあ。
B というか君札幌じゃん
A んにゃ、札幌じゃないけど。
B 北海道??
A 北海道
B むろらんさかえ?
B くしろちょうりょう
A ノー。
B かいせい?
B あさひがおか?
B 東西南北
B
B どれ?
B 帯広はくよう?
A ちゃうねん。
B どこ?
B 西?
A 柏葉とか〒〒強かったなあ。
B W
B 君×高?
A No.
B 俺×高www
B わろたqwwww
B ×高わろたwww
B ×高わろわろわろたwwww
A なにがおもしろいwwww
B 君は?
A (そもそも高校生ではないんだけどね…)
B 中学生大学生
A 大学出てるよ
B 出身高どこ?
B 北海道ではないの?
A △△。
B もれ札幌×高。知ってる?私服やで!
B △△?
A 私服やで。
B △△高校??
A yes.
B ▲▲系?
A とは
B 画像
B 偏差値67わろた ●●県かー
A それ●●の男子校な。
A ●●の△△はたぶん私服じゃないぞ
B ●●神やな
B 何県?
A △△市知らんのか…
B 画像
B しってるで!
B 理数科?
A 普通
B なんで私服
B
A なんでって言われても、校則制服がないからだけど。
B わろた
B この話やめよ
A ( なんでいきなり学校の訊問から始まったんだ…? )
B Htmlの話にかえよう
A うむ。
A で、HTMLって何さ?
A 何だと思う?
B はいぱーてきすとまーくあっぷらんげーじ 絵や歌と一緒で自分表現するもの
B メディア
A ほむほむ
A 「まーくあっぷ」って何?
B 表現メディアの一種
B 記すこと
A んー
A じゃあ、ハイパーテキストは?
B 特殊効果付属された文字列及び画像
B 及び記号
A 特殊効果とは?
B 色つき、アニメ
B この問答に終点はあるんですか?ゴールがみえてますか?
A ん、取りあえずHTMLがわかってないと話にならんしね。
A 満点はつけられないけど及第点じゃないかなー、と。
B はいぱーてきすと はネットにつながるやつですか
B てへぺろ
A ネットにつながるやつ」が正確な表現かどうかはともかくとして、それはハイパージャンプハイパーテキストの特徴。
B ハイパーテキストとは
B 模範回答
B
B なんや
B なんやなんやなんややややややややややややや
A ハイパーテキスト
B んーなるほど
A 要するに、ただのテキストを超えてる。
B ○○高校のクズがおるで
A って概念
B 後ろに
B それで
A でだ、そこで
A HTML5って何?
B なんや
B テキストを超越したもの創造するための道具
A No.
B なんや
B プログラミング言語
A そういう名前の「マークアップ言語」ってだけの話なんだけど。
A プログラミング言語ちゃうねん。
B しっとるわ
B でいいたいことは?
B 要旨はなんや
A マークアップ言語」ってことが重要
B はい
B それで
A 言語であるからには規格があって処理系がある。
A ってことはおk?
B うん
B 規格?
A 規格。
B 処理系? 説明せぇ言われても説明できない言葉やわ
B おしえで
B おしえてー
A 要するに、"print A" って文字列を与えたら "A" って出力するような仕組。
B それが処理系
B きかくは?
A ざっくり言うとそう。
A 言語言語として成立するための決まり
A さっきの例だと "print A" なら「Aを出力しろ」という命令であるべし、みたいな。
A HTML場合は基本的には要素と属性定義になってる。
B あーわかります
B いえーす
A 要素と属性おk?
A element と attribute 。
B 要素 属性width height
A おk
B 要素が親 属性が子
A それはちゃうねん。
B じゃあなんや
A でもそれは脇道だから置いておく。
B いいす
B いえす
B そして
B から
B からの?
A てっとり早く言うなら、HTML5定義されてる要素の集合に font や center は入ってない。
B ふむ
A 集合は?
B じゃあそれらはなんや
B ドモルガンの法則
B 要素の集まり
A おkおk。問題ないね
B なめてんのか、て感じですよ
A で、つまるところ何を見て font とか center を使ってんのよ、ってことになる。
B しらん
B 理由なくても動くから
B
A ってことは、HTML5を知ってることにはならん、と。
B た(^-^)/な
B だね
A "理由なくても動くから" niceだね!
B だろぅ?
B ワイルドだろぅ?
B で使っちゃダメな理由があんの?
A さっきの話に戻すと、HTML処理系って何?
A いっぱいあるよ!<だめな理由
B 命令の内容とそれに対応する文字
A ノー。
B なんや
B ユーザーの命令に対してのコンピュータが処理する内容
A 入力に対して応答する「仕組」が処理系
B しすてむ
A nice
B 入力に対して応答する仕組み=処理系
A 日本語の「系」は "system" に対応する。
B おつす
A で、HTMLを与えて、それをよしなに処理してくれるシステムって何?
B 処理系
A 具体的には?
B Html処理系
A HTMLの有名な処理系は何?
B html5
A それは規格。
B やー
B こんぱいらー?
A コンパイラ処理系
A (の一部
B Html処理系なんや
B コンピュータ
A 大雑把すぎる
B cpu
A ノー。
B めもり
B なんやねん
A ノー。
B Os
B web
B ブラウザ
A iPhoneにもWindowsにも処理系が入ってるからWebが見られる。
A 正解。
B プレインストールされてすか
A されてるね。
B なるほどね
A HTMLの有名な処理系は何?」の模範解答は InternetExplorerとかMozilla FirefoxとかOperaとかGoogle Chromeとか。
B
A で、どうして規格を守る必要があるのか、の話。
B ブラウザ名前をあげればいいんですね
A それはもう終った。
B exactly
B
B
A HTML5では文書の先頭に って書くことになってるけど、これはどういう意味か。
B 宣言
A DOCTYPE宣言
A 宣言してるのに規格守らなかったらだめじゃん
A やーいうそつきうそつきー、ってことになる。
A (まじで
B どういうこと
B Doctype宣言してんのにcenter、fontを要素として使うのはだめだということですか?
A HTML5の」宣言してんのにcenter、fontを使うのはだめー、ってこと。
B へー
A HTML 4.01 Transitional とかならおk
B 規格守らないとどういう弊害が?
A おkだけど、なんでそんな古いの使ってんのや、ってことになる。
A あらゆる意味でめんどくさい。
B
B 規格守らないと誰か困るの?
A ユーザも困るし、処理系を作るひとも困る。
B なんで?
A 困ったちゃんは絶滅しないから有名な処理系は古い規格をサポートし続けることになるのは確定的に顕かなんだけど。
A たとえばちょっと処理系自作しようとしたときに規格を守ってない文書に当たると、例外的な処理をしなければならなくなる。
B 新しいhtmlの規格がでても 古いバージョンサポートをやめられないのですか
A そんなことをしたら、君のページを表示できるブラウザがなくなるよね。
A (HTML5サポート外の要素を使ってるから
B なるほど
B center、fontに変わる要素はなんや
B 何を使えばええんや
A そもそもそれを要素で指定するのがナンセンスである、って話になってくる。
A まり中央揃え」とか「フォント」とかって意味の要素がナンセンス
B 最初Css使ってたけど他人のコードよんでfontていうやつ見つけたんで使ってみた
A 「他人のコードよんで」←まちがい
B csscolor: ;
A 「規格書を読む」←せいか
B 辞めてfont color使うことにした
B 他人のページのソースコード読んででええやろ
A 赤の他人はだいたい間違ってる
A (僕の言ってることも間違ってる可能性があるから規格書を読むべき
B なんや
B 表現が間違ってるわけじゃねぇんだよな
B そういえや
B 規格書をよめってことか
A 暇なときにね
A html5.jp とかで良い。
B web
B なるほどね
B 偏差値nn
B
A ?
B 君の偏差値は??
A さあ
B 教えてや
A そもそも偏差値の基準とは
B 模試偏差値とか教えて
B 偏差値の基準は???
B 偏差値の基準?なにをいいたい?
A 模試って言われても高校出て何年も経ってるから数値自体に何の意味もないんだが。
B 君は賢いかどうか知りたいだけよ。それを知るために偏差値は聞きたい
B はを
A 僕が賢いかって言われたらそりゃ賢くはないねえ。
B 俺より?
B プログラミング大会とかでたことある??
A 偏差値が良ければ賢いって価値判断がそもそも相当賢くない気がするんだけど。
A プロコン趣味程度にもやってないね
B ぉーわかってないね
B 賢い奴は、学校勉強くらいできるのよ
B 学校勉強程度はってことね
A さっきの偏差値nnって何の数字?
B プログラミング技能偏差値関係ねぇはずだけど、優秀なプログラマーは有名大出身ばっかさ
B ん?
B んとね 君の高校の偏差値
B 今のね
A 把握。
A 「優秀なプログラマーは有名大出身ばっか」の統計的根拠はあったりする?
B ない。俺が感覚的に感じた
B アメリカ
B れいおじー
A 「実際に会った優秀なプログラマ出身大学の関係」とかでも良いんだけど。
B レイ オジーマークザッカーバーグビルゲイツポールアレン
B 下村努
B スティーブ ウォズニアック
A おお、そりゃあ有名人だ。
A で?
B こいつら全員アメリカトップ高校ばっか
B なんや、小さい頃から理系天才エリートか、。?
A そもそもその世代は有名な大学しかまともな計算機がないんだけどね
B 日本Googleグリーの幹部は東大東工大京大情報工学ばっか
B なんだ、理系エリート
B なんや
B そういうことかー
B 所詮 有名企業高学歴巣窟か、
A ってことで、勉強がんばれ
B 君はこの事実をうけとめられるか
A そういうもんだからねー
B 学生のうちは勉強をすべきなんだ.......
B から勉強を.........!!!!!!
A するべき。
A 僕はまともに学校勉強はしてこなかった人間からねー
B しろわ
B しろやいま
A んー、いまさら大学入試受ける予定もないしねえ。
B 君どんな仕事してんの?
A 自宅を警備するお仕事をしてるよ☆ ってTwitterのbioにも書いてる
B ニート
B
A こんな夢見がちな大人になっちゃいけないよ☆
B 仕事する予定は?
A ないない
B しろや
B 家でなにしてんの?
A 勉強
B なんの?
A SICP
B 親が生活費だしてんこ
B だしてんの?
A んにゃ、自分お金でだけど
B ふりーたーか?
B アルバイトはしてる?
A ないない。アルバイトなんてしたら自宅を警備できないしね。
A そんな大人になっちゃいけない
B 自分の金てなに?お前が稼いだ金?
A いえーす
B どこで?
B 働いてないのに
A 不思議だ…
B お前なんやねん
B 何者やねん
A 自宅警備員
B ばか?
A Twitterのbioに書いてる以上でも以下でもない感じ。
B ごみ
B 社会ゴミ
A 少なくともいまの君よりは計算機科学に詳しい、ってことでおk?
B おーけー
A ってことで、こんな社会ゴミなんか秒速で追い抜いてみせろ、ってことでひとつ
B まあ俺がお前の歳だったら、お前より知識あるがな。俺×高やし、北大いくし
A おーすごいすごい。
A さっきの学歴を持ち出すなら北大じゃいろいろ物足りない気がするけど。
A 素直に京大とか東大とか行っとけ
A 北大教授京大東大ではしてない研究をしてるのが居てその分野を專攻したいー、とかなら別だけど。
A 知ってる範囲の北大学生ものすごいのって、□□□□出てて高校時代から一人でばりばりプログラム書いてる、とかそんな感じだから
B まあお前よりは高等だから
B こめん
B ごめん
A 僕より偏差値高いだろうってことは知ってるから、いまさら確認することじゃないなw
A ただ、具体名は避けておくけど、GoogleとかMSだけに優秀なプログラマが集まってると思ってるなら、それは間違ってるねー
A 高学歴=優秀なプログラマ」が真なら、国内メーカーはどうしてこんな惨状なのか…
A 僕がこの2年くらいで会ってきた、そこそこ多めな数の高校生とか大学生たちから見るに、優秀な高校生が良い大学入ってるってのはおよそ間違ってないね東大とか京大とか筑波とか東工大とか。
A s/優秀な高校生/優秀な高校生プログラマ/ ね
B そう吠えんな
B ごみなんだからお前は
B 情報オリのメダリストは全員高学歴だろ
A それはまったく否定しない
B 高学歴=優秀なプログラマーはいってないよくず
B 優秀なプログラマー高学歴であることが多いてことな
A で、情報オリンピックとか挙げちゃうとお前はどうなのよ、って話になってくる。
B それ俺より馬鹿クズがいうセリフじゃないぞ
A 情報オリンピックメダリストになりたいの? 高学歴になりたいの?
B 最終目標金持ちやね
B 金持ちになるにはい大学いったほうが確実だろ?
B プログラミング興味本位かな
A 確実って言うには出身大学は要件としていささか貧弱な気がするんだけど
B 金持ちになるには、いい大学いくことが近道
A 僕は読みたい本が買えるだけの儲けがありゃ良いか金持ちとかあんまり関係ない話やね
B くずめ
A 上位の大学の方が平均年収が高い、とかって水準の話ならまったくその通り。
B 金持ちなれねぇやつが かっこつけんなくず
A 君が儲ける金は君のものだし、僕が儲けた金は僕のものから、まったく関係がないよね
B きも
B くずだw
B お前は負け犬
B 可哀想に
A 別に君のおこぼれに与ろうってことは期待してないから、君が勝っても負けてもどうでも良いんだけど。
B くずめ死ね
B お前らはくずなんだから今すぎ死ね
A 今すぎ
B お前みたいな奴が日本の足引っ張んだよくずwww
A 内心蔑みながらも日本未来を案じるさまは立派です。

2011-09-30

ネット業界に見る理系文系価値

現在国内外インターネット企業が頑張っている。

やっぱ技術

ただ最近の傾向として、技術力がある会社が強いなーというのがあると思う。

特にGoogleFacebook

ラリー・ペイジセルゲイ・ブリンエリック・シュミットという計算機科学スペシャリストがトップにいて、創業期から理系天才達を採用してきた。

もはや学者研究資金のために会社をやって資金を調達してるんじゃないかってぐらいのイメージ

Facebookも圧倒的な技術ですごいスピードで成長してきた

理系文系

これは愚問だし大雑把すぎるカテゴライズなので先に謝っておく。ただ、ネット業界ってやっぱ理系の人が強いんじゃないかと。

技術があってこその業界だし、そう考えると数学的思考が有利になると思う。

プログラミング数学はあまり関係ないというけど、理系の人の考え方は絶対にプラスになる。

それになんだかんだ理系の人の方がプログラミングを始めるきっかけが多い。

これらは文系自分が周りの状況を含めて実感してる。

そう思うとネット業界において文系メリットってなんなんだろう。

文系ができて理系ができないことってある?

自分上司バリバリ理系だ。

大学では計算機科学を主に学んでいた。

プログラマーとしても凄く優れている。

それなのに営業なのだ。しかもトップ。

まぁMBA公認会計士を持っていたりもするのだが、何故プログラマーなどの技術職に行かないのかという経歴と能力

彼を見ていると理系でも文系仕事できんじゃん!って思ってしまう。

文系は営業職などしかない。しかし、理系は本職のプログラマー(これも語弊はあるが)がある上に営業もできる可能性がある、と。

戻れるなら・・

自分は営業が向いていると思うし、仕事は順調だ。

しかし、自分でつくってみたいという思いもあり技術勉強している。

からかわからないが、プログラマーに凄く尊敬の念を抱いてる。

文系プログラマーもいるだろうが、やはり理系出身のプログラマーが圧倒的に多い。

そういうことを思うと、過去自分にちゃんと理系分野勉強しておけよと言いたくなる。

プログラム理系文系関係無い」「文系プログラマーもいっぱいいる」という人はいるだろうが、今回はわかりやすくそういう分け方をしてみた。

まぁ自虐的なんだけど・・ただ自分は諦めたわけではないので、これから勉強していこうと思っている。

2011-09-15

コンピュータ基礎理論ハンドブック2 形式的モデル意味論」の目次

第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. 関連する重要な文献

2010-09-30

http://anond.hatelabo.jp/20100930003333

とっくに自覚してんじゃん。仕事ってのは意味のある仕事であるうちは嘘で、単に食うための無意味仕事になってからが本当なのかもしれないね。でも、じゃあ、本当に仕事を変えてやっていけるか?給与の額にかかわらず、辛いのは変わんないかもよ。


職場に Halabi と Stevens と Rose 持ち込んでも誰もその中身には興味がない時代だよ。知識つけたって評価されない仕事が増えて苦しくなるだけだから。つまんないから ACM の個人会員になってみたけど、なんかCACMって毎号毎号計算機科学未来はあるのか?みたいな記事が1つは載ってて、げんなりして、更新、やめた。


まあ、G社が潰れて、抱え込んだ人材ノウハウバーゲンセールをやる日までこの業界進歩が止まるんだろうなと思っている。

2010-09-07

IT系とかそれ以外のスキル列挙するから何ができそうか教えて欲しい

色々教えてください偉い人。

自分で考えろってのはご尤もですが、色々な方の意見が聞いてみたいのです。

純粋Java(max5000行程度)

Struts(ver2じゃないほう)上でのJava(max2000行程度)

perl(max7000行程度)

c/c++(ちょっと)

Haskell(ほんの少し)

VisualBasic.NETじゃないほう)(ほとんど忘れた)

HTML/CSS(セマンティック厨)(HTML5勉強中)(バイトWEBデザイン経験有)

javascript(簡単なものなら)

XML/XSL自作プログラムI/Oに利用)

MovableTypeCMSとして利用。ちょっとした企業サイトレベルくらいのものの構築。簡単なプラグイン作成とかも)

Apache(セットアップと最低限の設定くらい)

Tomcat(同上)

LinuxCentOSUbuntu。セットアップとちょっとした設定程度)

IPA資格ソフトウェアネットワークデータベース

Tex論文プレゼンテーション作成

AdobeDTP製品(CS2)(雑誌編集経験有、ただし学生レベル

Oracle10g)(Bronzeレベルの知識とちょっと触ったことがある程度の経験

postgreSQL(ちょっと触ったことがある程度)

会計関連の知識(日商簿記2級)(大学管理会計をかじった)

数学系の知識(論理とか集合やらの基礎。大学計算機科学をかじった)

印刷物/WEBサイトデザイン(独学だけどそれなりに。一般人よりはそれっぽいデザインが作れるかと)

・文章/記事作成(取材→記事執筆。文章校正経験有)(随筆みたいのは無理)

漫画ゲームが大好き

2010-08-15

http://anond.hatelabo.jp/20100815183855

純粋数学にはあまり興味ないです。興味の方向は自然科学ですね。

数学の中でも解析とかそっち系の分野なので、計算機科学と相性が良い離散数学にはやっぱりあまり興味が無いんです。

ログイン ユーザー登録
ようこそ ゲスト さん