はてなブックマーク

清水団(@dannchu)さんの「たくさん玉を入れ替えた後の確率」の問題が面白そうでしたので，sympy を使って調べてみました。 問題 はじめ，袋Aには白玉10個，袋Bには赤玉10個入っている。 ＜操作＞ Aから1つBに入れ，Bをよくかき混ぜ，Bから1つAに戻しかき混ぜる。 この＜操作＞をたくさん繰り返すと… 問題1. 「袋Aに白玉が5個，赤玉が5個入っている」状態に近づくと言えるか？ 問題2. この＜操作＞をたくさん繰り返したのちに，袋Aから玉を1個取り出すとき，それが白玉である確率は，1/2に近づくか？ 漸化式を立てる $n$ 回の試行後に，袋Aに白玉 $k$ 個，赤玉 $10-k$ 個が入っている確率を $p_{n,k}\ (n\geqq 0, 0\leqq k\leqq 10)$ とおきます。 $n$ 回目から $n+1$ 回目への推移を考えます。 $n+1$ 回目の試行後に袋A

現時点(2022/02/01)では，macOS の最新版は macOS Monterey 12.2 ですが，次期 macOS アップデートの 12.3 では，macOS の Python 環境に大きな変化がもたらされることになりました。 ニュース これは，2019年に予告されていた「スクリプト環境の粛正」がいよいよ始まったのでしょう。 Scripting language runtimes such as Python, Ruby, and Perl are included in macOS for compatibility with legacy software. Future versions of macOS won’t include scripting language runtimes by default, and might require you to instal

トレンドが Swift に移って久しく，近年は Objective-C に関心を持つ人が減っていますが，Linux 上で Objective-C の開発環境を整える方法についてまとめてみました。 Docker 上の Ubuntu 18.04 および 19.10 で動作確認しています。Dockerfile の ENV と RUN の内容を取り出せば，実機でも動くでしょう。 Objective-C 1.0 でよいなら…… 昔ながらの Objective-C 1.0 でよいなら，apt で入手できる出来合いのパッケージをインストールすれば，比較的容易に Clang 9 による Objective-C の開発環境を整えられます。 FROM ubuntu:19.10 RUN set -x \ && apt update \ && apt upgrade -y \ && DEBIAN_FRONTEND

以前の記事では，最新の TeX Live 2019 に，高品質なオープンソース和文フォントである原ノ味フォントと，新進気鋭の LaTeX 文書ビルドシステム llmk を搭載した Docker コンテナのイメージを作成しました。 TeX Live 2019 + 原ノ味フォント + llmk の Docker コンテナを作る それに対し今回は，過去バージョンの TeX Live を保存した Docker コンテナを作成してみました。 使い道 過去バージョンの TeX Live を Docker コンテナとして保存し，いつでも過去バージョンを呼び出せるようにしておくと，次のような場面で役立つはずです。 過去に組版した文書を今コンパイルしたら組版結果があちこち変わり，ページ数が変わってしまった！（←これ結構起こりますよね……😓）元と同じ環境で再度コンパイルしたい……！ 最新の TeX Live

Docker を使えば，普段使いの TeX Live 環境とは別に古い TeX 環境を保管しておいたり，あるいは逆に先端の開発中ブランチを試しに導入できたりと，色々便利です。 というわけで今回は，TeX Live 2019 + 原ノ味フォント + llmk でコンパイルできる Docker コンテナを作ってみました。 目標 モダンな TeX Live 環境を一発で用意できる Docker のコンテナイメージを作りたい。 pdfLaTeX / LuaLaTeX / XeLaTeX / (u)pLaTeX, dvips / dvipdfmx の全てを使えるようにする。 Adobe の源ノ明朝／源ノ角ゴシックを Adobe-Japan1 準拠に組み直して作られた高品質なオープンソース和文フォントである原ノ味フォントを，和文標準フォントとして使えるように準備・設定しておく。 【参考】 TeXCon

前回の記事の続編です。 HFS+ における Modified NFD Apple が OS X でファイルシステムとして採用しているHFS+では，ファイル名を原則としてNFDで分解して保持するようになっています。 2種類の「が」は分解形で統一される たとえば，ユーザが が.txt（「が」はU+304Cの1文字）というファイル名でファイルを保存しても，ファイルシステム上は が.txt（「が」は U+304B U+3099 の合成文字）として保存されます。 実際，が.txt（「が」はU+304Cの1文字）としてファイルを保存した後，Finderでファイル名変更モードに入り，「が」という文字をコピーすると，U+304C ではなく，U+304B U+3099 という2文字がコピーされるのが確認できます。 → か(U+304B) + 結合用濁点(U+3099) がコピーされる CJK互換漢字を置き

これは，こちらのサイトによると， Depending on your requirements, this may or may not be what you want, but it is certainly consistent with the overall design of the String type to abstract away as many Unicode details as possible. Rule of thumb: if two strings look equal to the user, they will be equal in your code. つまり，「Unicodeでの実装にかかわらず，ユーザ側からの見た目が同じであるからには，コード上でも同一として扱われるべきである」という原則に基づいているとのことです。 実際，この仕様はApple

先程，長年待望されていた ATOK for iOS がとうとう公開されました！ しかし，これまで iOS の標準キーボードを鍛え込むため登録していた多数の単語は，ATOK for iOS へは反映されないようです。 自分はこれまで，固有名詞や顔文字をはじめ，「めーる」→自分のメールアドレス，「でんわ」→自分の電話番号 など，いろいろ単語登録することで入力を便利にしていましたので，これを引き継ぎたいと思い，登録単語のエクスポート・インポートを試みました。 1. iOS → iCloud → Mac 経由で辞書をエクスポート iOS と Mac の「ことえり」は，iCloud を経由して登録単語を共有しています。普段Macで「ことえり」を使っていなくても，iCloudの「書類とデータ」の同期を有効にしていれば，登録単語は同期されています。 そこで，Mac 経由で登録単語一覧をファイルとしてエク