Hatena::ブログ(Diary)

永字八法 RSSフィード Twitter

 | 

2007-11-30 Friday

勉強になる。

思いついたことを - 永字八法の続き。
404 Blog Not Found:アルゴリズム百選 - フィボナッチ数列にO()を学ぶ

こうして一度出した結果を覚えておいて、あればそれを使うという方法メモ化(memoization)として知られています。見ての通り、定義通りなナイーブ計算法を使っているのに、O(2n)がO(1)(厳密には、最初の一回だけO(n))になってしまうのです。

メモ化、memoizationはmemorizationのtypoだろうけど、メモライゼーション、覚えておこう。
俺程度の発想は先人たちはとっくに通過していると言うことだな。

勉強になる。

思いついたことを - 永字八法の続き。
404 Blog Not Found:アルゴリズム百選 - フィボナッチ数列にO()を学ぶ

こうして一度出した結果を覚えておいて、あればそれを使うという方法メモ化(memoization)として知られています。見ての通り、定義通りなナイーブ計算法を使っているのに、O(2n)がO(1)(厳密には、最初の一回だけO(n))になってしまうのです。

メモ化、memoizationはmemorizationのtypoだろうけど、メモライゼーション、覚えておこう。
俺程度の発想は先人たちはとっくに通過していると言うことだな。

勉強になる。

思いついたことを - 永字八法の続き。
404 Blog Not Found:アルゴリズム百選 - フィボナッチ数列にO()を学ぶ

こうして一度出した結果を覚えておいて、あればそれを使うという方法メモ化(memoization)として知られています。見ての通り、定義通りなナイーブ計算法を使っているのに、O(2n)がO(1)(厳密には、最初の一回だけO(n))になってしまうのです。

メモ化、memoizationはmemorizationのtypoだろうけど、メモライゼーション、覚えておこう。
俺程度の発想は先人たちはとっくに通過していると言うことだな。

2007-11-29 Thursday

遺伝子型の保存について

遺伝子の展開方法について - 永字八法の続き。
no titleIT系っぽいニュースのメモ 11/28: Stressful Angel経由)
これは楽しい
プレイヤーが持つ最初遺伝子型をどうするかと言うのが、遺伝子ゲーム問題の一つだった訳だが、これを使えば「カラーID要件を満たす任意画像」をプレイヤーが選んで使えるようになる訳だ。
で、この展開の仕様は公開……しないんだろうなあ。商売する気満々みたいだし。

遺伝子型の読み取りについて

遺伝子の展開方法について - 永字八法遺伝子型の保存について - 永字八法の続き。

これまでで決めたことを整理しつつ補足、そしてその後

遺伝子型は、23桁の16進数値を二つ用意して表現する
23と言う数値に仕様上の意味はない。ただ単に人間染色体46本23対にあやかっただけである
遺伝子型の展開
それぞれの桁をフィボナッチ式で展開する。フィボナッチ式の第一項をその桁の数値、第二項を対応するもう一方の数値の同じ桁を使う。

遺伝子から形質を読み取る行為については、

  1. 遺伝子の共有
  2. 遺伝子地図
  3. 遺伝子語(造語

の三つの問題がある。
以下、順に考察してみる。

遺伝子の共有

人間遺伝子は、99%以上が全人類共通のものだそうだ。
肌が白いの黒いの、頭が良いの悪いの、そう言ったものは全てこの1%未満の僅かな差異によって規定される程度のことらしい。
この、全人類で共通の部分には、「腕が二本で脚が二本で〜」などのごくごく基本的な形質が記述されていると思われる。逆に言うと、それくらいの量を使って記述をしなければ人間と言う種を語ることはできないのだろう。
原始、遺伝子現在よりも遥かに多様性を持っていただろう。しかし現在人間仕様を見る限りでは、そのほとんど全てが淘汰されてしまったと言うしかない。人間と言う種が完成するまでには、数千数万、あるいは億のオーダーの種が滅んでいったに違いない。その億のふるい分けの結果が人間と言う種なのであれば、その性能・あるいは悪辣さは折り紙付きと言うしかないだろう。
話がそれた。
このゲームでは、プレイヤー最初に持つ遺伝子型は、プレイヤーに選ばせることが前提なのでどのようなものになるのか全く想像もつかない。よって、プレイヤーがどのような遺伝子型を設定しようとも、基本的な形質は変化しないように、プレイヤーのいじれない隠れ遺伝子を設定する必要がある。
先に述べた23桁2本の遺伝子型は、プレイヤーに明示される遺伝子のことであり、それ以外にプレイヤーがいじれない固定部分がその数十倍から数百倍はあるとしなければならない。
また、おファンタジー世界設定でゲームを行うとするならば、人間人間外との交配も充分考えられるので、この隠された部分は種族毎に違う記述を用意することになるだろう。たとえば、人間エルフの間に生まれた個体は、どのような形質を持つか。その答えは、この隠された部分の遺伝子がどう継承されるかで決まるだろう。
以後、プレイヤーが決める遺伝子を「表遺伝子」や型をつけて表現する。プレイヤーに見えない固定遺伝子を「裏遺伝子」と呼ぶことにする。

遺伝子地図の問題

実際の遺伝子を考えてみるとわかることだが。
現在人間遺伝子地図はある程度完成していて、染色体のどの部分がどの形質と対応しているかもある程度わかっているらしい。ニュースか何かでそのように聞いた覚えがある。一例を挙げると「男性Y染色体の一部には耳毛の長さを規定する部位があり、そこに書かれている内容(塩基配列)によって耳毛の生え方が変わってくる」とかだ。
ここで問題なのは、どこに何が書いてあるかの規則性がない、あるいは規則性を見出せていないと言う点だ。
よってどこに何が書いてあるか、も、同様にランダム生成してその後変化させない、とするしかない。
それと、一つの形質のバリエーションを表す遺伝子が、常に一塊になって存在するとも限らない。
たとえば、人間の男女の区別は、23対のうちの一対の染色体によって決まるのが常識だが、それはオッカムの剃刀で整えた後の表現であり、実際には他の部位も若干の影響を及ぼす。その一例が半陰陽であり、リングの貞子のようにXY染色体を持ちながら女性の身体的特徴を有していたりする。女性的な身体的特徴を記述している部位が、XY染色体を中心に染色体全体に散在していることを示す好例である
そこで、全ての形質決定の要素を、表遺伝子と裏遺伝子に分割して配置する。これで、基本的な形質は変わらないが、それぞれの個体が持つ遺伝子型がかみあった時、あまり見られない形質の発現を表現できる。また、そう言った発現をプレイヤーがコントロールできる素地にもなる。

遺伝子語の問題

ここまでで、遺伝子型は全て16進数表現することにしてきた。最後問題は、「ではこの数値は何を意味するのか」である
体毛の色を例にとって考えてみる。
人間の体毛の色は、黒・茶・赤・黄・白のベクトル上のどれかになる(金髪銀髪は「体毛の艶」のパラメータによるものなので、ここでは無視できる。黄色で艶があれば金髪だ。黒髪で艶があっても黒としか言われないのは文化上の問題)。
人間の裏遺伝子部分には、体毛が取りうるカラーコードの表を記述しておく。そして表遺伝子のある部分を、そのカラーコードのどれが選択されているかの表として採用する。
この「裏遺伝子バリエーション表+表遺伝子に選択」を基本パターンとして、他の形質についても記述できるだろう。
種族が混血した場合は、このバリエーション自体が変更されることになり、表遺伝子が同一であっても発現する形質は異なってくる。
-->

遺伝子型の保存について

遺伝子の展開方法について - 永字八法の続き。
no titleIT系っぽいニュースのメモ 11/28: Stressful Angel経由)
これは楽しい
プレイヤーが持つ最初遺伝子型をどうするかと言うのが、遺伝子ゲーム問題の一つだった訳だが、これを使えば「カラーID要件を満たす任意画像」をプレイヤーが選んで使えるようになる訳だ。
で、この展開の仕様は公開……しないんだろうなあ。商売する気満々みたいだし。

遺伝子型の読み取りについて

遺伝子の展開方法について - 永字八法遺伝子型の保存について - 永字八法の続き。

これまでで決めたことを整理しつつ補足、そしてその後

遺伝子型は、23桁の16進数値を二つ用意して表現する
23と言う数値に仕様上の意味はない。ただ単に人間染色体46本23対にあやかっただけである
遺伝子型の展開
それぞれの桁をフィボナッチ式で展開する。フィボナッチ式の第一項をその桁の数値、第二項を対応するもう一方の数値の同じ桁を使う。

遺伝子から形質を読み取る行為については、

  1. 遺伝子の共有
  2. 遺伝子地図
  3. 遺伝子語(造語

の三つの問題がある。
以下、順に考察してみる。

遺伝子の共有

人間遺伝子は、99%以上が全人類共通のものだそうだ。
肌が白いの黒いの、頭が良いの悪いの、そう言ったものは全てこの1%未満の僅かな差異によって規定される程度のことらしい。
この、全人類で共通の部分には、「腕が二本で脚が二本で〜」などのごくごく基本的な形質が記述されていると思われる。逆に言うと、それくらいの量を使って記述をしなければ人間と言う種を語ることはできないのだろう。
原始、遺伝子現在よりも遥かに多様性を持っていただろう。しかし現在人間仕様を見る限りでは、そのほとんど全てが淘汰されてしまったと言うしかない。人間と言う種が完成するまでには、数千数万、あるいは億のオーダーの種が滅んでいったに違いない。その億のふるい分けの結果が人間と言う種なのであれば、その性能・あるいは悪辣さは折り紙付きと言うしかないだろう。
話がそれた。
このゲームでは、プレイヤー最初に持つ遺伝子型は、プレイヤーに選ばせることが前提なのでどのようなものになるのか全く想像もつかない。よって、プレイヤーがどのような遺伝子型を設定しようとも、基本的な形質は変化しないように、プレイヤーのいじれない隠れ遺伝子を設定する必要がある。
先に述べた23桁2本の遺伝子型は、プレイヤーに明示される遺伝子のことであり、それ以外にプレイヤーがいじれない固定部分がその数十倍から数百倍はあるとしなければならない。
また、おファンタジー世界設定でゲームを行うとするならば、人間人間外との交配も充分考えられるので、この隠された部分は種族毎に違う記述を用意することになるだろう。たとえば、人間エルフの間に生まれた個体は、どのような形質を持つか。その答えは、この隠された部分の遺伝子がどう継承されるかで決まるだろう。
以後、プレイヤーが決める遺伝子を「表遺伝子」や型をつけて表現する。プレイヤーに見えない固定遺伝子を「裏遺伝子」と呼ぶことにする。

遺伝子地図の問題

実際の遺伝子を考えてみるとわかることだが。
現在人間遺伝子地図はある程度完成していて、染色体のどの部分がどの形質と対応しているかもある程度わかっているらしい。ニュースか何かでそのように聞いた覚えがある。一例を挙げると「男性Y染色体の一部には耳毛の長さを規定する部位があり、そこに書かれている内容(塩基配列)によって耳毛の生え方が変わってくる」とかだ。
ここで問題なのは、どこに何が書いてあるかの規則性がない、あるいは規則性を見出せていないと言う点だ。
よってどこに何が書いてあるか、も、同様にランダム生成してその後変化させない、とするしかない。
それと、一つの形質のバリエーションを表す遺伝子が、常に一塊になって存在するとも限らない。
たとえば、人間の男女の区別は、23対のうちの一対の染色体によって決まるのが常識だが、それはオッカムの剃刀で整えた後の表現であり、実際には他の部位も若干の影響を及ぼす。その一例が半陰陽であり、リングの貞子のようにXY染色体を持ちながら女性の身体的特徴を有していたりする。女性的な身体的特徴を記述している部位が、XY染色体を中心に染色体全体に散在していることを示す好例である
そこで、全ての形質決定の要素を、表遺伝子と裏遺伝子に分割して配置する。これで、基本的な形質は変わらないが、それぞれの個体が持つ遺伝子型がかみあった時、あまり見られない形質の発現を表現できる。また、そう言った発現をプレイヤーがコントロールできる素地にもなる。

遺伝子語の問題

ここまでで、遺伝子型は全て16進数表現することにしてきた。最後問題は、「ではこの数値は何を意味するのか」である
体毛の色を例にとって考えてみる。
人間の体毛の色は、黒・茶・赤・黄・白のベクトル上のどれかになる(金髪銀髪は「体毛の艶」のパラメータによるものなので、ここでは無視できる。黄色で艶があれば金髪だ。黒髪で艶があっても黒としか言われないのは文化上の問題)。
人間の裏遺伝子部分には、体毛が取りうるカラーコードの表を記述しておく。そして表遺伝子のある部分を、そのカラーコードのどれが選択されているかの表として採用する。
この「裏遺伝子バリエーション表+表遺伝子に選択」を基本パターンとして、他の形質についても記述できるだろう。
種族が混血した場合は、このバリエーション自体が変更されることになり、表遺伝子が同一であっても発現する形質は異なってくる。
-->

遺伝子型の保存について

遺伝子の展開方法について - 永字八法の続き。
no titleIT系っぽいニュースのメモ 11/28: Stressful Angel経由)
これは楽しい
プレイヤーが持つ最初遺伝子型をどうするかと言うのが、遺伝子ゲーム問題の一つだった訳だが、これを使えば「カラーID要件を満たす任意画像」をプレイヤーが選んで使えるようになる訳だ。
で、この展開の仕様は公開……しないんだろうなあ。商売する気満々みたいだし。

