タグ

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

  • 数学的帰納法は帰納ではない? - 西尾泰和のはてなダイアリー

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

    数学的帰納法は帰納ではない? - 西尾泰和のはてなダイアリー
    aont
    aont 2014/08/07
    帰納法的推論を演繹法で示すことと思っていたが、それとは違う考えのようだ。
  • 量子将棋が面白い - 西尾泰和のはてなダイアリー

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

    量子将棋が面白い - 西尾泰和のはてなダイアリー
    aont
    aont 2013/10/28
  • 「めんどくさい」「やる気がでない」時のチェックリスト - 西尾泰和のはてなダイアリー

    「めんどくさい」「やる気がでない」にも色々なパターンがあります。そこで質問に答えていくと解決策にたどりつくようなチェックリストを作ってみました。 追記: このエントリーの内容を元に平均10問の質問に答えるだけであなたの状況に合わせたアドバイスをする人工知能を作りました。オススメです。 Q1: やる気がでないのは今日に入ってからですか? 数日やる気がでない状態が続いているのですか?それとも今日に入ってからかですか? 今日に入ってから→Q2 数日続いている→Q8 Q2: 最近なにか新しい情報が明らかになりましたか? たとえば計画段階では知らなかった事実が明らかになって、今までやってきた作業が無駄になったとか。何らかの情報が最近明らかになりましたか? はい→状況が変わったのであれば、計画の通りに実行することが必要とは限りません。状況の変化に合わせて計画を変更したり中止したりしてはいけないのですか

    「めんどくさい」「やる気がでない」時のチェックリスト - 西尾泰和のはてなダイアリー
    aont
    aont 2012/11/19
  • 言語女子会2: varは必要?/privateがない? - 西尾泰和のはてなダイアリー

    言語女子会: undefとnullは両方必要?の続編です。 varは必要なの? とあるプログラミング言語が集う女子会にて: Python: JavaScriptちゃんってさ、なんでvarだらけなの? JavaScript: えっ、変? Python: varなんかいらなくない?私ぜんぜん持ってないよ? JavaScript: えー、じゃあ変数をどうやって宣言するの? Python: 宣言っていうか…「x = 1」みたいな代入文があれば変数xが必要なのって自明じゃない?宣言とか必要? Ruby: 必要ないよね。っていうか変数宣言とか古臭くない? JavaScript: そうかなー。 Python: 少しダサイかも。ほら断舎離ブームだし要らないものは捨てなきゃ! JavaScript: 要らないかなぁ、変数宣言。Pythonちゃんは関数がネストしているときに外側のスコープの変数に代入するのって

    言語女子会2: varは必要?/privateがない? - 西尾泰和のはてなダイアリー
    aont
    aont 2012/03/22
  • 電車内プログラミングの生産性が高いのは何故かに関する考察 - 西尾泰和のはてなダイアリー

    Twitterから転載 電車の中でやるコーディングは自由意志でやりたいと思ってやるコーディングなので生産性が高い 電車の中ではインタラプトが入らないから生産性が高い 近づいてくるデッドラインが明確なので締め切り効果が発生して生産性が高い 電車の中では調べ物ができないので、調べ物が必要なタスクが後回しにされて、結果として下調べが済んでいるもしくは脳内の知識でできるタスクを実行するから生産性が高く見える タイミングが予想出来る乗り換えインタラプトが存在するので、乗り換えの間に考えていたことを忘れないようにファイルに出力すること、そして歩くことが問題の整理に役立っている 電車の適度な騒音や移動していることによる海馬への刺激がなんか集中力を高めたりするのかもしれない 「目的地につくまで15分だからその間にアレを実装出来るかな?」というのがまさに「自発的に設定した制限時間へのチャレンジ」なのでドーパ

    電車内プログラミングの生産性が高いのは何故かに関する考察 - 西尾泰和のはてなダイアリー
    aont
    aont 2010/05/09
  • 1