サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
おみそ汁
fj.hatenablog.jp
カジノでバカラを遊んでみて、これはハマる人が多いのも頷けるという感想を持った。ほとんど単純な丁半博打なのですが、徐々に状態が確定していく演出があって、当たったときのフワッと気が舞い上がる感覚がクセになります。次にやったときにもっと楽しめるように、少しバカラの統計を調べて遊んでみようと思う。 今日は1回のゲームでの確率を調べてみます。モンテカルロ法でやるのも芸がないので、頑張って手計算で調べていきましょう。ただバカラのルールは複雑だから、紙と鉛筆だと間違ってしまうので、Python でコードを書きながらやっていきます。 勝率の計算 まずはプレーヤー、バンカーそれぞれの勝率を求めます。プレーヤーが勝つ場合を場合分けして、それぞれの確率を求めて、足し合わせるというトップダウンのアプローチでも計算できますが、今回はいろいろな条件下での確率を計算してみたいので、ボトムアップなアプローチでやってみたい
「答えのない問題」と呼ばれる種類の問題があります。この種類の問題に取り組む仕事は、過重労働のイメージが強い。その理由が問題の構造にあることに気づいたので記録しておく。 まず答えのない問題について説明します。答えのない問題とは、明確な解決策や結論が存在しなかったり、主観性の違いにより一意の答えが存在しない問題のことです。明らかな答えはなくて、人によって言うことが変わるような問題です。例えば広告のクリエイティブだったり、ビジネス上の戦略立案や意思決定に関する問題、投資判断の問題は、答えがない問題です。どんな広告を出したらいいかに唯一の正解はないし、企業の戦略も唯一の正解があるわけではありませんね。 『左利きのエレン』で描かれている広告会社のクリエイティブの人たちとか、コンサルタントの人たちの SNS とか眺めていると、彼らの仕事はハードワークの印象が強い。やりがいが強く夢中になれる仕事だから、
それってあなたの感想ですよね? このフレーズは、ひろゆきの言葉として有名です。このフレーズだけ聞くと、感想だからだめだというようにも聞こえますが、感想を述べること大切だと私は考えています。 もちろん、ひろゆきが感想を持つべきではないと言っているわけではありません。彼の言いたかったことは、意見と事実の混同を避け、それぞれをきちんと識別しましょうということでした。意見と事実の区別は議論における基本的なスキルで、事実の裏付けがない意見は説得力を欠きます。 しかし、自分の意見を持つことは重要です。意見を持つことは、ポジションを持つとも言います。上司に対して「どうしましょう?」という相談を持ちかけたとき、「君はどうしたいの?」と聞き返されることは皆さんも経験があるのではないでしょうか。それは、自分の意見を表明してほしいというリクエストです。 その一方で、意見を持つことは、しんどいと感じることもあるで
マネージャと呼ばれる職種の人はどこの組織にもいます。いわゆる中間管理職の人々です。個人の人格は別にして、彼らには組織上の機能の要請から、共通の行動原理があります。マネージャは例外なくこの行動原理にしたがって動きます。特に優秀なマネージャであるほど原理に忠実に動くものです。そのため、マネージャというロールの人々は行動の予測がしやすい; 別の言い方をすると御しやすい人々だと言えるでしょう。マネージャをマネジメントするのは、サラリーマンスキル(コンピテンシというやつ)の一つで、彼らをコントロールできた方が楽に仕事ができるようになります。 今回は、私が長年の観察により発見しましたマネージャの行動原理を挙げまして、マネージャを御する方法を考えてみたいと思います。 マネージャは自分の立場を守る。 全ての管理職は自分の立場を守ること、つまり保身を最も優先します。自らの責任範囲で悪いことが起こらないことに
ChatGPTが私の人間に対する価値観を変えている。人より賢いAIが実際に存在するとわかると、どのように人間があるべきか悩む。ChatGPTを使えば、大量のテキストをほとんど手間なく作成できるため、私がわざわざ文章を書く価値はないと思うが、逆にChatGPTに刺激されて、ものを書きたくなるのが不思議だ。 さて、ChatGPTは、主体性がないがとても優秀なアシスタントのようなものだ。言われたことには、必ずすぐに何か返答する。こちらの作業指示が悪くて間違う場合もあるが、フィードバックを与えて修正を促せる。逆に聞いていないことは答えないので、ChatGPTのアウトプットがこちらの想像を超えることはない。 ChatGPTは、私を含めて大半の人より賢いので、人に頼むよりChatGPTと会話している方が有意義だとよく思う。ChatGPTには主体性がなく、報連相ができないため、分からなかったことを「分か
ChatGPT が出てきて、平均値なものに価値がなくなって、外れ値に価値があるか、人の役割はノイズを与えるだとか言われているのを聞くが、そんなことはないと思っている。間違い方は無数にあるが、正しいのやり方はほんの少ししかない。なにかをするときには、無数の選択肢の中から、正しいものを選び取っていかないと、ゴールにたどり着かない。ChatGPT だってプロンプトとして与えられるものは無数にあるが、求める答えが得られるプロンプトはわずかだ。正しい答えを素早く得る能力の価値は ChatGPT があっても変わらない。 もちろん人間なので、たまに道から逸れるだろう。外乱もある。でも、その場合も都度都度修正していけば、目的地にたどり着ける。 ChatGPT の画期的なところは即座にフィードバックを与えて修正ができることだ。 だが、修正がなしに一発で決める方が、何度もフィードバックを繰り返すより、速い。仕
間違いを減らす方法を考えていて、ある程度以上はどうしようもないという役に立たない結論を得たのだったのだが、過激だったのか、意図せずアクセスが増えてしまった。単に苦労していますだけの内容を多く読まれても困るなと、一回取り下げて書き足しました。 間違いの減らし方を こちら に書きました。 仕事をしていると、必ず間違いを提出してくる人に出会ったことはないでしょうか?私は何度も悲しい思いをしており、そういう人にはもう仕事は頼めないと、非情ですが早々に判断するようにしています。 少なくともソフトウェア開発の世界では、正確さに大きな価値が置かれています。この業界だけでなく、一般的に、間違いは欠陥か事故であり、基本的に許されないものです。仕事は、紙の試験ではないため、百点満点が当たり前です。タクシーに乗ったら、事故せずに必ずつくことを期待する。手術で手が滑ることや、車を運転して信号を見間違えることは許さ
ChatGPT の登場には脳天を雷で撃たれたかのような衝撃が走りました。世間の多くの人が ChatGPT に驚いて興奮しているのは知っていますが、私も同じように感動を覚えています。技術的にや社会的に見て ChatGPT の何がすごいのかは、私が述べるまでもないですが、私にとって ChatGPT がどうすごいのかは、言語化したほうがいいと思ったので書きます。 AI が仕事を奪うとか、シンギュラリティだとか、言っている人もポジショントークで言っているだけで、本気で信じているとは思ってませんでした。例えば投資を集めるために、ストーリーとして面白いから語られていただけで、実際信じてないんだろうと冷ややかに見ていました。 しかし、ChatGPT を見せられると、冷ややかというか冷静ではいられません。産業的なインパクトは分かりましたが、それ以上に価値観が揺らぎます。私が大切だと信じて努力してきたものの
『Clean Architecture』を読んでいて、これを実現するには上流工程の順番で開発をすればいいのではと思いました。 Clean Architecture とは上の図で説明されるソフトウェアコンポーネントの設計思想です。フレームワーク・データベース・画面などを「細かい話」として脇に追いやって、業務を中心に据えているところが特徴です。業務のモデルを表す Enterprise Business Rules が中心にあって、業務アプリケーションがする仕事を Application Business Rules として記述し、Interface Adapters が業務アプリケーションと細かい話を結びつけます。そして、Clean Architecture は、コンポーネント群のビルドの依存関係も、外側から内側にと、アプリケーションが業務に依存するようにせよと言っています。 さて、この Cl
Cephに興味が出たので調べていまして、そのメモ代わりに…… どのサーバーが何のデータを持っているのか覚えておかなければならない問題 分散ストレージシステムで面倒な課題にデータの位置の管理があります。あるファイルがあったとして、そのデータを読みたい。その際何も手段がなければ、どのサーバーが欲しいデータを持っているか分かりません。最も単純な解決方法は、どのサーバーが何のデータを持っているか覚えておくサーバーを用意することです。データを持っているサーバーをデータノード、どのデータがどのデータノードにあるかを覚えているサーバーをメタデータノードとでも呼ぶことにします。メタデータノードを用意する方法では、データにアクセスしたいマシン(アクセスクライアントと呼びます)がデータを得るには以下のような操作を行う必要があります。 アクセスクライアントは、メタデータノードに欲しいデータがあるデータノードのホ
「順問題」と「逆問題」という新しいことばを知りました。英語でいうと direct problem, inverse problem です。例えば、入出力系を考えたときに、入力から出力を求めるのが順問題で、出力から入力を推定したり、入力に対して求められる出力を実現する系を考えたりするのを逆問題と呼ぶそうです。算数の問題だけでなくて、広く「問題解決 problem-solving」といわれる一般的な問題にあてはめると、こうやったらどうなるかを求めるのが順問題、こうなるためにはどうするかを求めるのが逆問題です。 例えば下のようなのが例としてあげられるでしょうか。 順問題 - 演算、構造計算、実験、検査、推論 逆問題 - 設計、プログラミング、計画、証明、詰将棋 厳密に区別できるものではないです。順問題で、こうやったらどうなるかを求めるには、実際にやってみるというのが一つの良いやりかたですが、どう
語っていることの辻褄があっているとか、矛盾がないとか、整合性が取れている状態を論理的と言います。意思決定や問題を解きたいときなど、正しさに重きが置かれる場面では、論理的であることを求められます。論理的整合性が取れていないものは誤っている可能性が高く、根拠が弱かったり話の辻褄があっていない意見は、正しいことを求めるところではだいたい無視されるでしょう。ただし偉い人が言ったら別ですけど。 議論が論理的か非論理的かは、話を聞く人が判断しますが、われわれはどうやって話の筋が通っているかどうかを判断しているんでしょうか。現実にはもっと大雑把にやっていますけど、理想的な場面を仮定して、数学の証明のように推論規則を守っているかをひとつずつ確認しているとしましょう。ひとつの文が論理的に妥当化どうかって、わたしたちはどうやって判断していますかね。見たら分かるとしか答えようがないと思うんですよね。 例えば「A
会社でも役所でも国家でも人が集まるところには、人が集まること特有の事象というのが多くあります。その中でも特に「決める」ということは、一人で何かする場合にはありえない面倒な作業です。決裁とか承認とか呼ばれるものです。 決裁とか承認は、職務権限で誰が決裁するか決まっている場合もあれば、管轄としてどこが決定するか決まっている場合もあるかと思いますが、いずれにせよ、だいたいの仕事は決めるのは自分ではなくて、他の誰かに決めて貰わないといけません。自身の行動ですら、決めることを許されないのが組織にいてつらいところですね。 決裁権を持つ人、つまり、決める人が組織や仕事に与える影響は大きくて、何かするときには、この決める人が仕事のボトルネックになってしまうことが多いです。決まらなければ進まないし、誤ったことが決まってしまえば失敗します。決めるところにいる人の能力はよく見えますし、決める人の能力は影響が大き
Bash でスタックトレースを表示する方法。 caller という組み込みコマンドで関数の呼び出し元の位置がさかのぼって取れます。これを使って以下のようなスタックトレースを表示する関数が作れます。 function print_stacktrace() { index=1 while frame=($(caller "${index}")); do ((index++)) # at function <function name> (<file name>:<line no>) echo "at function ${frame[1]} (${frame[2]}:${frame[0]})" >&2 done } function func_a() { print_stacktrace } function func_b() { func_a } function func_c() { fu
仕事の出来栄えは、どのような順番でサブタスクをこなしていくか、考えていくかで大きく変わってくるように思います。もちろん、やる順番が唯一の説明変数ではありませんが、安定した仕事ができる経験豊かな人と、そうでない未熟な人、この二者の間では、明らかに手をつけていく順に違いがあります。 一般的に経験の浅い人たちは、どうやるのか想像がつきやすくて、簡単に手をつけやすいところから始める傾向があります。そして、手をつけ始めたところに夢中になってしまい、考慮していないところに大きな落とし穴があることに気づきません。後々になって問題が明らかになって、手戻りをしたり、いびつな状態で無理やり終わらぜなるを得なくなったりします。この結果、仕上がりは悪くなるのはよくあることです。 例えば、経験のない人が、設計をしてみたら、全体的には穴だらけなのに、一部はやたらと細かくなります。決まって、どこまで細かくしていいか分か
オブジェクト指向プログラミングは失敗だった――以前から思っていました。 okuranagaimo.blogspot.com オブジェクト指向プログラミング (OOP) が人類にとって早すぎたか、人類には OOP が向いていなかった。世の中の Java で作られたプログラムのほとんどは、Java に付属する OOP っぽい機能を使うことで余計に複雑になっているように思います。ここでいう複雑さとは、頭が整理されていない状態、頭が構造化されていない状態のことです。例えば、インスタンスなんて作らずに全部 static メソッドでベタ書きされた方がよっぽどわかりやすいのに、それができてしまうからという理由で要らぬ副作用、すなわちオブジェクトの状態の変化が入りこんで、おかしなことになっている様子に出会ったことは何度となくあります。 おそらく原始的で単純な OOP で作られたプログラムはそこまで問題では
static おじさんと呼ばれる人がいたそうだ、あるいはいるそうです。インスタンスの生成を嫌がって、何でも static メソッド にしてしまう人のことです。static メソッドと呼ぶよりも関数と呼んだ方がよいかもしれません。 インスタンスの生成を嫌がるのは、気持ちはわかります。メモリ管理が GC 任せで、速度にどう影響するかわからないのが嫌なのでしょう。現在では、細かいメモリ管理が本当に必要な場合はほとんどないので、ほとんどの場合インスタンスの生成なんて無視してよいでしょう。しかし、ひとつひとつの処理に対してコスト感覚を持つこと自体はよいことです。問題があるとすれば、その感覚が誤っていることでしょう。 ただ、おそらく static おじさんと嘲笑されたのは、コスト感覚の誤りからよりも、未知のものがわからない、覚える気がない態度からでしょう。いつか私も Java おじさんとか Linux
具体化という言葉を会社員をしていますとよく聞きます。特に企画の仕事では良く耳にします。再建策に具体性がないみたいな批判も経済ニュースではよく見ます。どうも、具体的なのは良きことで、抽象的なことは悪しきことみたいです。具体化していくのが仕事だ!といった話もしばしば聞きます。 それは間違ってはいないでしょう。抽象概念に金を払う人はいないですから、仕事でやっている以上何かしらの実体にせざる得ません。抽象概念を操っているように思える数学者でさえ、紙に書かれたものにしなければ仕事とは認められません。 仕事ならば、放っておいても勝手に話を具体化し始めます。すぐにタスクのブレークダウンを始めるし、気の早い人だったら何か「成果物」をつくり始めます。何か不安なのか、取り憑かれたように具体化が行われます。具体化とは難しくないし、それで仕事が進んでいるように見えるからでしょう。 しかし、急速に具体化が進むのは必
先日に発見したモジュールの結合の定義を自身でも気に入ったので、よく知られている結合の種類をこの定義に当てはめてみようと思います。 Coupling (computer programming) - Wikipedia モジュールの結合にはいくつかの種類がありまして、以下のものが知られています。 内部結合 content coupling 共通結合 common coupling 外部結合 external coupling 制御結合 control coupling スタンプ結合 stamp coupling (data-structured coupling) データ結合 data coupling 名前が変だし、それぞれの関係性も分かりづらいので、この分類はあまり好きではないのですが、他のもっと良い分類をしらないので、とりあえずこれを使います。 モジュール の モジュール に対する結合
アーキテクチャの問題とは、システムをどこで分割 (decomposition) するかという問題と言い換えてよいでしょう。分割するのは、魚を捌くのと同じようなもので、包丁を入れるべき場所というのがあります。 分割するというからには、切り分けるサイズがありますが、今回は分割の単位の議論はしません。なぜかといいますと、ちゃんとつくれば、システムの部品は入れ子構造になっているはずです。再帰的に作られているという言い方もできます。つまり、システムを切り分けて出てきたものは、やはり同じやり方で切り分けることができます。マトリョーシカというか、フラクタル的といいますか、問題を切り分ければ同じものが出てくるはずです。明らかに正しいことが分かるサイズが最小単位で、そこに至るまで分割を繰り返されたものが、ちゃんとした仕事でしょう。 問題をバラすときにタテに切るかヨコに切るか、そしてその切り目はどこかというの
モジュールが疎結合になっているとか密結合になっているとか、業界にいますとよく聞きます。モジュール間の結合度の定義を発見したのでメモしておきます。 モジュール の モジュール に対する結合度 は以下の式で定義できます。 ここで、 は が に対して持つ仮定の集合、 は仮定 が成立しなくなる確率です。 要するに、これは情報エントロピーを用いて結合度を定義しようとしていまして、 は0以上の値を取り、結合度の値が大きいほどモジュール間の結合が密となります。 そもそも、モジュール間の結合度というものが定義されていなかったので、その定義を発見したことに意味があります。 さらに、この定義が便利なのは有名な設計原則を説明できてしまうことです。以下のようなものを聞いたことがあると思います。 デルメル原則 リスコフの置換原則 ハリウッド原則 驚き最小の原則 これらはだいたい同じことを言っています。依存する側が持
モダンC言語プログラミング 統合開発環境、デザインパターン、エクストリーム・プログラミング、テスト駆動開発、リファクタリング、継続的インテグレーションの活用 作者: 花井志生出版社/メーカー: アスキー・メディアワークス発売日: 2013/10/01メディア: 大型本この商品を含むブログ (2件) を見る 現代的な開発方法をC言語による開発(特に組み込み向け)でも行おうという話.旧態然としているCの開発に先進的な手法を取り入れようという試みは良いので,悪い本ではない. トピックとしては以下について収録されている: 統合開発環境 オブジェクト指向プログラミング デザインパターン テスト駆動開発 リファクタリング 継続的インテグレーション 開発環境については,Eclipseでもvimでもemacsでも好きなの使えよって思う.EclipseのC/C++プラグインはまだ十分に安定しているとはいえな
オブジェクト指向プログラミング言語ではメソッドを呼び出したいとき、 <インスタンス名>.<メソッド名> とインスタンスを示す変数の名前のあとに、そのオブジェクトに属するメソッドの名前を示します。このプログラミング言語の構文は、誤解も招く良くない構文であったと思います。 <インスタンス名>.<メソッド名> の構文は英語の SV 文型を連想させるので、インスタンスが主語でメソッドが動詞であると勘違いしてしまいます。 しかし、実際にはオブジェクトを目的語とした方が自然な――人間に優しい――プログラムとなるように思います。 Java の標準ライブラリを見ても、オブジェクトが目的語となっているものが多いです。例えば Callable インターフェイスは call() メソッドを持ちます。 "callableObject.call();" とプログラム上は書きますが、英語で書くと "call the
シェルスクリプトのインタプリタを作ろうかと、シェルスクリプトの仕様を調べています。気持ちの悪い仕様をいくつか見つけました。仕様書*1を見ながら、dash で試しました。 丸括弧と波括弧のふるまいが違う。 丸括弧はサブシェル、波括弧はコマンドのグルーピングをするための似たような文法ですが、ふるまいが異なるので戸惑います。 $ (echo hello) hello 丸括弧はコマンドの前後にスペースも要らず、丸括弧内のコマンドが実行されます。 $ {echo hello} {echo: not found $ { echo hello } Syntax error: end of file unexpected (expecting "}") $ { echo hello; } hello しかし、波括弧はコマンドの前にスペースか改行をを入れて、コマンドの後ろにはセミコロンか改行を入れる必要があ
経験とはそう大切なものなのだろうか。 何かをするにあたって、経験が全くないよりは豊富に経験があった方が上手くできるでしょうし、年の功が役に立つことはあります。役に立つとは問題を解決するのに有効かどうかということです。問題を解くことに効果があるならば、その経験は敬うべきものでしょう。 一方で、いくら経験があるとのたまわれても、問題の解決の助けにならなければ、その経験は尊重できません。「昔の誰々が同じようだった」などと経験があることを自慢されたところで、役に立ちません。ただ昔話をしたいのか、自分の優位性を示したいかでしょうから、雑談であればなんぼでもヨイショします。しかし、こちらが問題を抱えていて困っているときに、自慢話を聞かされることはいささか迷惑でもあります。 我々は問題の解決がしたいだけです。その仕事をやっている年月の長さが必ずしも解につながるわけではなく、また解の出処が経験から得た見識
現実はおそらく一つなのだろうけれども、どの断面で切り取るかによって見え方は全く異なるものになります。人の知性では世界をそのまま認識することはできず、何かしらのフィルターを通して世界を見て解釈します。フィルターとはフレームワークやパラダイムやモデルと言い換えてもよいでしょう。生きていますと世界をもっと合理的に解釈できるような新しいフィルターを見つけたり、これまでのフィルターでは解釈しきれないような新しい事象に出会ってフィルターが外れたりします。このときが生活していて最もよろこびを得るときだと、私は思っています。 「接点 t 」とは、高校数学で2次関数・3次関数の数曲線の接線を求める問題の有名な解法のことで*1、この解法を初めて学んだときに狐につままれたような気持ちでした。接点 t はこちらが勝手に置いたもので、それを通る接線なんて存在するかどうかも分からない virtual なものです。しか
COBOL排除の動きが進んでいるそうで…… itpro.nikkeibp.co.jp 私はCOBOL触ったことないですし、COBOLerの実態もよく知らないし、そもそもSEではないので、以降完全に推測で書きます。 私は別にCOBOL言語自体は悪くないと思っている。確かに古いので、新しい言語にあるような近代的な機能はないかも知れません。しかし、だからといって使えないわけではない。実際今まで使えてきたわけだ。COBOLにやらせていることは単に給与とか税金の計算とかの事務処理だと思うのですが、それだったらCOBOLでも十分戦えるのでは? 問題なのは とにかくコードの量が膨大であって誰も全容が分からないこと 保守作業が極めて非効率であること だと思います。ここがすでに間違っているかもしれないが、正しいこととして以降推論します。 これらは別にCOBOL言語の問題ではないですよね? Javaにしたら、
浮動小数点数の時系列データを圧縮するのに xor encoding という手法があるそうだ。 Gorilla の論文 http://www.vldb.org/pvldb/vol8/p1816-teller.pdf 時系列データベースに関する基礎知識と時系列データの符号化方式について - クックパッド開発者ブログ …
Java8で導入されたと話題のラムダ式を勉強中。コーディングの観点からはただの無名関数以上の意味はないが、いろいろ深いみたい。 Pythonだと以下のように書く >>> add = lambda x, y: x + y >>> add(1, 2) 3 では、再帰関数はどうすればよいのだろう? 例えば、階乗は >>> factorial = lambda n: n * factorial(n-1) if n > 0 else 1 >>> factorial(5) 120 と書ける。しかし、 >>> f = factorial >>> factorial = None >>> f(5) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 1, in <lambda
次のページ
このページを最初にブックマークしてみませんか?
『超ウィザード級ハッカーのたのしみ』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く