タグ

ブックマーク / nishiohirokazu.hatenadiary.org (19)

  • 「正規表現技術入門」はいい本だ - 西尾泰和のはてなダイアリー

    著者の新屋さんから技術評論社の「正規表現技術入門」を頂きました。 これはいいですね。特に第2章で語られている、正規表現がどうやって生まれてきたかという話がよいです。僕も拙著「コーディングを支える技術」の続編に向けて、正規表現の歴史を書こうとしたことがあったのですが、僕が書こうと思っていたもの以上によいものに仕上がっています。しかも20ページとコンパクトにまとまってて、もう、僕がこれに関して書く必要はないなぁ、とうれしいようなさみしいような。パイプとgrepの関係は知らなかった、面白い。 第1章で60ページぐらいで正規表現の基的なことをおさえてくれているのもよいところです。正規表現を使う必要のあるプログラマはみんな第1章だけでも目を通しておくとよいのではないかな。 正規表現がフォーマルにはどう定義されているものなのか。この話題は、コンピュータサイエンスを大学で学んだ人にとっては常識の範疇

    「正規表現技術入門」はいい本だ - 西尾泰和のはてなダイアリー
    nanakoso
    nanakoso 2015/05/19
    フクロウ本よりよさげ
  • 書評:アンダースタンディングコンピュテーション - 西尾泰和のはてなダイアリー

    監訳者のささださんから「アンダースタンディング コンピュテーション―単純な機械から不可能なプログラムまで」を頂いたので紹介。 「プログラムの『意味』とは何か?」という抽象的な問いに真っ向から挑む。プログラムの「意味」には、「それによって計算機がどう操作されるか」で表現する方法と、「それを別の(もっとシンプルな)言語に変換するとしたらどうなるか」で表現する手法とがある。書ではこの2つの手法があることを解説し、それぞれの手法について深堀りしていく。 「計算機がどう操作されるか」路線では、もちろん次に「『計算機』って何だ?」という問いに挑む必要性が出てくる。まずは能力の劣った計算機である「決定性有限オートマトン」から初めて、それが正規表現というある種のプログラミング言語とどういう対応の仕方をしているのかを解説するのにまる1章割いている。このストーリー仕立ては面白い。 その後、有限オートマト

    書評:アンダースタンディングコンピュテーション - 西尾泰和のはてなダイアリー
  • 数学的帰納法は帰納ではない? - 西尾泰和のはてなダイアリー

    エンジニアの学び方」第3章の帰納の例で数学的帰納法を例にあげているのですが、「数学的帰納法は帰納ではないのでは」という質問がありましたので解説を書きました。 なぜ「数学的帰納法は演繹」という主張が生まれたのかに関して id:shuyo さんとの議論を通じて僕は「ペアノの公理が導入されたことで、それ以前の数学的帰納法で帰納が使われていたステップが『自然数の定義』で置き換えられて演繹だけが残ったから」という理解に到達したのでペアノの側の主張も併記しておきました。 参考文献:科学と仮説 (岩波文庫)

    数学的帰納法は帰納ではない? - 西尾泰和のはてなダイアリー
    nanakoso
    nanakoso 2014/08/06
    形式的には「帰納法の公理」の適用にすぎず公理の適用は演繹の1ステップ
  • 「10倍の生産性」をマフラーで例える - 西尾泰和のはてなダイアリー

    「プログラマは能力によって生産性に10倍の差がある」とかいうけどこれはプログラミングに限った話ではない。編み物未経験のXさんと既に何もマフラーを編んだ経験のあるYさんとで、マフラーの最初の5列ぐらいを編むのに掛かる時間で勝負したら、Xさんが編み方の説明を読んでる間にYさんは編み終わる。技術とはそういうもの。 技術によって確かに生産性が10倍変わることはある。しかしゴール設定が「マフラーを編む」ではなく「イケメンZ君の気を引く」なら、Xさんはわざわざ不利なマフラー作りで勝負する必要がない。例えば手料理のほうが得意ならそれでチャレンジすれば良い。こうして生産性の差は消滅する。これが専門化の罠。 Yさんが手編み能力を持っているせいで「手編みマフラー」という選択肢に固執してしまい、冷静な判断を失うことがあるが、残念なことだ。さらには手編み能力を持たないという理由でXさんを見下したり「手編みマフラ

    「10倍の生産性」をマフラーで例える - 西尾泰和のはてなダイアリー
    nanakoso
    nanakoso 2014/02/20
    そういう話はボスかクライアントに言ってくれませんかね
  • 量子将棋が面白い - 西尾泰和のはてなダイアリー

    量子将棋というゲームが遊べるようになったということで、さっそくプレイしてみた。ルールは簡単に言うと、すべての駒は量子的な重ね合わせの状態にあり、どう動かしたかによって駒の状態が収束する。王将に収束した駒を取れば勝ち。(追記: ルールの解説書きました: 量子将棋 Q&A) 2勝2敗で結構面白かったので流れ去ってアクセスできなくなる前に感想をメモ。 1回目(勝ち) 棋譜: http://shogitter.com/kifu/884 僕の戦略 駒の種別が確定すれば取れる選択肢が減る。ということは必要がない限り駒は動かないほうが良い。動かさなければいけないのであれば歩の振りをするのが一番可能性が狭まらない。 王将に確定した駒を取れば勝ちなのであれば、相手の「王将かもしれない駒」をどんどん取って行って可能性を狭めるべき。 感想 駒の上にマウスポインタを置くと可能性のある駒の種類が出てくる 飛車を取る

    量子将棋が面白い - 西尾泰和のはてなダイアリー
    nanakoso
    nanakoso 2013/10/28
    持ち駒を勝手に確定して相手の可能性を狭めるって戦法が面白い(追記:審判なしの軍人将棋っぽい)
  • 文字列の解析 その3: 正規表現の歴史 - 西尾泰和のはてなダイアリー

    第1回では文字列から特定パターンの部分を切り出すことがなぜ必要になるのか、そして第2回ではパターンが複雑になるとそれを実装するコードがとても複雑になるということと、その複雑なコードを人間が書くのではなくコンピュータに作らせる「正規表現」について学びました。 ここではその正規表現がどのように生まれてきたのか、軽く歴史を振り返ってみましょう。[1] (注:書きかけです) マッカロピッツのニューラルネット 1943年、Warren McCulloch と Walter Pittsの2人が神経細胞(ニューロン)の振る舞いをモデル化して、複数の神経がネットワークとしてどういう振る舞いをしうるかについての研究を発表しました。[2] 後のニューラルネットワークにつながる研究です。[3] この論文の中で彼らは、複雑なニューロンの接続関係を表現するために、独自の記法を発明しました。 (脚注[1] 今回の話は

    文字列の解析 その3: 正規表現の歴史 - 西尾泰和のはてなダイアリー
  • Haskell(GHCi)の:printが面白い - 西尾泰和のはてなダイアリー

    Haskellって、変数に束縛されている値が「評価されている」と「されていない」の状態を持っていて、それがグローバルにあちこちから共有されているから「どれくらいの計算量で終わるか」みたいな議論になるとイメージが掴めなくて困っていた。確認する方法があればいいのになぁ、でも、ないんだろうなぁと、諦めていたが、GHCiである程度できることがわかった。面白いじゃんこれ。 まずこんなソースコードを用意してみる。これは「リストを結合した時点で前半のリストは評価されるのか否か」を実験するためのコード。以前議論になったときに、僕の主張としては「前半を評価しないでも『xsの先頭1個と「xsの残りとysを結合したもの」のcons』を返せば良い。きっとその実装になってるだろう」というものだったのだけど、今までは挙動を観察する方法を知らなかったので議論止まりだった。 xs = [1, 2, 3] ys = [4,

    Haskell(GHCi)の:printが面白い - 西尾泰和のはてなダイアリー
  • 刺激の栄養失調

    人間の体が栄養を求めるのと同じように、人間の脳は刺激を求める。 事をとらなくて血糖値が下がりすぎると、体調が悪くなって行動をするのが億劫になってしまう。べにいくのも買ってくるのも面倒だからと、買い置きのお菓子をべたりしてしまう。一時的に糖分を取って空腹が紛らわせられるが、人間の体は糖分だけで動くのではない。多種多様なビタミンが必要だ。糖分だけ取っていたのではかえって体調が悪くなる。 脳も同じ。ある種の刺激が足りなくなると、「脳調」が悪くなって行動をするのが億劫になってしまう。外に出るのは面倒だからとtwitterやb.hatenaを見たりしてしまう。そこにあるのは確かに「新しい情報」という刺激だ。一時的に「脳の空腹感」は満たされる。しかし人間の脳は新しい情報だけで充足するものではない。多種多様な刺激が必要だ。 あった方がいいかもしれない「脳の栄養素」候補のリスト 歩く、泳ぐなど(リズ

    刺激の栄養失調
    nanakoso
    nanakoso 2012/12/12
    散歩のススメ アロマはいろんなもの食べてれば不要論を押したい(食いしん坊)
  • manに「cp -rは使うな」と書いてあった話 - 西尾泰和のはてなダイアリー

    cp -rでシンボリックリンクまで実体としてコピーされて困ったのでMacのmanを読んでいたのだが、そもそもcp -rってオプション一覧に載ってない。あれれ?と思って続きを読んでいたら互換性の章でstrongly discouragedと書かれていた。 COMPATIBILITY Historic versions of the cp utility had a -r option. This implementation supports that option; however, its use is strongly discouraged, as it does not correctly copy special files, symbolic links, or fifo's. 代わりに-Rを使うべきだそうだ。その場合のシンボリックリンクの扱いをどうするかはオプションで指定でき

    manに「cp -rは使うな」と書いてあった話 - 西尾泰和のはてなダイアリー
  • java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー

    ブログを書くまでがjava-jaですが、もう眠いのでとりあえず1行だけ書いて、あとは徐々に書き足す。 会場を無料提供してくれたグリーさん、ありがとうございます! 誰かが検査例外の話をするだろうと思って書かなかったら結局誰も言及しなかった、Javaのコミュニティなのに。 っていうか聴衆が100人もいると、もしかしてそもそも「検査例外ってなに?」って人もいたんじゃないか?「検査例外がOCPを壊す」とか「Liskovの置換原則のLiskov」とか通じてるんだろうか?とりあえず直和型が通じてないことだけはひしひしと感じた。 Twitterの自分の発言を転載しておく。 ちなみにZen of Pythonでも「エラーを握りつぶすな」と書いてあります 禅 of Python: 20の格言 「例外はそもそも何のため」ってところ、ざっくり省いたんだけどもそういうところのほうがニーズあったかね?? 「C#1.

    java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー
    nanakoso
    nanakoso 2012/06/28
    例外処理 [読み物]
  • 作りたいもの: 専門家の考える「よい状態」を実現に近づけるシステム - 西尾泰和のはてなダイアリー

    増井さんの作りたいものリストを作ろうというスライドを見て「確かに『いつかやる』リストに入れてるだけじゃ発展しないから、公開しても問題ないものは公開したらいいなぁ」と思ったのでやってみました。今回は早々に「自分がやることではない」と捨てて、リストに書いてすらいなかったことなのですが、公開するべきだと判断したので公開しておきます。 背景 今日の高木先生の日記(高木浩光@自宅の日記 - 「個人情報」定義の弊害、とうとう地方公共団体にまで) 現行個人情報保護法の「個人情報」の定義に不備があることを、これまでずっと書き続けてきた。「どの個人かが(住所氏名等により)特定されてさえいなければ個人情報ではない」(のだから何をやってもよい)とする考え方がまかり通ってしまいかねないという危機についてだ。 (中略) 私にできることはここまでです。ここから先は私の役割ではないと考えています。必要だと思われる方々で

    作りたいもの: 専門家の考える「よい状態」を実現に近づけるシステム - 西尾泰和のはてなダイアリー
  • gitチートシートv0.3 - 西尾泰和のはてなダイアリー

    http://www.nishiohirokazu.org/tmp/git03.pdf 今日はツッコミ役の人はお休み。

    gitチートシートv0.3 - 西尾泰和のはてなダイアリー
  • もっとよいGitチートシート - 西尾泰和のはてなダイアリー

    世の中にGitのチートシートはいくつかあるけど「Gitを知らない人に渡して最初に読んでもらうのに適したもの」が見つからない。チートシートじゃなくてチュートリアルと呼ぶべきかもしれないけど、とにかく印刷してA4で1枚になるくらいの資料が必要だ。Gitに触れた技術者が軒並み同じ落とし穴でコケるのは正しい状態ではない。「Gitには、indexっていう『コミットする前にワークツリーで行った変更のうちのどの部分をコミットするか整理するための場所』があるんだよ」とか「git revertはsvn revertと違っていきなりリポジトリに変更を加えるから気をつけて」とか最初に言ってもらえればもっとスムーズに進めたはずだ。 というわけでどういうチートシートが必要かに関して考えてみる。 登場人物 http://www.ndpsoftware.com/git-cheatsheet.html このチートシートが

    もっとよいGitチートシート - 西尾泰和のはてなダイアリー
  • 首都圏で引っ越す人が知らないともったいない情報 - 西尾泰和のはてなダイアリー

    「引越れんらく帳」にお客さまのお名前や引越先のご住所などを登録しておけば、電気・水道・ガスなどの引越に関する手続きで何度も同じことを入力する手間が省けます。他にも、NHK、クレジットカード、損害保険等々、主要な企業の住所変更などにも対応しています。 東京電力 引越コンシェルジュ すごい、こんなものがあったなんて。1回住所や電話番号、メールアドレスなどを入力したら、東京ガスや水道局は違うウェブサービスなのにちゃんとデータが引き継がれてさくさく入力できる。12分くらいで電気とガスの手続きを完了した。水道はお客様番号をメモしてこなかったので後でやろう。

    首都圏で引っ越す人が知らないともったいない情報 - 西尾泰和のはてなダイアリー
  • レバレッジメモ: プログラミング言語の概念と構造 - 西尾泰和のはてなダイアリー

    プログラミング言語の概念と構造。例の原稿を書く前にid:yuguiさんから借りたのに結局読みもせずに自分の記憶と勢いで原稿を書いてしまったのだが、今更読んでみた。っていうかこれはかなりいいだ。というわけで返す前にレバレッジメモ作成。 参考文献のリストの引き写しは今日はもう遅くて眠いのでまた今度。 マリナーI無人金星探査機は1962年7月22日発射から290秒後に爆破された。損失は1800から2000万ドルと見積もられる。notの欠落が原因である。 1950年代には効率のよいプログラムは人がマシン語を書くことでのみ作られると信じられていた。この信念にFortranが挑戦した。 最初はアセンブリ言語で書かれていたUNIXカーネルは1973年にプログラミング言語Cによって書き換えられた。利点は「新しいユーザとプログラム」「移植性」「可読性」 Ritchie[1978] *1 BNFのNaurは

    レバレッジメモ: プログラミング言語の概念と構造 - 西尾泰和のはてなダイアリー
  • 不完全にしてかなり言葉足らずな比較プログラミング言語学 - 西尾泰和のはてなダイアリー

    プログラミング言語は人が作ったもの。人は誤るもの。なので完璧なプログラミング言語は存在しない。 「人は誤るもの、しかし誤りに固執するのは馬鹿の所業だ。」(キケロ) プログラミング言語も、間違った設計をして、馬鹿でない人がそれを修正することの繰り返しで発展してきた。 というわけで言語間での設計判断のい違いとか失敗した設計とかを収集中。一部抜粋して講義資料に入れるつもりなので他の事例をご存知でしたらぜひ情報をいただけるとありがたいです。 if(x = 0) C言語では代入が式であるためif(x == 0)のつもりでif(x = 0)と書いてしまい、常に偽になってしまう。 x = 0の値はint、条件式はboolでないといけないので型エラーだよ派: Java x = 0は式ではないので条件式に入れたら構文エラーだよ派: Python 条件式にx = 0をいれたらx == 0と解釈するよ派: H

    不完全にしてかなり言葉足らずな比較プログラミング言語学 - 西尾泰和のはてなダイアリー
  • Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅い - 西尾泰和のはてなダイアリー

    ラボの昼休みに光成さん、中谷さんとご飯をべながら話した内容を一応ざっくりとまとめておく。 発端はたしか最近Haskellを勉強の光成さんが、Haskellのかっこいいsieveは実はとても遅い(俺は Haskell の sieve についてとんでもない思い違いをしていたようだ...)という話を見て、同様にかっこいいけど遅い下記のフィボナッチ数列の定義の速度を調べてみたら2.5乗くらいのオーダーになっていたという話だったかと思う。 fib = 1:1:zipWith (+) fib (tail fib) 僕も確認するために、コマンドライン引数でNを与えられるフィボナッチ数列のN番目を求めるコードを書いた。 import System fib = 1:1:zipWith (+) fib (tail fib) main = do args <- getArgs print $ (0 *) $

    Haskellの「fib = 1:1:zipWith (+) fib (tail fib)」はとても遅い - 西尾泰和のはてなダイアリー
    nanakoso
    nanakoso 2010/06/23
    フィボナッチ
  • Haskellで同じ名前が常に同じ値を返すとは限らないという話 - 西尾泰和のはてなダイアリー

    モナドって結局何なのよ? — join to Monad v0.1.1 documentationを読んでいて、そこの指摘が「ああ確かにこれは他の言語から来た人がつまずきやすい点だな」と思ったのでそこだけ切り出して詳しく書いてみる。まずは下のコードの穴埋めをしてみよう。 $ ghci Prelude> import ****** Prelude ******> let f x = ***** Prelude ******> (f 0) * 1 2092838931 Prelude ******> (f 0) / 1 0.9872770354820595 Prelude ******> (f 0) * 1 == (f 0) / 1 True「Haskellの関数は純粋だ、同じ関数に同じ引数を渡せば常に同じ値が返る」うんうん、それには同意する。だがしかし、それでもなお(f x)が異なる値に評価

    Haskellで同じ名前が常に同じ値を返すとは限らないという話 - 西尾泰和のはてなダイアリー
  • Haskellのshowを再利用 - 西尾泰和のはてなダイアリー

    http://d.hatena.ne.jp/hoge1e3/20080128 * 通常はデフォルトのshow を使って * ある一部のクラスについてはshow をカスタマイズしたい toStringじゃなくてshowにしてみました。 data Pair = Pair {car::Pair, cdr::Pair} | Null | Value Int instance Show Pair where show (Pair x y) = "(" ++ show x ++ " . " ++ show y ++ ")" show Null = "()" show (Value x) = show x main = putStrLn $ show $ (Pair (Value 1) (Pair (Value 2) Null)) 僕もJava使いだったのでなんとなくわかるのですけど、 data Foo

    Haskellのshowを再利用 - 西尾泰和のはてなダイアリー
  • 1