遺伝子型の読み取りについて

遺伝子の展開方法について - 永字八法遺伝子型の保存について - 永字八法の続き。

これまでで決めたことを整理しつつ補足、そしてその後

遺伝子型は、23桁の16進数値を二つ用意して表現する
23と言う数値に仕様上の意味はない。ただ単に人間染色体46本23対にあやかっただけである
遺伝子型の展開
それぞれの桁をフィボナッチ式で展開する。フィボナッチ式の第一項をその桁の数値、第二項を対応するもう一方の数値の同じ桁を使う。

遺伝子から形質を読み取る行為については、

  1. 遺伝子の共有
  2. 遺伝子地図
  3. 遺伝子語(造語

の三つの問題がある。
以下、順に考察してみる。

遺伝子の共有

人間遺伝子は、99%以上が全人類共通のものだそうだ。
肌が白いの黒いの、頭が良いの悪いの、そう言ったものは全てこの1%未満の僅かな差異によって規定される程度のことらしい。
この、全人類で共通の部分には、「腕が二本で脚が二本で〜」などのごくごく基本的な形質が記述されていると思われる。逆に言うと、それくらいの量を使って記述をしなければ人間と言う種を語ることはできないのだろう。
原始、遺伝子現在よりも遥かに多様性を持っていただろう。しかし現在人間仕様を見る限りでは、そのほとんど全てが淘汰されてしまったと言うしかない。人間と言う種が完成するまでには、数千数万、あるいは億のオーダーの種が滅んでいったに違いない。その億のふるい分けの結果が人間と言う種なのであれば、その性能・あるいは悪辣さは折り紙付きと言うしかないだろう。
話がそれた。
このゲームでは、プレイヤー最初に持つ遺伝子型は、プレイヤーに選ばせることが前提なのでどのようなものになるのか全く想像もつかない。よって、プレイヤーがどのような遺伝子型を設定しようとも、基本的な形質は変化しないように、プレイヤーのいじれない隠れ遺伝子を設定する必要がある。
先に述べた23桁2本の遺伝子型は、プレイヤーに明示される遺伝子のことであり、それ以外にプレイヤーがいじれない固定部分がその数十倍から数百倍はあるとしなければならない。
また、おファンタジー世界設定でゲームを行うとするならば、人間人間外との交配も充分考えられるので、この隠された部分は種族毎に違う記述を用意することになるだろう。たとえば、人間エルフの間に生まれた個体は、どのような形質を持つか。その答えは、この隠された部分の遺伝子がどう継承されるかで決まるだろう。
以後、プレイヤーが決める遺伝子を「表遺伝子」や型をつけて表現する。プレイヤーに見えない固定遺伝子を「裏遺伝子」と呼ぶことにする。

遺伝子地図の問題

実際の遺伝子を考えてみるとわかることだが。
現在人間遺伝子地図はある程度完成していて、染色体のどの部分がどの形質と対応しているかもある程度わかっているらしい。ニュースか何かでそのように聞いた覚えがある。一例を挙げると「男性Y染色体の一部には耳毛の長さを規定する部位があり、そこに書かれている内容(塩基配列)によって耳毛の生え方が変わってくる」とかだ。
ここで問題なのは、どこに何が書いてあるかの規則性がない、あるいは規則性を見出せていないと言う点だ。
よってどこに何が書いてあるか、も、同様にランダム生成してその後変化させない、とするしかない。
それと、一つの形質のバリエーションを表す遺伝子が、常に一塊になって存在するとも限らない。
たとえば、人間の男女の区別は、23対のうちの一対の染色体によって決まるのが常識だが、それはオッカムの剃刀で整えた後の表現であり、実際には他の部位も若干の影響を及ぼす。その一例が半陰陽であり、リングの貞子のようにXY染色体を持ちながら女性の身体的特徴を有していたりする。女性的な身体的特徴を記述している部位が、XY染色体を中心に染色体全体に散在していることを示す好例である
そこで、全ての形質決定の要素を、表遺伝子と裏遺伝子に分割して配置する。これで、基本的な形質は変わらないが、それぞれの個体が持つ遺伝子型がかみあった時、あまり見られない形質の発現を表現できる。また、そう言った発現をプレイヤーがコントロールできる素地にもなる。

遺伝子語の問題

ここまでで、遺伝子型は全て16進数表現することにしてきた。最後問題は、「ではこの数値は何を意味するのか」である
体毛の色を例にとって考えてみる。
人間の体毛の色は、黒・茶・赤・黄・白のベクトル上のどれかになる(金髪銀髪は「体毛の艶」のパラメータによるものなので、ここでは無視できる。黄色で艶があれば金髪だ。黒髪で艶があっても黒としか言われないのは文化上の問題)。
人間の裏遺伝子部分には、体毛が取りうるカラーコードの表を記述しておく。そして表遺伝子のある部分を、そのカラーコードのどれが選択されているかの表として採用する。
この「裏遺伝子バリエーション表+表遺伝子に選択」を基本パターンとして、他の形質についても記述できるだろう。
種族が混血した場合は、このバリエーション自体が変更されることになり、表遺伝子が同一であっても発現する形質は異なってくる。
-->

2007-11-28 Wednesday

2007-11-27 Tuesday

思いついたことを

ペプシ算ファイナル - 永字八法の続き。
404 Error - FC2ブログ
はてなブログ
ペプシ算をRubyで解いて、さらにはそれをPerl移植していただきました。
そこで思いついたことを二点。

Ruby言語仕様について

関数メソッドに取って変わられた世界と言うのは聞いてましたが、新しい関数を作るのに、デフォルトクラス設計メソッドを追加するとは……すごい言語だ。

class Integer
  def factorial
    (1..self).inject(1){|r, i| r * i}
  end
  def combination(n)
    self.factorial / (n.factorial * (self - n).factorial)
  end
end

これって、Integerクラスにfactorial(階乗メソッドを追加してるんだよね?
もし、他人数でやるアプリケーション開発とかで、複数人間が同じ名前メソッド定義したりしたらどうなるんだろう。それとも、名前空間か何かで区切れるんだろうか。疑問は尽きない。
それと、injectをリファレンス確認して驚いた。同じことをPerlでやろうとしたら、

use List::Util qw ( reduce );
sub factorial {
	return reduce { $a * $b } (1..$_[0]);
}

ってやんなきゃならない。モジュールによる追加機能だっつうの。
RubyCGIが組めるフレームワーク、えーともしかしてRuby on Rails? とか今のレン鯖に入ってたら、Ruby始めちゃうかもしんないな。

エレガントさを取るか、実用性を取るか

実際のところ、アルゴリズム的には木戸さんとこで正解なのかも知れないけど、俺が気になるのは階乗を使っているところで、しかもそれは問われる度に再計算していること。
俺がPerlクラスを作ってごちゃごちゃやっているのは、何度も繰り返し問い合わせた際に、レスポンスを遅くしたり負荷を大きくしたりしないために、計算途中のキャッシュを保持するようにしてるから。既に計算したところは、計算せずにキャッシュから値を返すだけで済むし、まだ計算してないところも、途中から計算を始めることができて楽になるからなんだよね。
まあ、ペプシ算みたいなものを頻繁に問い合わせするようなアプリケーションってのも、あんまり思いつかないけどね。
数学的なエレガントさを取るか、(必ずしも意味があるかはわからない)実用性を取るかは、プログラマーとしての哲学領域にまで入り込んでしまうんで、結論は出ないだろうけど。
教科書としては、基本木戸さんで、「ではこれを高速化してみましょう」みたいにできたらいいと思う。

思いついたことを

ペプシ算ファイナル - 永字八法の続き。
404 Error - FC2ブログ
はてなブログ
ペプシ算をRubyで解いて、さらにはそれをPerl移植していただきました。
そこで思いついたことを二点。

Ruby言語仕様について

関数メソッドに取って変わられた世界と言うのは聞いてましたが、新しい関数を作るのに、デフォルトクラス設計メソッドを追加するとは……すごい言語だ。

class Integer
  def factorial
    (1..self).inject(1){|r, i| r * i}
  end
  def combination(n)
    self.factorial / (n.factorial * (self - n).factorial)
  end
end

これって、Integerクラスにfactorial(階乗メソッドを追加してるんだよね?
もし、他人数でやるアプリケーション開発とかで、複数人間が同じ名前メソッド定義したりしたらどうなるんだろう。それとも、名前空間か何かで区切れるんだろうか。疑問は尽きない。
それと、injectをリファレンス確認して驚いた。同じことをPerlでやろうとしたら、

use List::Util qw ( reduce );
sub factorial {
	return reduce { $a * $b } (1..$_[0]);
}

ってやんなきゃならない。モジュールによる追加機能だっつうの。
RubyCGIが組めるフレームワーク、えーともしかしてRuby on Rails? とか今のレン鯖に入ってたら、Ruby始めちゃうかもしんないな。

エレガントさを取るか、実用性を取るか

実際のところ、アルゴリズム的には木戸さんとこで正解なのかも知れないけど、俺が気になるのは階乗を使っているところで、しかもそれは問われる度に再計算していること。
俺がPerlクラスを作ってごちゃごちゃやっているのは、何度も繰り返し問い合わせた際に、レスポンスを遅くしたり負荷を大きくしたりしないために、計算途中のキャッシュを保持するようにしてるから。既に計算したところは、計算せずにキャッシュから値を返すだけで済むし、まだ計算してないところも、途中から計算を始めることができて楽になるからなんだよね。
まあ、ペプシ算みたいなものを頻繁に問い合わせするようなアプリケーションってのも、あんまり思いつかないけどね。
数学的なエレガントさを取るか、(必ずしも意味があるかはわからない)実用性を取るかは、プログラマーとしての哲学領域にまで入り込んでしまうんで、結論は出ないだろうけど。
教科書としては、基本木戸さんで、「ではこれを高速化してみましょう」みたいにできたらいいと思う。

思いついたことを

ペプシ算ファイナル - 永字八法の続き。
404 Error - FC2ブログ
はてなブログ
ペプシ算をRubyで解いて、さらにはそれをPerl移植していただきました。
そこで思いついたことを二点。

Ruby言語仕様について

関数メソッドに取って変わられた世界と言うのは聞いてましたが、新しい関数を作るのに、デフォルトクラス設計メソッドを追加するとは……すごい言語だ。

class Integer
  def factorial
    (1..self).inject(1){|r, i| r * i}
  end
  def combination(n)
    self.factorial / (n.factorial * (self - n).factorial)
  end
end

これって、Integerクラスにfactorial(階乗メソッドを追加してるんだよね?
もし、他人数でやるアプリケーション開発とかで、複数人間が同じ名前メソッド定義したりしたらどうなるんだろう。それとも、名前空間か何かで区切れるんだろうか。疑問は尽きない。
それと、injectをリファレンス確認して驚いた。同じことをPerlでやろうとしたら、

use List::Util qw ( reduce );
sub factorial {
	return reduce { $a * $b } (1..$_[0]);
}

ってやんなきゃならない。モジュールによる追加機能だっつうの。
RubyCGIが組めるフレームワーク、えーともしかしてRuby on Rails? とか今のレン鯖に入ってたら、Ruby始めちゃうかもしんないな。

エレガントさを取るか、実用性を取るか

実際のところ、アルゴリズム的には木戸さんとこで正解なのかも知れないけど、俺が気になるのは階乗を使っているところで、しかもそれは問われる度に再計算していること。
俺がPerlクラスを作ってごちゃごちゃやっているのは、何度も繰り返し問い合わせた際に、レスポンスを遅くしたり負荷を大きくしたりしないために、計算途中のキャッシュを保持するようにしてるから。既に計算したところは、計算せずにキャッシュから値を返すだけで済むし、まだ計算してないところも、途中から計算を始めることができて楽になるからなんだよね。
まあ、ペプシ算みたいなものを頻繁に問い合わせするようなアプリケーションってのも、あんまり思いつかないけどね。
数学的なエレガントさを取るか、(必ずしも意味があるかはわからない)実用性を取るかは、プログラマーとしての哲学領域にまで入り込んでしまうんで、結論は出ないだろうけど。
教科書としては、基本木戸さんで、「ではこれを高速化してみましょう」みたいにできたらいいと思う。

2007-11-26 Monday

遺伝子の展開方法について

遺伝子物ゲーについて - 永字八法の続き。
昨日はあんなこと言ったけど、別にカオス限定しなくてもカオス的なものでいいよね(笑)

その1:みんな大好きMD5

遺伝子型の中からいくつかを選び、それを組み合わせて種として使う。MD5に食わせて出てきた数値を使い終わったら、最初の種と、使い終わった数字を組み合わせて次の数値をはじき出す。以下繰り返し。

メリット

カオス的には充分。

デメリット

NScripterで使うにはDLL必要になると思う。面倒。MD5の式って、NScripterネイティブ実装できるようなもんなのか?

その2:ちょっと数学的にフィボナッチ式

フィボナッチ数列は、第一項と第二項の初期値が1のものであればみんなよく知っていると思うけど。
これで第一項と第二項を1以外の実数にしてしまったらどうだろうか。ちょっと展開が面白いことにならないだろうか。
具体的には、こんな式か。
F¥small n+2¥Large =(F¥small n+1¥Large +F¥small n¥Large )¥small mod¥Large m
mには、10とか16とか256とかそれっぽい数値が入る。

メリット

一番展開が簡単。NScripterでもら〜くらく。

デメリット

あんまりカオスじゃない気がするんだけどどうよ?

その3:ロジスティック方程式

真打、真のカオス
F¥small n+1¥Large = aF¥small n¥Large(1-F¥small n¥Large)

メリット

カオス計算結構楽。

デメリット
  • 小数点以下が使えないと初期鋭敏性のうまみがなくなると言うか。値をそれぞれ百倍にして擬似的に端数処理してもいいんだけど。
  • aの値をどう設定するかが問題トップシークレットになるなあ。
  • そしてどんな数値にしたとしてもやがて収斂してしまう。しかしこれは利点かも知れないが……。

セルオートマトン

例えば、遺伝子型を示す文字列を全て2進数還元して、その上で1次元セルオートマトンルール30ないしルール90で展開して、タペストリーを作るとする。(参考:セル・オートマトン - Wikipedia
その作成されるタペストリーの模様から遺伝子情報を読み取ると言うのはどうだろう。プレイヤーにもそのタペストリーは見えるのだ。遺伝子型がただの文字列と言うのは、リアルではあるが面白みはそんなにない。目に見える絵だとそれはそれで楽しいような気がする。
作図の例(ルール90の場合
f:id:eiji8pou:20071126234240p:image

デメリット

できる絵が全然面白くないんですけど。げふん。これ区別つけろとか言われても無理だよなあ。

結論

なんかフィボナッチ当たりに決まりそうな雰囲気
次回は、ここからデータを取り出す方法について。

遺伝子型を展開する方法は常に差し替え可能状態を保つとする。その方が後々楽そうだから
しかし、画像のもの遺伝子型にすると言うアイデアも捨てがたい。

遺伝子の展開方法について

遺伝子物ゲーについて - 永字八法の続き。
昨日はあんなこと言ったけど、別にカオス限定しなくてもカオス的なものでいいよね(笑)

その1:みんな大好きMD5

遺伝子型の中からいくつかを選び、それを組み合わせて種として使う。MD5に食わせて出てきた数値を使い終わったら、最初の種と、使い終わった数字を組み合わせて次の数値をはじき出す。以下繰り返し。

メリット

カオス的には充分。

デメリット

NScripterで使うにはDLL必要になると思う。面倒。MD5の式って、NScripterネイティブ実装できるようなもんなのか?

その2:ちょっと数学的にフィボナッチ式

フィボナッチ数列は、第一項と第二項の初期値が1のものであればみんなよく知っていると思うけど。
これで第一項と第二項を1以外の実数にしてしまったらどうだろうか。ちょっと展開が面白いことにならないだろうか。
具体的には、こんな式か。
F¥small n+2¥Large =(F¥small n+1¥Large +F¥small n¥Large )¥small mod¥Large m
mには、10とか16とか256とかそれっぽい数値が入る。

メリット

一番展開が簡単。NScripterでもら〜くらく。

デメリット

あんまりカオスじゃない気がするんだけどどうよ?

その3:ロジスティック方程式

真打、真のカオス
F¥small n+1¥Large = aF¥small n¥Large(1-F¥small n¥Large)

メリット

カオス計算結構楽。

デメリット
  • 小数点以下が使えないと初期鋭敏性のうまみがなくなると言うか。値をそれぞれ百倍にして擬似的に端数処理してもいいんだけど。
  • aの値をどう設定するかが問題トップシークレットになるなあ。
  • そしてどんな数値にしたとしてもやがて収斂してしまう。しかしこれは利点かも知れないが……。

セルオートマトン

例えば、遺伝子型を示す文字列を全て2進数還元して、その上で1次元セルオートマトンルール30ないしルール90で展開して、タペストリーを作るとする。(参考:セル・オートマトン - Wikipedia
その作成されるタペストリーの模様から遺伝子情報を読み取ると言うのはどうだろう。プレイヤーにもそのタペストリーは見えるのだ。遺伝子型がただの文字列と言うのは、リアルではあるが面白みはそんなにない。目に見える絵だとそれはそれで楽しいような気がする。
作図の例(ルール90の場合
f:id:eiji8pou:20071126234240p:image

デメリット

できる絵が全然面白くないんですけど。げふん。これ区別つけろとか言われても無理だよなあ。

結論

なんかフィボナッチ当たりに決まりそうな雰囲気
次回は、ここからデータを取り出す方法について。

遺伝子型を展開する方法は常に差し替え可能状態を保つとする。その方が後々楽そうだから
しかし、画像のもの遺伝子型にすると言うアイデアも捨てがたい。

遺伝子の展開方法について

遺伝子物ゲーについて - 永字八法の続き。
昨日はあんなこと言ったけど、別にカオス限定しなくてもカオス的なものでいいよね(笑)

その1:みんな大好きMD5

遺伝子型の中からいくつかを選び、それを組み合わせて種として使う。MD5に食わせて出てきた数値を使い終わったら、最初の種と、使い終わった数字を組み合わせて次の数値をはじき出す。以下繰り返し。

メリット

カオス的には充分。

デメリット

NScripterで使うにはDLL必要になると思う。面倒。MD5の式って、NScripterネイティブ実装できるようなもんなのか?

その2:ちょっと数学的にフィボナッチ式

フィボナッチ数列は、第一項と第二項の初期値が1のものであればみんなよく知っていると思うけど。
これで第一項と第二項を1以外の実数にしてしまったらどうだろうか。ちょっと展開が面白いことにならないだろうか。
具体的には、こんな式か。
F¥small n+2¥Large =(F¥small n+1¥Large +F¥small n¥Large )¥small mod¥Large m
mには、10とか16とか256とかそれっぽい数値が入る。

メリット

一番展開が簡単。NScripterでもら〜くらく。

デメリット

あんまりカオスじゃない気がするんだけどどうよ?

その3:ロジスティック方程式

真打、真のカオス
F¥small n+1¥Large = aF¥small n¥Large(1-F¥small n¥Large)

メリット

カオス計算結構楽。

デメリット
  • 小数点以下が使えないと初期鋭敏性のうまみがなくなると言うか。値をそれぞれ百倍にして擬似的に端数処理してもいいんだけど。
  • aの値をどう設定するかが問題トップシークレットになるなあ。
  • そしてどんな数値にしたとしてもやがて収斂してしまう。しかしこれは利点かも知れないが……。

セルオートマトン

例えば、遺伝子型を示す文字列を全て2進数還元して、その上で1次元セルオートマトンルール30ないしルール90で展開して、タペストリーを作るとする。(参考:セル・オートマトン - Wikipedia
その作成されるタペストリーの模様から遺伝子情報を読み取ると言うのはどうだろう。プレイヤーにもそのタペストリーは見えるのだ。遺伝子型がただの文字列と言うのは、リアルではあるが面白みはそんなにない。目に見える絵だとそれはそれで楽しいような気がする。
作図の例(ルール90の場合
f:id:eiji8pou:20071126234240p:image

デメリット

できる絵が全然面白くないんですけど。げふん。これ区別つけろとか言われても無理だよなあ。

結論

なんかフィボナッチ当たりに決まりそうな雰囲気
次回は、ここからデータを取り出す方法について。

遺伝子型を展開する方法は常に差し替え可能状態を保つとする。その方が後々楽そうだから
しかし、画像のもの遺伝子型にすると言うアイデアも捨てがたい。

2007-11-25 Sunday

遺伝子物ゲーについて

遺伝子を扱ったゲームと言うものがある。ダビスタ代表されるようなものだ。この種のゲーム面白さは、遺伝子掛け合わせのトライエラーにあるだろう。そして真に面白いゲームは、製作者にとっても予測がつかず面白いものらしい。
そのような、(そして製作者にとっても楽な)アルゴリズムはないかと考えてみた。
まず条件として、遺伝子一定の長さの文字列表現されるべきだ。
そうすることで、子孫が容易に作り出せるからだ。ある桁について、両親のどちらかをランダムに受け継げばいい。
さて、ここまではいい。問題はここから先、遺伝子型の有限の文字列から無限に近い情報を取り出すと言う作業である
有限の文字列を種にして無限項(つまり必要なだけ)に展開でき、さらにその展開が予測不可能な式、などと言うものがこの世にあるのだろうか。
あった。カオスだ。
初期鋭敏性や予測不可能性など、カオス理論の特徴そのものである
次は実際にどのように適用するかを考えてみたい。

エラートラップ

クイズマジックアカデミーにおいて、同じ問題が二度続けて出題されたことがあると聞いた。
これについて、同席していた知人(プログラミング素人)が「同じ問題が選ばれたらキャンセルして違う問題取りに行くようにすればいいのに」とのたまった。
あ、いや、それは違うんじゃ、と言おうと思って色々考えた末に、逆にそれしかないんだと納得せざるを得なかったと言う話。
これを実現する手法としては三つのアプローチがある。

  1. 問題選択アプリが、同じ番号が続けて出ないようなアルゴリズムを使う
  2. フロントアプリが、問題選択アプリとの通信の際に、「前回この問題を使った」との情報を送る
  3. フロントアプリ側で、前回と同じ問題が来た場合キャンセルして再取得する仕組みを作る

これらのアプローチがどう違うかと言えば、番号が若いほどコストが低くなり、同時に確実性も減少していると言える。たとえば、3は確実性に関しては完全である。しかし、場合によっては何度でもループすることが考えられ、その分高コストになりうる。1ではループは考えられず、問題は一瞬で決まる。コストは最低である。しかしアルゴリズム実装問題で、条件を満たせないことが考えられる。確実性では劣るのだ。
では石橋を叩いて渡る、渡された引数の型を常に確認してからでないと安心してルーチンを組めない心配性にして普通プログラマーとしてはどうすべきか。正解は「全部実装する」だろう。
今回のマジアカバグは、結局のところ3を実装していれば防げた訳で、現象から判断して3は実装されていなかったに違いなく、プログラマーの用心が足りなかったと言うより他はない。
素人のように考え、玄人のように行動せよ」の見本のようだと思った次第。

遺伝子物ゲーについて

遺伝子を扱ったゲームと言うものがある。ダビスタ代表されるようなものだ。この種のゲーム面白さは、遺伝子掛け合わせのトライエラーにあるだろう。そして真に面白いゲームは、製作者にとっても予測がつかず面白いものらしい。
そのような、(そして製作者にとっても楽な)アルゴリズムはないかと考えてみた。
まず条件として、遺伝子一定の長さの文字列表現されるべきだ。
そうすることで、子孫が容易に作り出せるからだ。ある桁について、両親のどちらかをランダムに受け継げばいい。
さて、ここまではいい。問題はここから先、遺伝子型の有限の文字列から無限に近い情報を取り出すと言う作業である
有限の文字列を種にして無限項(つまり必要なだけ)に展開でき、さらにその展開が予測不可能な式、などと言うものがこの世にあるのだろうか。
あった。カオスだ。
初期鋭敏性や予測不可能性など、カオス理論の特徴そのものである
次は実際にどのように適用するかを考えてみたい。

エラートラップ

クイズマジックアカデミーにおいて、同じ問題が二度続けて出題されたことがあると聞いた。
これについて、同席していた知人(プログラミング素人)が「同じ問題が選ばれたらキャンセルして違う問題取りに行くようにすればいいのに」とのたまった。
あ、いや、それは違うんじゃ、と言おうと思って色々考えた末に、逆にそれしかないんだと納得せざるを得なかったと言う話。
これを実現する手法としては三つのアプローチがある。

  1. 問題選択アプリが、同じ番号が続けて出ないようなアルゴリズムを使う
  2. フロントアプリが、問題選択アプリとの通信の際に、「前回この問題を使った」との情報を送る
  3. フロントアプリ側で、前回と同じ問題が来た場合キャンセルして再取得する仕組みを作る

これらのアプローチがどう違うかと言えば、番号が若いほどコストが低くなり、同時に確実性も減少していると言える。たとえば、3は確実性に関しては完全である。しかし、場合によっては何度でもループすることが考えられ、その分高コストになりうる。1ではループは考えられず、問題は一瞬で決まる。コストは最低である。しかしアルゴリズム実装問題で、条件を満たせないことが考えられる。確実性では劣るのだ。
では石橋を叩いて渡る、渡された引数の型を常に確認してからでないと安心してルーチンを組めない心配性にして普通プログラマーとしてはどうすべきか。正解は「全部実装する」だろう。
今回のマジアカバグは、結局のところ3を実装していれば防げた訳で、現象から判断して3は実装されていなかったに違いなく、プログラマーの用心が足りなかったと言うより他はない。
素人のように考え、玄人のように行動せよ」の見本のようだと思った次第。

遺伝子物ゲーについて

遺伝子を扱ったゲームと言うものがある。ダビスタ代表されるようなものだ。この種のゲーム面白さは、遺伝子掛け合わせのトライエラーにあるだろう。そして真に面白いゲームは、製作者にとっても予測がつかず面白いものらしい。
そのような、(そして製作者にとっても楽な)アルゴリズムはないかと考えてみた。
まず条件として、遺伝子一定の長さの文字列表現されるべきだ。
そうすることで、子孫が容易に作り出せるからだ。ある桁について、両親のどちらかをランダムに受け継げばいい。
さて、ここまではいい。問題はここから先、遺伝子型の有限の文字列から無限に近い情報を取り出すと言う作業である
有限の文字列を種にして無限項(つまり必要なだけ)に展開でき、さらにその展開が予測不可能な式、などと言うものがこの世にあるのだろうか。
あった。カオスだ。
初期鋭敏性や予測不可能性など、カオス理論の特徴そのものである
次は実際にどのように適用するかを考えてみたい。

エラートラップ

クイズマジックアカデミーにおいて、同じ問題が二度続けて出題されたことがあると聞いた。
これについて、同席していた知人(プログラミング素人)が「同じ問題が選ばれたらキャンセルして違う問題取りに行くようにすればいいのに」とのたまった。
あ、いや、それは違うんじゃ、と言おうと思って色々考えた末に、逆にそれしかないんだと納得せざるを得なかったと言う話。
これを実現する手法としては三つのアプローチがある。

  1. 問題選択アプリが、同じ番号が続けて出ないようなアルゴリズムを使う
  2. フロントアプリが、問題選択アプリとの通信の際に、「前回この問題を使った」との情報を送る
  3. フロントアプリ側で、前回と同じ問題が来た場合キャンセルして再取得する仕組みを作る

これらのアプローチがどう違うかと言えば、番号が若いほどコストが低くなり、同時に確実性も減少していると言える。たとえば、3は確実性に関しては完全である。しかし、場合によっては何度でもループすることが考えられ、その分高コストになりうる。1ではループは考えられず、問題は一瞬で決まる。コストは最低である。しかしアルゴリズム実装問題で、条件を満たせないことが考えられる。確実性では劣るのだ。
では石橋を叩いて渡る、渡された引数の型を常に確認してからでないと安心してルーチンを組めない心配性にして普通プログラマーとしてはどうすべきか。正解は「全部実装する」だろう。
今回のマジアカバグは、結局のところ3を実装していれば防げた訳で、現象から判断して3は実装されていなかったに違いなく、プログラマーの用心が足りなかったと言うより他はない。
素人のように考え、玄人のように行動せよ」の見本のようだと思った次第。

2007-11-22 Thursday

ひとのわるさ

一度、やってみたいことがある。
かかってきた資格勧誘電話に対して、
「ノルマとかあるの?」「時給いくら?」「会社名とかどうなってんの?」「ノウハウ教えて」
とか、逆に聞いてみたい。
それと同様に、道でティッシュ配ってる人に対して、一分あたり一個ティッシュもらうからとか話つけて、具体的な数字の話を聞いてみたい。
そんなことを話したら、「どんだけ(人|性格|意地)が悪いんだ」とぶいぶい言われた。
ちぇ。

ペプシ算クラス

ペプシ算 - 永字八法の続き
ペプシ算のクラス作ってみた
※書き直した!

サンプルスクリプト

use Pepsi;
# 問題設定をする。
my $pepsi = Pepsi->new(
	kind=>5,	# 5種類のおまけつきを
	bottle=>12	# 1ダース買う
);
$pepsi->calc; # 計算する

my $result = $pepsi->total; # 計算結果を得る
# 計算結果は、何種類そろったかをキーとして確率を格納したハッシュリファレンス

# 計算結果を表示する。
print 'buy '.$pepsi->bottle." bottles.\n";
foreach my $get_kind ( sort { $a <=> $b } keys %{$result} ) {
	print 'get '.$get_kind.' kind(s) : %'.($result->{$get_kind}*100)."\n";
}

モジュール

package Pepsi;
use strict;
use bignum;
use base qw ( Class::Accessor );
__PACKAGE__->mk_accessors(qw(
	open_bottle
	bottle
	kind
	get_kind
	patern
));
sub new {
	my $invocant = shift;
	my $class = ref $invocant;
	$class ||= $invocant;
	my $self = bless {patern=>1, @_}=>$class;
	
	return $self;
}
sub rest_kind {
	my $self = shift;
	my $rest = $self->kind - $self->get_kind;
	return $rest;
}
sub calc {
	my $self = shift;
	$self->is_end and return;
	my @child = ();
	push @child, $self->new(
		open_bottle=>(1+$self->open_bottle),
		bottle=>$self->bottle,
		kind=>$self->kind,
		get_kind=>(1+$self->get_kind),
		patern=>($self->rest_kind * $self->patern)
	); # 新種が出た場合&最初の一本は必ず新種
	if ( $self->open_bottle > 0 ) {
		push @child, $self->new(
			open_bottle=>(1+$self->open_bottle),
			bottle=>$self->bottle,
			kind=>$self->kind,
			get_kind=>$self->get_kind,
			patern=>($self->get_kind * $self->patern)
		); # 新種が出なかった場合
	}
	$self->{child} = \@child;
	map { $_->calc } @child;
	return 1;
}
sub is_end {
	my $self = shift;
	$self->get_kind < $self->kind or return 1;
	$self->open_bottle < $self->bottle or return 1;
	return undef;
}
sub is_live {
	return shift->is_end ? undef : 1;
}
sub ends {
	my $self = shift;
	my $result = shift;
	$result ||= [];
	if ( $self->{child} ) {
		map { $_->ends($result) } @{$self->{child}};
	} else {
		push @{$result}, $self;
#		print "End!\n";
	}
	return $result;
}
sub fraction {
	my $self = shift;
	my $patern = $self->patern;
	my $open_bottle = $self->open_bottle;
	while ( $open_bottle < $self->bottle ) {
		$patern *= $self->kind;
		++ $open_bottle;
	}
	return $patern;
}
sub total_child {
	my $self = shift;
	my %hash = ();
	map { $hash{$_->get_kind} += $_->fraction } @{$self->ends};
	return \%hash;
}
sub total_mother {
	my $self = shift;
	return $self->kind ** $self->bottle;
}
sub total {
	my $self = shift;
	my $child = $self->total_child;
	my $mother = $self->total_mother;
	foreach my $num ( keys %{$child} ) {
		$child->{$num} /= $mother;
	}
	return $child;
}
1;

考え方

まず、0種類の食玩がそろっているとする。
最初のボトルをあけると、0が1になる。
次のボトルをあけると、この1が1のままか2になるか、分岐が発生する。
ボトルがそろうか、全部開けてしまうかするまで、このツリーを全て調べる。

やってみた感想

再帰を使っているので、ちょっと数が大きくなると死ぬほど時間がかかるようになります。
なので、今度は再帰を使わない方法を思いついたのでそれを実装中。

ペプシ算ファイナル

サンプルスクリプト

use Pepsi;
# 問題設定をする。
my $pepsi = Pepsi->new(
	kind=>5	# 5種類のおまけつき食玩具
);
print $pepsi->percent(10); # 10本あけて、コンプする確率は?
print "\n";
print $pepsi->limit(0.9); # では、コンプ率が90%を超えるのは何本から?
print "\n";
print $pepsi->limit(0.95); # では、コンプ率が95%を超えるのは何本から?
print "\n";
my $res = $pepsi->probability(15); # 15本開けた時、どんな確率で何種類集まる?
my $num = 0;
foreach my $proba ( @{$res} ) {
	print 'get '.$num.' kind(s) : % '.$proba."\n";
	++ $num;
}
print "\n";
$res = $pepsi->get_patern(15); # 同じ内容を、分母で割る前の値で取得したい。
$num = 0;
foreach my $proba ( @{$res} ) {
	print 'get '.$num.' kind(s) : % '.$proba."\n";
	++ $num;
}
print "\n";
print $pepsi->mother(15); # その時の分母を取得する。

実行結果

0.5225472
18
21
get 0 kind(s) : % 0
get 1 kind(s) : % 0.00000000016384
get 2 kind(s) : % 0.00001073676288
get 3 kind(s) : % 0.00466963857408
get 4 kind(s) : % 0.166550372352
get 5 kind(s) : % 0.8287692521472

get 0 kind(s) : %
get 1 kind(s) : % 5
get 2 kind(s) : % 327660
get 3 kind(s) : % 142506060
get 4 kind(s) : % 5082714000
get 5 kind(s) : % 25292030400

30517578125

モジュール

package Pepsi;
use strict;
use bignum;
use base qw ( Class::Accessor );
__PACKAGE__->mk_accessors(qw(
	bottle
	kind
));
sub new {
	my $invocant = shift;
	my $class = ref $invocant;
	$class ||= $invocant;
	my $self = bless {@_}=>$class;
	$self->init;
	return $self;
}
sub open_bottle {
	my $self = shift;
	my $now_bottle = $self->bottle;
	my $next_bottle = $now_bottle + 1;
	foreach my $kind ( 0..$self->kind ) {
		# かぶる場合
		my $new_num = $self->{table}->[$now_bottle]->[$kind] * $kind;
		$new_num and $self->{table}->[$next_bottle]->[$kind] += $new_num;
		# 新しい種類が出る場合
		$new_num = $self->{table}->[$now_bottle]->[$kind] * ($self->kind - $kind);
		$new_num and $self->{table}->[$next_bottle]->[$kind+1] += $new_num;
	}
	++ $self->{bottle};
}
sub get_patern {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	$bottle += 0;
	until ( $self->{table}->[$bottle] ) {
		$self->open_bottle;
	}
	return $self->{table}->[$bottle];
}
sub percent {
	my $self = shift;
	my ( $bottle, $kind ) = ();
	@_ and ( $bottle, $kind ) = @_;
	$bottle ||= $self->bottle;
	$kind ||= $self->kind;
	my $patern = $self->get_patern($bottle);
	my $result = $patern->[$kind];
	$result /= $self->mother($bottle);
	return $result;
}
sub probability {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	my $patern = $self->get_patern($bottle);
	my $mother = $self->mother($bottle);
	my @res = @{$patern};
	map { $_ /= $mother } @res;
	return \@res;
}
sub limit {
	my $self = shift;
	my $limit = shift;
	$limit ||= 0.9;
	my $bottle = 1;
	while ( $self->percent($bottle) < $limit ) {
		++ $bottle;
	}
	return $bottle;
}
sub mother {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	$bottle += 0;
	$self->{mother}->[$bottle] ||= $self->mother($bottle-1) * $self->kind;
	return $self->{mother}->[$bottle];
}
sub init {
	my $self = shift;
	$self->{bottle} = 0;
	$self->{mother} = [1];
	$self->{table} = [[1]];
}
1;

解説

もっとブラックボックス化できた。
食玩の種類数を指定するだけで、必要数字を取得できるようにした。ひゃっほう。

感想

でもさあ、よく考えたら、今の食玩って中身まる見えでないといけないんだよね。コンプするのに買い込む必要がないと言うか……。

ひとのわるさ

一度、やってみたいことがある。
かかってきた資格勧誘電話に対して、
「ノルマとかあるの?」「時給いくら?」「会社名とかどうなってんの?」「ノウハウ教えて」
とか、逆に聞いてみたい。
それと同様に、道でティッシュ配ってる人に対して、一分あたり一個ティッシュもらうからとか話つけて、具体的な数字の話を聞いてみたい。
そんなことを話したら、「どんだけ(人|性格|意地)が悪いんだ」とぶいぶい言われた。
ちぇ。

ペプシ算クラス

ペプシ算 - 永字八法の続き
ペプシ算のクラス作ってみた
※書き直した!

サンプルスクリプト

use Pepsi;
# 問題設定をする。
my $pepsi = Pepsi->new(
	kind=>5,	# 5種類のおまけつきを
	bottle=>12	# 1ダース買う
);
$pepsi->calc; # 計算する

my $result = $pepsi->total; # 計算結果を得る
# 計算結果は、何種類そろったかをキーとして確率を格納したハッシュリファレンス

# 計算結果を表示する。
print 'buy '.$pepsi->bottle." bottles.\n";
foreach my $get_kind ( sort { $a <=> $b } keys %{$result} ) {
	print 'get '.$get_kind.' kind(s) : %'.($result->{$get_kind}*100)."\n";
}

モジュール

package Pepsi;
use strict;
use bignum;
use base qw ( Class::Accessor );
__PACKAGE__->mk_accessors(qw(
	open_bottle
	bottle
	kind
	get_kind
	patern
));
sub new {
	my $invocant = shift;
	my $class = ref $invocant;
	$class ||= $invocant;
	my $self = bless {patern=>1, @_}=>$class;
	
	return $self;
}
sub rest_kind {
	my $self = shift;
	my $rest = $self->kind - $self->get_kind;
	return $rest;
}
sub calc {
	my $self = shift;
	$self->is_end and return;
	my @child = ();
	push @child, $self->new(
		open_bottle=>(1+$self->open_bottle),
		bottle=>$self->bottle,
		kind=>$self->kind,
		get_kind=>(1+$self->get_kind),
		patern=>($self->rest_kind * $self->patern)
	); # 新種が出た場合&最初の一本は必ず新種
	if ( $self->open_bottle > 0 ) {
		push @child, $self->new(
			open_bottle=>(1+$self->open_bottle),
			bottle=>$self->bottle,
			kind=>$self->kind,
			get_kind=>$self->get_kind,
			patern=>($self->get_kind * $self->patern)
		); # 新種が出なかった場合
	}
	$self->{child} = \@child;
	map { $_->calc } @child;
	return 1;
}
sub is_end {
	my $self = shift;
	$self->get_kind < $self->kind or return 1;
	$self->open_bottle < $self->bottle or return 1;
	return undef;
}
sub is_live {
	return shift->is_end ? undef : 1;
}
sub ends {
	my $self = shift;
	my $result = shift;
	$result ||= [];
	if ( $self->{child} ) {
		map { $_->ends($result) } @{$self->{child}};
	} else {
		push @{$result}, $self;
#		print "End!\n";
	}
	return $result;
}
sub fraction {
	my $self = shift;
	my $patern = $self->patern;
	my $open_bottle = $self->open_bottle;
	while ( $open_bottle < $self->bottle ) {
		$patern *= $self->kind;
		++ $open_bottle;
	}
	return $patern;
}
sub total_child {
	my $self = shift;
	my %hash = ();
	map { $hash{$_->get_kind} += $_->fraction } @{$self->ends};
	return \%hash;
}
sub total_mother {
	my $self = shift;
	return $self->kind ** $self->bottle;
}
sub total {
	my $self = shift;
	my $child = $self->total_child;
	my $mother = $self->total_mother;
	foreach my $num ( keys %{$child} ) {
		$child->{$num} /= $mother;
	}
	return $child;
}
1;

考え方

まず、0種類の食玩がそろっているとする。
最初のボトルをあけると、0が1になる。
次のボトルをあけると、この1が1のままか2になるか、分岐が発生する。
ボトルがそろうか、全部開けてしまうかするまで、このツリーを全て調べる。

やってみた感想

再帰を使っているので、ちょっと数が大きくなると死ぬほど時間がかかるようになります。
なので、今度は再帰を使わない方法を思いついたのでそれを実装中。

ペプシ算ファイナル

サンプルスクリプト

use Pepsi;
# 問題設定をする。
my $pepsi = Pepsi->new(
	kind=>5	# 5種類のおまけつき食玩具
);
print $pepsi->percent(10); # 10本あけて、コンプする確率は?
print "\n";
print $pepsi->limit(0.9); # では、コンプ率が90%を超えるのは何本から?
print "\n";
print $pepsi->limit(0.95); # では、コンプ率が95%を超えるのは何本から?
print "\n";
my $res = $pepsi->probability(15); # 15本開けた時、どんな確率で何種類集まる?
my $num = 0;
foreach my $proba ( @{$res} ) {
	print 'get '.$num.' kind(s) : % '.$proba."\n";
	++ $num;
}
print "\n";
$res = $pepsi->get_patern(15); # 同じ内容を、分母で割る前の値で取得したい。
$num = 0;
foreach my $proba ( @{$res} ) {
	print 'get '.$num.' kind(s) : % '.$proba."\n";
	++ $num;
}
print "\n";
print $pepsi->mother(15); # その時の分母を取得する。

実行結果

0.5225472
18
21
get 0 kind(s) : % 0
get 1 kind(s) : % 0.00000000016384
get 2 kind(s) : % 0.00001073676288
get 3 kind(s) : % 0.00466963857408
get 4 kind(s) : % 0.166550372352
get 5 kind(s) : % 0.8287692521472

get 0 kind(s) : %
get 1 kind(s) : % 5
get 2 kind(s) : % 327660
get 3 kind(s) : % 142506060
get 4 kind(s) : % 5082714000
get 5 kind(s) : % 25292030400

30517578125

モジュール

package Pepsi;
use strict;
use bignum;
use base qw ( Class::Accessor );
__PACKAGE__->mk_accessors(qw(
	bottle
	kind
));
sub new {
	my $invocant = shift;
	my $class = ref $invocant;
	$class ||= $invocant;
	my $self = bless {@_}=>$class;
	$self->init;
	return $self;
}
sub open_bottle {
	my $self = shift;
	my $now_bottle = $self->bottle;
	my $next_bottle = $now_bottle + 1;
	foreach my $kind ( 0..$self->kind ) {
		# かぶる場合
		my $new_num = $self->{table}->[$now_bottle]->[$kind] * $kind;
		$new_num and $self->{table}->[$next_bottle]->[$kind] += $new_num;
		# 新しい種類が出る場合
		$new_num = $self->{table}->[$now_bottle]->[$kind] * ($self->kind - $kind);
		$new_num and $self->{table}->[$next_bottle]->[$kind+1] += $new_num;
	}
	++ $self->{bottle};
}
sub get_patern {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	$bottle += 0;
	until ( $self->{table}->[$bottle] ) {
		$self->open_bottle;
	}
	return $self->{table}->[$bottle];
}
sub percent {
	my $self = shift;
	my ( $bottle, $kind ) = ();
	@_ and ( $bottle, $kind ) = @_;
	$bottle ||= $self->bottle;
	$kind ||= $self->kind;
	my $patern = $self->get_patern($bottle);
	my $result = $patern->[$kind];
	$result /= $self->mother($bottle);
	return $result;
}
sub probability {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	my $patern = $self->get_patern($bottle);
	my $mother = $self->mother($bottle);
	my @res = @{$patern};
	map { $_ /= $mother } @res;
	return \@res;
}
sub limit {
	my $self = shift;
	my $limit = shift;
	$limit ||= 0.9;
	my $bottle = 1;
	while ( $self->percent($bottle) < $limit ) {
		++ $bottle;
	}
	return $bottle;
}
sub mother {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	$bottle += 0;
	$self->{mother}->[$bottle] ||= $self->mother($bottle-1) * $self->kind;
	return $self->{mother}->[$bottle];
}
sub init {
	my $self = shift;
	$self->{bottle} = 0;
	$self->{mother} = [1];
	$self->{table} = [[1]];
}
1;

解説

もっとブラックボックス化できた。
食玩の種類数を指定するだけで、必要数字を取得できるようにした。ひゃっほう。

感想

でもさあ、よく考えたら、今の食玩って中身まる見えでないといけないんだよね。コンプするのに買い込む必要がないと言うか……。

ひとのわるさ

一度、やってみたいことがある。
かかってきた資格勧誘電話に対して、
「ノルマとかあるの?」「時給いくら?」「会社名とかどうなってんの?」「ノウハウ教えて」
とか、逆に聞いてみたい。
それと同様に、道でティッシュ配ってる人に対して、一分あたり一個ティッシュもらうからとか話つけて、具体的な数字の話を聞いてみたい。
そんなことを話したら、「どんだけ(人|性格|意地)が悪いんだ」とぶいぶい言われた。
ちぇ。

ペプシ算クラス

ペプシ算 - 永字八法の続き
ペプシ算のクラス作ってみた
※書き直した!

サンプルスクリプト

use Pepsi;
# 問題設定をする。
my $pepsi = Pepsi->new(
	kind=>5,	# 5種類のおまけつきを
	bottle=>12	# 1ダース買う
);
$pepsi->calc; # 計算する

my $result = $pepsi->total; # 計算結果を得る
# 計算結果は、何種類そろったかをキーとして確率を格納したハッシュリファレンス

# 計算結果を表示する。
print 'buy '.$pepsi->bottle." bottles.\n";
foreach my $get_kind ( sort { $a <=> $b } keys %{$result} ) {
	print 'get '.$get_kind.' kind(s) : %'.($result->{$get_kind}*100)."\n";
}

モジュール

package Pepsi;
use strict;
use bignum;
use base qw ( Class::Accessor );
__PACKAGE__->mk_accessors(qw(
	open_bottle
	bottle
	kind
	get_kind
	patern
));
sub new {
	my $invocant = shift;
	my $class = ref $invocant;
	$class ||= $invocant;
	my $self = bless {patern=>1, @_}=>$class;
	
	return $self;
}
sub rest_kind {
	my $self = shift;
	my $rest = $self->kind - $self->get_kind;
	return $rest;
}
sub calc {
	my $self = shift;
	$self->is_end and return;
	my @child = ();
	push @child, $self->new(
		open_bottle=>(1+$self->open_bottle),
		bottle=>$self->bottle,
		kind=>$self->kind,
		get_kind=>(1+$self->get_kind),
		patern=>($self->rest_kind * $self->patern)
	); # 新種が出た場合&最初の一本は必ず新種
	if ( $self->open_bottle > 0 ) {
		push @child, $self->new(
			open_bottle=>(1+$self->open_bottle),
			bottle=>$self->bottle,
			kind=>$self->kind,
			get_kind=>$self->get_kind,
			patern=>($self->get_kind * $self->patern)
		); # 新種が出なかった場合
	}
	$self->{child} = \@child;
	map { $_->calc } @child;
	return 1;
}
sub is_end {
	my $self = shift;
	$self->get_kind < $self->kind or return 1;
	$self->open_bottle < $self->bottle or return 1;
	return undef;
}
sub is_live {
	return shift->is_end ? undef : 1;
}
sub ends {
	my $self = shift;
	my $result = shift;
	$result ||= [];
	if ( $self->{child} ) {
		map { $_->ends($result) } @{$self->{child}};
	} else {
		push @{$result}, $self;
#		print "End!\n";
	}
	return $result;
}
sub fraction {
	my $self = shift;
	my $patern = $self->patern;
	my $open_bottle = $self->open_bottle;
	while ( $open_bottle < $self->bottle ) {
		$patern *= $self->kind;
		++ $open_bottle;
	}
	return $patern;
}
sub total_child {
	my $self = shift;
	my %hash = ();
	map { $hash{$_->get_kind} += $_->fraction } @{$self->ends};
	return \%hash;
}
sub total_mother {
	my $self = shift;
	return $self->kind ** $self->bottle;
}
sub total {
	my $self = shift;
	my $child = $self->total_child;
	my $mother = $self->total_mother;
	foreach my $num ( keys %{$child} ) {
		$child->{$num} /= $mother;
	}
	return $child;
}
1;

考え方

まず、0種類の食玩がそろっているとする。
最初のボトルをあけると、0が1になる。
次のボトルをあけると、この1が1のままか2になるか、分岐が発生する。
ボトルがそろうか、全部開けてしまうかするまで、このツリーを全て調べる。

やってみた感想

再帰を使っているので、ちょっと数が大きくなると死ぬほど時間がかかるようになります。
なので、今度は再帰を使わない方法を思いついたのでそれを実装中。

ペプシ算ファイナル

サンプルスクリプト

use Pepsi;
# 問題設定をする。
my $pepsi = Pepsi->new(
	kind=>5	# 5種類のおまけつき食玩具
);
print $pepsi->percent(10); # 10本あけて、コンプする確率は?
print "\n";
print $pepsi->limit(0.9); # では、コンプ率が90%を超えるのは何本から?
print "\n";
print $pepsi->limit(0.95); # では、コンプ率が95%を超えるのは何本から?
print "\n";
my $res = $pepsi->probability(15); # 15本開けた時、どんな確率で何種類集まる?
my $num = 0;
foreach my $proba ( @{$res} ) {
	print 'get '.$num.' kind(s) : % '.$proba."\n";
	++ $num;
}
print "\n";
$res = $pepsi->get_patern(15); # 同じ内容を、分母で割る前の値で取得したい。
$num = 0;
foreach my $proba ( @{$res} ) {
	print 'get '.$num.' kind(s) : % '.$proba."\n";
	++ $num;
}
print "\n";
print $pepsi->mother(15); # その時の分母を取得する。

実行結果

0.5225472
18
21
get 0 kind(s) : % 0
get 1 kind(s) : % 0.00000000016384
get 2 kind(s) : % 0.00001073676288
get 3 kind(s) : % 0.00466963857408
get 4 kind(s) : % 0.166550372352
get 5 kind(s) : % 0.8287692521472

get 0 kind(s) : %
get 1 kind(s) : % 5
get 2 kind(s) : % 327660
get 3 kind(s) : % 142506060
get 4 kind(s) : % 5082714000
get 5 kind(s) : % 25292030400

30517578125

モジュール

package Pepsi;
use strict;
use bignum;
use base qw ( Class::Accessor );
__PACKAGE__->mk_accessors(qw(
	bottle
	kind
));
sub new {
	my $invocant = shift;
	my $class = ref $invocant;
	$class ||= $invocant;
	my $self = bless {@_}=>$class;
	$self->init;
	return $self;
}
sub open_bottle {
	my $self = shift;
	my $now_bottle = $self->bottle;
	my $next_bottle = $now_bottle + 1;
	foreach my $kind ( 0..$self->kind ) {
		# かぶる場合
		my $new_num = $self->{table}->[$now_bottle]->[$kind] * $kind;
		$new_num and $self->{table}->[$next_bottle]->[$kind] += $new_num;
		# 新しい種類が出る場合
		$new_num = $self->{table}->[$now_bottle]->[$kind] * ($self->kind - $kind);
		$new_num and $self->{table}->[$next_bottle]->[$kind+1] += $new_num;
	}
	++ $self->{bottle};
}
sub get_patern {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	$bottle += 0;
	until ( $self->{table}->[$bottle] ) {
		$self->open_bottle;
	}
	return $self->{table}->[$bottle];
}
sub percent {
	my $self = shift;
	my ( $bottle, $kind ) = ();
	@_ and ( $bottle, $kind ) = @_;
	$bottle ||= $self->bottle;
	$kind ||= $self->kind;
	my $patern = $self->get_patern($bottle);
	my $result = $patern->[$kind];
	$result /= $self->mother($bottle);
	return $result;
}
sub probability {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	my $patern = $self->get_patern($bottle);
	my $mother = $self->mother($bottle);
	my @res = @{$patern};
	map { $_ /= $mother } @res;
	return \@res;
}
sub limit {
	my $self = shift;
	my $limit = shift;
	$limit ||= 0.9;
	my $bottle = 1;
	while ( $self->percent($bottle) < $limit ) {
		++ $bottle;
	}
	return $bottle;
}
sub mother {
	my $self = shift;
	my $bottle = undef;
	if ( @_ ) {
		$bottle = shift;
	} else {
		$bottle = $self->bottle;
	}
	$bottle += 0;
	$self->{mother}->[$bottle] ||= $self->mother($bottle-1) * $self->kind;
	return $self->{mother}->[$bottle];
}
sub init {
	my $self = shift;
	$self->{bottle} = 0;
	$self->{mother} = [1];
	$self->{table} = [[1]];
}
1;

解説

もっとブラックボックス化できた。
食玩の種類数を指定するだけで、必要数字を取得できるようにした。ひゃっほう。

感想

でもさあ、よく考えたら、今の食玩って中身まる見えでないといけないんだよね。コンプするのに買い込む必要がないと言うか……。

2007-11-19 Monday

2007-11-17 Saturday このエントリーを含むブックマーク このエントリーのブックマークコメント

2007-11-16 Friday

面倒だ。

私が管理するここではないあるサイトは、なんか別のwikiを入れているんだが、そのwikiコメントシステムがすごいことになっているのに気付いた。
私が管理するのはシステムであって、コンテンツ管理するのは別の人間だ。そのコンテンツ管理人から連絡を受けて、SPAMコメントを削除してくれと言われたのだが、えっとこれまたこまったな。

ちょっと方法を調べるうちにタイムアップ気味。つか眠い

面倒だ。

私が管理するここではないあるサイトは、なんか別のwikiを入れているんだが、そのwikiコメントシステムがすごいことになっているのに気付いた。
私が管理するのはシステムであって、コンテンツ管理するのは別の人間だ。そのコンテンツ管理人から連絡を受けて、SPAMコメントを削除してくれと言われたのだが、えっとこれまたこまったな。

ちょっと方法を調べるうちにタイムアップ気味。つか眠い

面倒だ。

私が管理するここではないあるサイトは、なんか別のwikiを入れているんだが、そのwikiコメントシステムがすごいことになっているのに気付いた。
私が管理するのはシステムであって、コンテンツ管理するのは別の人間だ。そのコンテンツ管理人から連絡を受けて、SPAMコメントを削除してくれと言われたのだが、えっとこれまたこまったな。

ちょっと方法を調べるうちにタイムアップ気味。つか眠い

2007-11-12 Monday

2007-11-07 Wednesday

2007-11-06 Tuesday

日常に潜むアレ

ちょっと特殊パソコン教室みたいな状況にて。
見るとはなしに見たら、隣の席の奴が、ニューウェイズサイトを開いてIDパスワード入力していた。ディストリビューターなんとかって。背筋に寒気が走った。本気でやってる奴なんていたんだ。
一方俺は、悪徳商法?マニアックスを大急ぎで開いた。

職場に先日かかってきた電話

アパートを買わないかって話だった。
ターゲット退職間近のうちのボスだったんだが、丁度いなかったんで、俺がお相手してみた。
業者アパートを買いませんか?」
俺「儲かるんならあなたが買ったらいいんじゃないですか?」
これはセールス系に対する万能かつ定番切り返しなのだが、最近業者はこれくらいでは動じないらしい。既に想定問答ができているようだ。
業者「○○工場の人が、自分とこで作った○○を全部消費するなんておかしな話じゃありませんか?」
ちょっと納得しそうになった。
俺「んーでも、作った人間が欲しいと思わないようなものを売りつけるのもどうなんでしょうか」
業者ぶっちゃけると、公務員さんにしか売れない、公務員さんだからこういう値段設定ができるんですよ。だから私は買えないんです」
優越感をくすぐるセリフ。
業者「他にもたくさんの方に買っていただいておりまして……」
極論すれば一つも売れてなくても「たくさんの方に売れている」とは言える。ここで「じゃあ誰に」と聞いても「個人情報」の錦の御旗に阻まれる。
俺「しかしねえ、その公務員ってのが曲者でねえ。副職とか兼業ってのは……」
業者「あ、それは大丈夫です。○棟○室までなら、副業とは認められないんです」
大丈夫とか言うセリフが出たら要注意だ。誰がそう言ったのかをつっこんでみよう。
俺「それ、誰が言ったの?」
業者「は?」
俺「いや、その○棟○室? までなら大丈夫って、誰が言ったの?」
業者「いえその、皆さんそれで運営してらっしゃるんですが」
俺「他人関係ないって。それで大丈夫だってのは、どこの法律だか判例だかを根拠に、誰がそう言ったのかって聞いてるんですよ」
業者「えーそれはちょっと……」
俺「自分がやってることの法的な裏付けも知らなくて人に物勧めてた訳?」
公務員が法律で騙されたなんてのは、新聞記事にしても面白くないし恥かしい。
業者「じゃあ、資料全部集めたら買ってくれますか?」
俺「買うとは言ってない。検討くらいはしてもいい。ま、俺程度でそちらの審査に通るとしたらむしろその審査を疑うけどね」
そこでリアルで他に電話がかかってきたので、強制的電話を切った。
以来、同じ業者から電話はかかってこない。
参考:2log.net

日常に潜むアレその2

カラオケボックスにて。
集まった友人のうち一人が、実話系雑誌の出した心霊ムックを買ってきて、それをパラパラめくったりなんだりしてちょっとそれ系の気分が出ていた時のこと。
突然携帯電話がかかってきた。ナンバーディスプレイには「公衆電話」としか出ていなかった。今時一体誰が?と訝りつつも電話に出た。
「××××」
「あの、もしもし?」
「××××(同じセリフ)」
何度か繰り返した後、周囲から、外で話せとジェスチャーされて廊下に出る。
「あの、どちらですか? どちらにおかけですか?」
廊下に出ると、やっと少しずつ聞き取れ始めた。相手は男性。外からかけているので風が強いのか、機械が古いのか、雑音が酷い。
「×××失敗××」(同じセリフ!)
「は?」
「×××は失敗しました」(同じセリフなんだよお!)
確かに、「失敗」とか聞こえた。流石に恐ろしい物を感じ始めた。
「あの、どちらにおかけですか? どなたですか? もしもし!」
やがて、プーと言う警告音がしてから電話自然に切れた。

日常に潜むアレ

ちょっと特殊パソコン教室みたいな状況にて。
見るとはなしに見たら、隣の席の奴が、ニューウェイズサイトを開いてIDパスワード入力していた。ディストリビューターなんとかって。背筋に寒気が走った。本気でやってる奴なんていたんだ。
一方俺は、悪徳商法?マニアックスを大急ぎで開いた。

職場に先日かかってきた電話

アパートを買わないかって話だった。
ターゲット退職間近のうちのボスだったんだが、丁度いなかったんで、俺がお相手してみた。
業者アパートを買いませんか?」
俺「儲かるんならあなたが買ったらいいんじゃないですか?」
これはセールス系に対する万能かつ定番切り返しなのだが、最近業者はこれくらいでは動じないらしい。既に想定問答ができているようだ。
業者「○○工場の人が、自分とこで作った○○を全部消費するなんておかしな話じゃありませんか?」
ちょっと納得しそうになった。
俺「んーでも、作った人間が欲しいと思わないようなものを売りつけるのもどうなんでしょうか」
業者ぶっちゃけると、公務員さんにしか売れない、公務員さんだからこういう値段設定ができるんですよ。だから私は買えないんです」
優越感をくすぐるセリフ。
業者「他にもたくさんの方に買っていただいておりまして……」
極論すれば一つも売れてなくても「たくさんの方に売れている」とは言える。ここで「じゃあ誰に」と聞いても「個人情報」の錦の御旗に阻まれる。
俺「しかしねえ、その公務員ってのが曲者でねえ。副職とか兼業ってのは……」
業者「あ、それは大丈夫です。○棟○室までなら、副業とは認められないんです」
大丈夫とか言うセリフが出たら要注意だ。誰がそう言ったのかをつっこんでみよう。
俺「それ、誰が言ったの?」
業者「は?」
俺「いや、その○棟○室? までなら大丈夫って、誰が言ったの?」
業者「いえその、皆さんそれで運営してらっしゃるんですが」
俺「他人関係ないって。それで大丈夫だってのは、どこの法律だか判例だかを根拠に、誰がそう言ったのかって聞いてるんですよ」
業者「えーそれはちょっと……」
俺「自分がやってることの法的な裏付けも知らなくて人に物勧めてた訳?」
公務員が法律で騙されたなんてのは、新聞記事にしても面白くないし恥かしい。
業者「じゃあ、資料全部集めたら買ってくれますか?」
俺「買うとは言ってない。検討くらいはしてもいい。ま、俺程度でそちらの審査に通るとしたらむしろその審査を疑うけどね」
そこでリアルで他に電話がかかってきたので、強制的電話を切った。
以来、同じ業者から電話はかかってこない。
参考:2log.net

日常に潜むアレその2

カラオケボックスにて。
集まった友人のうち一人が、実話系雑誌の出した心霊ムックを買ってきて、それをパラパラめくったりなんだりしてちょっとそれ系の気分が出ていた時のこと。
突然携帯電話がかかってきた。ナンバーディスプレイには「公衆電話」としか出ていなかった。今時一体誰が?と訝りつつも電話に出た。
「××××」
「あの、もしもし?」
「××××(同じセリフ)」
何度か繰り返した後、周囲から、外で話せとジェスチャーされて廊下に出る。
「あの、どちらですか? どちらにおかけですか?」
廊下に出ると、やっと少しずつ聞き取れ始めた。相手は男性。外からかけているので風が強いのか、機械が古いのか、雑音が酷い。
「×××失敗××」(同じセリフ!)
「は?」
「×××は失敗しました」(同じセリフなんだよお!)
確かに、「失敗」とか聞こえた。流石に恐ろしい物を感じ始めた。
「あの、どちらにおかけですか? どなたですか? もしもし!」
やがて、プーと言う警告音がしてから電話自然に切れた。

日常に潜むアレ

ちょっと特殊パソコン教室みたいな状況にて。
見るとはなしに見たら、隣の席の奴が、ニューウェイズサイトを開いてIDパスワード入力していた。ディストリビューターなんとかって。背筋に寒気が走った。本気でやってる奴なんていたんだ。
一方俺は、悪徳商法?マニアックスを大急ぎで開いた。

職場に先日かかってきた電話

アパートを買わないかって話だった。
ターゲット退職間近のうちのボスだったんだが、丁度いなかったんで、俺がお相手してみた。
業者アパートを買いませんか?」
俺「儲かるんならあなたが買ったらいいんじゃないですか?」
これはセールス系に対する万能かつ定番切り返しなのだが、最近業者はこれくらいでは動じないらしい。既に想定問答ができているようだ。
業者「○○工場の人が、自分とこで作った○○を全部消費するなんておかしな話じゃありませんか?」
ちょっと納得しそうになった。
俺「んーでも、作った人間が欲しいと思わないようなものを売りつけるのもどうなんでしょうか」
業者ぶっちゃけると、公務員さんにしか売れない、公務員さんだからこういう値段設定ができるんですよ。だから私は買えないんです」
優越感をくすぐるセリフ。
業者「他にもたくさんの方に買っていただいておりまして……」
極論すれば一つも売れてなくても「たくさんの方に売れている」とは言える。ここで「じゃあ誰に」と聞いても「個人情報」の錦の御旗に阻まれる。
俺「しかしねえ、その公務員ってのが曲者でねえ。副職とか兼業ってのは……」
業者「あ、それは大丈夫です。○棟○室までなら、副業とは認められないんです」
大丈夫とか言うセリフが出たら要注意だ。誰がそう言ったのかをつっこんでみよう。
俺「それ、誰が言ったの?」
業者「は?」
俺「いや、その○棟○室? までなら大丈夫って、誰が言ったの?」
業者「いえその、皆さんそれで運営してらっしゃるんですが」
俺「他人関係ないって。それで大丈夫だってのは、どこの法律だか判例だかを根拠に、誰がそう言ったのかって聞いてるんですよ」
業者「えーそれはちょっと……」
俺「自分がやってることの法的な裏付けも知らなくて人に物勧めてた訳?」
公務員が法律で騙されたなんてのは、新聞記事にしても面白くないし恥かしい。
業者「じゃあ、資料全部集めたら買ってくれますか?」
俺「買うとは言ってない。検討くらいはしてもいい。ま、俺程度でそちらの審査に通るとしたらむしろその審査を疑うけどね」
そこでリアルで他に電話がかかってきたので、強制的電話を切った。
以来、同じ業者から電話はかかってこない。
参考:2log.net

日常に潜むアレその2

カラオケボックスにて。
集まった友人のうち一人が、実話系雑誌の出した心霊ムックを買ってきて、それをパラパラめくったりなんだりしてちょっとそれ系の気分が出ていた時のこと。
突然携帯電話がかかってきた。ナンバーディスプレイには「公衆電話」としか出ていなかった。今時一体誰が?と訝りつつも電話に出た。
「××××」
「あの、もしもし?」
「××××(同じセリフ)」
何度か繰り返した後、周囲から、外で話せとジェスチャーされて廊下に出る。
「あの、どちらですか? どちらにおかけですか?」
廊下に出ると、やっと少しずつ聞き取れ始めた。相手は男性。外からかけているので風が強いのか、機械が古いのか、雑音が酷い。
「×××失敗××」(同じセリフ!)
「は?」
「×××は失敗しました」(同じセリフなんだよお!)
確かに、「失敗」とか聞こえた。流石に恐ろしい物を感じ始めた。
「あの、どちらにおかけですか? どなたですか? もしもし!」
やがて、プーと言う警告音がしてから電話自然に切れた。

2007-11-04 Sunday

2007-11-02 Friday

一方ロシアは

著作権の縛り、と言うか、著作権法の条文に含まれる「一部」と言う文言解釈によって、本は半分しかコピーできない訳ですが。
no title

複写は「書物全体の半分まで」とあるので、半分まではよい。さて、残りの半分はというと、複写は不可という。では、どうするか。

これをコピペジョーク的に解決しますとこうなります
「一方ロシアは、コピー申請を違う名前で二回出した」
やれやれ

一方ロシアは

著作権の縛り、と言うか、著作権法の条文に含まれる「一部」と言う文言解釈によって、本は半分しかコピーできない訳ですが。
no title

複写は「書物全体の半分まで」とあるので、半分まではよい。さて、残りの半分はというと、複写は不可という。では、どうするか。

これをコピペジョーク的に解決しますとこうなります
「一方ロシアは、コピー申請を違う名前で二回出した」
やれやれ

一方ロシアは

著作権の縛り、と言うか、著作権法の条文に含まれる「一部」と言う文言解釈によって、本は半分しかコピーできない訳ですが。
no title

複写は「書物全体の半分まで」とあるので、半分まではよい。さて、残りの半分はというと、複写は不可という。では、どうするか。

これをコピペジョーク的に解決しますとこうなります
「一方ロシアは、コピー申請を違う名前で二回出した」
やれやれ

 | 

Notice

コメント等は基本的に自由ですが、通りすがりとかななしさんとかの場合、いじっても面白くないので放置する可能性があります。

最近のエントリー

カウンター:
<< 2007/11 >>
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
あわせて読みたい
過去ログ
0000 | 00 |
1800 | 10 |
1908 | 06 |
1983 | 06 | 12 |
1985 | 01 | 08 | 09 | 10 | 11 |
1986 | 10 |
1990 | 01 | 02 | 03 | 04 | 05 | 06 |
1995 | 01 |
1996 | 02 | 03 | 04 | 05 | 06 |
1997 | 03 | 05 |
1999 | 02 | 09 |
2000 | 00 |
2001 | 12 |
2002 | 01 | 02 | 03 | 04 |
2003 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2004 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2015 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2016 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2017 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2018 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 |

Mail Form
お名前
メールアドレス
本文
公開の是非 公開してもよござんす/公開してはいけません
ブロ電™切符
RSS feed meter for http://d.hatena.ne.jp/eiji8pou/
著作権保護期間の70年延長に反対
NHK(日本放置協会)は放置される側の団体です
やる気の無いサイトリング
時間のないサイト運営者リング
ヒロインリコメンダー
私設コミケカタログ
「ひぐらしのなく頃に」を応援しています。
07th Expansion
「ひぐらしのなく頃に」のネタばれがあるのです。

最新コメント一覧

1. 08/21 無明長夜
2. 05/06 えぐち
3. 09/18 ABC1979
4. 10/14 eiji8pou
5. 10/14 ななし
6. 10/14 ななし
7. 06/30 うなぎ
8. 01/12 ねこ
9. 10/18 とおりすがり
10. 04/29 柊
11. 02/13 湖都
12. 02/13 eiji8pou
13. 02/13 湖都
14. 10/06 湖都
15. 10/06 リメ

最新トラックバック一覧

1. 03/03 Twitter / @uxIDiYlDhqWLm83
2. 03/02 Twitter / @roboko_bot
3. 03/02 Twitter / @Blue_Reimu
4. 10/17 Twitter / @Rek7z
5. 11/16 Twitter / @Lyri_m
6. 09/01 Twitter / @shinriyo
7. 04/10 Twitter / @psychedesire
8. 10/25 Twitter / @karafuto1979
9. 10/23 Twitter / @kkk_iso
10. 10/23 Twitter / @tacticsrealize
11. 10/22 Twitter / @kkk_iso
12. 10/18 Twitter / @kkk_iso
13. 04/24 Twitter / @fakestarbaby
14. 02/11 Twitter / @karafuto1979
15. 04/10 buynowforsaleの日記 - 灯で形態素解析もどき&マルコフ連鎖で文章...

言及URL

1. FrontPage - 朱鷺魅
2. Renee PDF Aideのダウンロード : Vector ソフトを探す!
3. NScripter−Tips:常駐ボタンの作り方
4. eiji8pouさんの採点結果[71点] まぁだいだいできたかなぁ〜|paizaオンラインハッカソンLite
5. 線形合同法 - Wikipedia
6. システムカスタマイズについてダラダラやるよーその8 - 永字八法
7. システムカスタマイズについてダラダラやるよーその7 - 永字八法
8. pretextgosubとgettag - 永字八法
9. システムカスタマイズについてダラダラやるよーその6.5 - 永字八法
10. システムカスタマイズについてダラダラやるよーその6 - 永字八法

言及ISBN/ASIN

1. 日本語〈上〉 (岩波新書)
2. ラプンツェル
3. ツバメしんどろ~む (Volume2) (角川コミックスドラゴンJr.)
4. ツバメしんどろ~む (3) (角川コミックスドラゴンJr)
5. ツバメしんどろ~む4 (カドカワコミックスドラゴンJr)
6. ツバメしんどろ~む v.6 (角川コミックス ドラゴンJr. 48-11)
7. ツバメしんどろ~む v.7 (角川コミックス ドラゴンJr. 48-13)
8. ツバメしんどろ~む v.8 (角川コミックス ドラゴンJr. 48-14)
9. だから僕は、Hができない。 4 (ドラゴンコミックスエイジ お 3-2-4)
10. キカイダー02(5) (角川コミックス・エース)
11. ストライクウィッチーズ 天空の乙女たち (1) (角川コミックス・エース 82-6)
12. J1 1 (あすかコミックスDX)
13. J1 2 (あすかコミックスDX)
14. 東方三月精 〜 Strange and Bright Nature Deity. (1) (角川コミックス)
15. のりタマ 1 (電撃コミックス)
16. ヘヴィーオブジェクト (電撃コミックス)
17. 京騒戯画鏡書院と迷子の栞 (電撃コミックス)
18. あぶない丘の家 3 (あすかコミックス)
19. ダークマーメイド―邪神伝説シリーズ 2 (ノーラコミックス 邪神伝説シリーズ)
20. まあめいど―都築和彦CGコミックス (ノーラコミックス・デラックス)
21. ワダチ 1 (マガジンKC)
22. ワダチ 2 (マガジンKC)
23. シミュレーションの発想―新しい問題解決法 (ブルーバックス (B‐523))
24. クレオパトラの謎 (講談社現代新書 (683))
25. ワーグナー (講談社現代新書)
26. 悪魔の話 (講談社現代新書)
27. 西洋占星術―科学と魔術のあいだ (講談社現代新書)
28. ChuしてBOMB! 1 (講談社コミックスフレンド)
29. ChuしてBOMB! 2 (講談社コミックスフレンド)
30. 星の島のるるちゃん 1 (講談社コミックスなかよし)

言及JAN/EAN

1. コミックメガストア 2009年12月号
2. 二次元ドリームマガジン2005年2月号
3. 二次元ドリームマガジン2006年2月号
4. 二次元ドリームマガジン2007年2月号
5. 二次元ドリームマガジン2005年4月号
6. 二次元ドリームマガジン2006年4月号
7. 二次元ドリームマガジン2007年4月号
8. 二次元ドリームマガジン2005年6月号
9. 二次元ドリームマガジン2006年6月号
10. 二次元ドリームマガジン2004年8月号
11. 二次元ドリームマガジン2005年8月号
12. 二次元ドリームマガジン2006年8月号
13. 二次元ドリームマガジン2005年10月号
14. 二次元ドリームマガジン2006年10月号
15. 二次元ドリームマガジン2005年12月号
16. 二次元ドリームマガジン2006年12月号
17. まんがタイムきららMAX 2010年01月号
18. ウルトラジャンプ 2009年11月号
19. コミックメガストアH 2009年10月号
20. 二次元ドリームマガジン 2009年12月号 Vol.49
21. コミック二次元ドリームVol.01
22. まんが学園4年生
23. まんがパレット2010年5月号
24. まんが4コマKINGSぱれっと 2009年12月号
25. まんがタイムきらら 2010年1月号
26. まんがタイムきらら 2010年4月号
27. まんがタイムきらら 2009年11月号
28. まんがタイムきららMAX 2009年12月号
29. まんがタイムきらら Carat 2009年12月号
30. HGST 3.5inch 7200rpm 2.0TB 64MB SATA 6.0Gbps

eiji8pouのアンテナ

1. 競馬まとめのまとめ
2. OL男子の4コマ書評
3. lib_blog
4. marginBlog
5. 労働者の図書館 〓図書館で働く者の義務と権利〓
6. 山中湖情報創造館
7. 東京の図書館をもっとよくする会
8. blue-black
9. 女子高生Cの場合
10. はてなダイアリー - ACADEMIC RESOURCE GUIDEの作業メモ
11. のらゴコロ
12. カレントアウェアネス・ポータル | 国立国会図書館
13. 図書館ばなし
14. diary / nowadays
15. 雲上四季
16. 妖精現実 フェアリアル
17. ”裏”日本工業新聞!!
18. うさだ
19. Stressful Angel
20. RE V の日記 @Hatena::Diary


注目ISBN/ASIN

1. 真野恵里菜メジャーデビュー10周年記念フォトエッセイ 『 軌跡 』
.
.
.
.
.
.
.
.
.

最新JAN/EAN

1. 6CD Gabriel Fauré
2. The Art of Violin 3 Alfonso Mosesti
3. Brahms: Tre Sonate pianoforte e violino op.78-100-108
4. うな次郎
5. BBC Music Magazine Vol.18.3 Sergei Prokofiev

注目JAN/EAN

1. まんがタイムきららCarat 2009年1月号
.
.
.
.

書いたコメント