...これなら悪くないと思います。なると少し変なので、名前は要検討かと。ago=begin今の論点は以下の三つだと思います。復元抽出の指定まず、今回のおみくじは復元抽出なので、復元抽出の指定を追加する必要があります。いう名の復元抽出メソッド追加を推します。互換性上の問題は発生しません。重みをどこから与えるかですが、そもそも元のデータはどこにあるのかという観点があります。存在する場合があるでしょう。やるというのはそれなりに理由があるように感じます。呼び出し回数が多い場合について考えると、要素数・抽出数が少ない場合はどうでもよいとしましょう。いうか)で保持して、そこから取ってくるようにしたほうがいいんじゃないですかね。これは現時点では必ずしも入れる必要はない気もします。これなら悪くないと思います。なると少し変なので、名前は要検討かと。するだろうので、変にはなりませんね。ago=beginまず、今回のおみくじは復元抽出なので、復元抽出の指定を追加する必要があります。いう名の復元抽出メソッド追加を推します。あったものが急に使えなくなる問題も自然と解消されますし。これなら悪くないと思います。なると少し変なので、名前は要検討かと。するだろうので、変にはなりませんね。これを採用する可能性を考えると、重みをブロックで指定する方式は整合性がなくなる可能性が高いでしょうか。akr@fsij.org:なので、被復元抽出を効率的に実装する方法について検討が必要ですが、それはちょっと自明ではありません。2006)というアルゴリズムがあるようですね。重みの情報は、存在する各要素から重みを求める関数の形で与えればいいようです。2006)というアルゴリズムがあるようですね。重みの情報は、存在する各要素から重みを求める関数の形で与えればいいようです。論文の最初のほうだけ読んでやってみるとこうですかねぇ。正規分布っぽいものを与えて、それっぽい形になっています。復元抽出の指定まず、今回のおみくじは復元抽出なので、復元抽出の指定を追加する必要があります。一回の呼び出しで複数取り出すことはあまり考えていなかったのではないか、という印象を受けます。実装でも引数を考慮しない簡易的なもの、と書かれています。ひとつだけ取り出すなら、復元抽出でも非復元抽出でもかわりないので、どちらでも気にしないんじゃないかと思っています。redmine@ruby-lang.org:これなら悪くないと思います。なると少し変なので、名前は要検討かと。するだろうので、変にはなりませんね。これを採用する可能性を考えると、重みをブロックで指定する方式は整合性がなくなる可能性が高いでしょうか。あ、確かにこれだと重みが指定できませんね。復元抽出の指定まず、今回のおみくじは復元抽出なので、復元抽出の指定を追加する必要があります。一回の呼び出しで複数取り出すことはあまり考えていなかったのではないか、という印象を受けます。実装でも引数を考慮しない簡易的なもの、と書かれています。ひとつだけ取り出すなら、復元抽出でも非復元抽出でもかわりないので、どちらでも気にしないんじゃないかと思っています。IRCにおけるちょっとした議論の結果、主たる想定ユースケースはRPGゲームだろうということになりました。この場合確かにakrさんのご指摘通りな可能性が高いように思います。ago=beginそして、ひとつだけ取り出すなら、復元抽出でも非復元抽出でもかわりないので、どちらでも気にしないんじゃないかと思っています。おっしゃる通り、個人的には全く気にしません。気にする人たちのことを考えて仕様を検討してほしいとは思っています。ago=beginむらたです。さんのおかげでこのスレに気付けました。ありがとうございます。話しが長くなったので、引用を前後させます。tarui@prx.jp:じゃあ反対ないので実装はともかく、この仕様は基本入れる方向で考えましょう。反対の人は意思表示お早めに。仕様が詰められていないと思うので、そういう意味で消極的反対です。仕様をもっとよく考えるべきです。ニーズについては頷けるので、何らかの形で分布関数を与えることには異論はありません。ここで、幾つかの考慮すべきことがあります。効率的な実装の可能な仕様であるべきです。非復元抽出の要望が入るとすれば、その要望と衝突せず、整合性を持つ仕様である必要があります。メソッドとして提供する方法が良いのではないかと。計算コストはそんなに変わらないでしょう。私は導入することに反対ではありません。その代わりインターフェイスで以下の提案があります。次のようにすると良いのではないでしょうか。重みを配列かハッシュで受け取る。用意し、後置ブロック経由で重みを与えられるようにする。後置ブロックを受け付けるより分かりやすいと思っています。複数個の抽出を実装して良いと思います。する事が最も一般的なのではないかと思います。アルゴリズムを採用したほうが効率が良いはずです。アルゴリズムを切り替えるための閾値の調査などが必要になるでしょうね。用に作ったことがあります。必要なら私が実装しても構いません。私はここまで複雑にしなくて良だろうと考えています。mrknさんのMath/Random構想を考慮して欲しいです。あちらで提供される分布実装と整合性を持つ仕様であって欲しいです。二種類で構成されます。ライブラリに習っています。クラスの代わりにできるように今はなってないです。ここで動くコードを見せられたらカッコ良かったんですが、残念ながら今はコンパイルできません。そのまましばらくのあいだ放置してしまっている状況です。「呼び出したら添字を返すモノ」を乱数生成器の代わりに受け取って使えるようになる必要があります。アルゴリズムを実装して重み付き抽出の追加機能を提案しようと考えていました。これ以上複雑にできないだろうなと考えるに至っています。:P上のように考えるに至った理由は次のとおりです。アルゴリズムのように作業用データを準備したりする必要があります。準備のための計算コストを考えると、そのような準備済みの状態をオブジェクトにして取り出して使い回せる仕組みが欲しくなります。結局のところ「抽出器」として母集団となる配列なりハッシュなりを含むオブジェクトが必要になるということですね。そのような準備を隠してしまうメソッドです。複数回の呼び出しで複数個の抽出を高速に行なう用途には向いてません。関数も複数回の呼び出しには最適化できてないです。求めるのは得策じゃないです。確率情報源クラスとして抽出器を実装する必要があります。最低限だけできるようにして「遅いのが嫌なら自分で実装してね」で良いと思います。上で書いた「抽出器」を生成するメソッドになってるんですね。このアイデアはとても素晴しいと思います。ago=begin遠藤です。メソッドとして提供する方法が良いのではないかと。議論すべきだと思います。わからないどころか誤解させる語感があるのでかなり反対ですが)。次のようにすると良いのではないでしょうか。重みを配列かハッシュで受け取る。用意し、後置ブロック経由で重みを与えられるようにする。したらどうかな、という案が挙がっていました。個人的には、ブロックが重みを表すのにはどうも違和感があります。類似という話もわかるっちゃわかるのですが。相性が悪いって問題もあります。アルゴリズムを採用したほうが効率が良いはずです。アルゴリズムを切り替えるための閾値の調査などが必要になるでしょうね。用に作ったことがあります。必要なら私が実装しても構いません。さんは何のためにこれを作ったのかが興味あります。この提案はユースケースが明確でなく、その辺の議論がどうも机上の域をこえてない感じですので、参考になるのではないかと。アルゴリズムのように作業用データを準備したりする必要があります。準備のための計算コストを考えると、そのような準備済みの状態をオブジェクトにして取り出して使い回せる仕組みが欲しくなります。最低限だけできるようにして「遅いのが嫌なら自分で実装してね」で良いと思います。そんなもの組み込みにする必要があるんでしょうか。上で書いた「抽出器」を生成するメソッドになってるんですね。両方あれば問題ないと思います。ago=begin遠藤です。その実装の案をまとめてみました。redmine@ruby-lang.org:おっしゃる通り、個人的には全く気にしません。気にする人たちのことを考えて仕様を検討してほしいとは思っています。小さい変化で済むといいですね。うまく分割して漸進的に作るのがいいと思うので。ago=beginむらたです。次のようにすると良いのではないでしょうか。重みを配列かハッシュで受け取る。用意し、後置ブロック経由で重みを与えられるようにする。したらどうかな、という案が挙がっていました。私も同様のインターフェイスを考えていました。なくて配列とハッシュも受け付けられれば良いと思います。アルゴリズムを採用したほうが効率が良いはずです。アルゴリズムを切り替えるための閾値の調査などが必要になるでしょうね。用に作ったことがあります。必要なら私が実装しても構いません。さんは何のためにこれを作ったのかが興味あります。この提案はユースケースが明確でなく、その辺の議論がどうも机上の域をこえてない感じですので、参考になるのではないかと。