サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
大谷翔平
u1roh.hatenadiary.jp
この記事は F# Advent Calendar 2014 - connpass の18日目の記事です。昨日は teramonagi さんの FsLab JournalでReproducible Research(レポート)を簡単に作りたい - My Life as a Mock Quant でした。 分をわきまえずに継続モナドとかいうヤツについて書きます。 ちょっと前のことですが、継続(continuation)の概念がストンと腑に落ちる瞬間を味わいまして割と気持ち良かったので、その感動を忘れないうちに書きます。まあ、経験上最初の「分かった!」はぬか喜びであることが多いので今回も誤解している可能性はありそうですが、多少の間違いはあっても感動の熱さが残っているうちに書かないと書く気が失せてしまうこともやはり経験から分かっているので、勇気を出してこの機会に書いてみようと思うのです。 なお、私
この文章は先日中途で入社されたSさんに向けて書いています。SさんはC++とJavaの経験はあるが、C#の経験はないそうです。 という事情でして、C++やJavaと対比しながらC#を説明すれば手っ取り早くC#を覚えて頂けるかな、などと思うわけです。しかしながら私自身C++は最近書いてないし、Javaに至っては10年以上前に少し触ったことがあるだけ、という状態。とりあえずJavaとの比較は諦めます。C++についても全くもって正確な記事が書ける自信がないことをお断りするとともに、間違ってたらぜひツッコミよろしくおねがいします>< (あ、あと C++11 は分からないので、C++11 以前の C++ を前提に書いています。SさんもC++11に詳しいわけでは無さそうですし…) class と struct C++ では class と sturct に本質的な違いがなく、単にメンバがデフォルトで p
F# Advent Calendar 2013 15日目の記事です。 ヘタレなので大したことは書けないです。初めての Advent Calendar でやや緊張気味。 ステートレスとステートフル 現在 F# を実戦投入してます。OpenGL を利用した 3D CAD 系アプリケーションの受託開発です。WPFによるスタンドアロンなデスクトップアプリケーションとなります。下図のような構成となっています。 ViewModel を C# にしたのは深い意味はないです。ViewModel は F# による恩恵が大きい部分ではないだろうという判断と、いきなり全面的に F# にするのに私がビビっただけです。次の機会には ViewModel も F# にするかもしれません。 さて、作っていく過程で気づいたのですが、Model部分は更に次のような2層に別れる感じです。 関数型プログラミングでは状態を持たない
数々の数学者の人生を狂わせたリーマン予想というものがある、ということは以前から知識として知ってはいたのですが、とあるキッカケでなんとなくWikipediaで調べてみました。 ゼータ関数を次のように定義する。 1859年にリーマンは自身の論文の中で、複素数全体 (s ≠ 1) へゼータ関数を拡張した場合、 ζ(s) の自明でない零点 s は、全て実部が 1/2 の直線上に存在する。 と予想した。 リーマン予想 - Wikipedia あーそういえば数学ガールでバーゼル問題は読んだなあと思いつつ、難しいことはサッパリ分からんが正月休みのヒマを埋めるべくとりあえずゼータ関数を可視化してみたら面白いかもしれんと、プログラミングの書き初めを始めたわけであります。 まずゼータ関数に出てくる数列を次のように定義します。(あ、C#ね) static IEnumerable<Complex> ZetaSeq
なんか似ているようで異なる技術。 ゲームで出来てるのにどうしてCADやCAEでは出来ないのか、などと言われることがあってみたり、自問自答してみたり。 ちょっと整理してm・・・いや、書き散らかしてみる。整理はしてない。 IK (Inverse Kinematics; 逆運動学) ゲーム/CG系でいうIKと、ロボット工学系でいうIKは、似ているようで結構違いがありそう。 各関節の角度(足の付根、膝、足首など)からつま先の位置を求めるのがFK(Forward Kinematics)、逆につま先の位置から各関節の角度を求めるのがIK(Inverse Kinematics)。 MMD(MikuMikuDance)のモーションデータ(VMDファイル)を再生するプログラムを組んだことがある。キャラクタの3Dデータ(PMDファイル)をモーションデータに沿ってアニメーションさせるプログラムだ。 MMDでは下
C# で yield return に出会ったとき、まず最初に理解の妨げとなったのは yield という単語の意味だった。 当時の僕にとって、yield といえばそれは「降伏する」という意味だった。その理由は僕が工学部機械科出身で材料力学を習ってきたことと関係がある。材料力学には「降伏応力」という概念があって、これは英語で yield stress というのである。 そんなわけで、yield return を知ったときは大いに戸惑った。降伏する、ではサッパリ意味が通じないではないか。当然、辞書を引くことになる。 〔農産物や鉱物が〕産出する 〔努力や投資によって〕収益が出る、利益が挙がる 〔戦いなどで相手に〕降伏する、屈服する http://eow.alc.co.jp/yield/UTF-8/?ref=sa 辞書を引いても、ストンと腑に落ちる訳は見つからない。強いて言えば「産出する」だろうか
ふと突然、「不便さ」こそデザインされるべきだ、などという思考に頭が支配される。そんな今日の昼下がり。 紙の本は不便だ。検索できない。ハイパーリンクもない。でも、だからこそ目の前の文章に集中できる。活字の世界に入り込むことが出来る。小説に没頭することが出来る。 心をシングルタスクにすることができる。 電子書籍のデザインはどうあるべきか。問題は紙のような物理的な制約がないことだ。どこまでも機能が追加できてしまう。どこまでも便利を追求できてしまう。しかし、それは良いデザインといえるのか。 検索機能をつければ、その検索機能は画面の面積を占めるだけではない。読者の心にも入り込む。「検索する」という選択肢が入り込む。もちろんそれは便利だ。だが時として、集中の邪魔となる。読書体験の質を下げる。 温泉が好きだ。都会の喧騒を離れ、お金を使ってわざわざ不便な田舎の温泉宿まで足を運ぶ。不便だからこそ、いいのだ。
世の中にはスパゲッティなソースコードが多い。これも一種のピーターの法則かもしれない。 ピーターの法則とは何故世の中には無能な奴が多いのかを説明する法則だ。ある人がある職能で優秀と認められたとする。その人はきっと昇進するだろう。昇進後の職能でも優秀と認められれば、きっとその次の階層に昇進するだろう。こうして昇進を続け、あるときその人に向いていない職能にぶつかり、そこで無能と判定され、昇進が止まる。つまりその人は自分に向いていない職能に留まり続けることになる。こうして世の中は無能な人材で埋め尽くされるというわけだ。 これをソースコードに当てはめてみよう。ソースコードが綺麗に書かれていれば、機能追加においてベネフィットがコストを上回る可能性が高い。従ってソースコードが綺麗であるかぎり機能追加は続くだろう。しかしいつかはソースコードが乱れ、機能追加に限界が来て、進化が止まる。逆にいえばソースコード
このページを最初にブックマークしてみませんか?
『u1roh.hatenadiary.jp』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く