2004/12/31
2004/12/29
うけてたちます。
hisashim: [Programming][Fun] コンピュータで解く簡単な問題::
http://www.livejournal.com/users/hisashim/85886.html
任意の自然数nについて、偶数なら2で割り、奇数なら3をかけて1を足して得られる数列に関し、(1)n = 7 のときに1に収束するまでのステップ数を求めよ。(2)n∈[2, 100]のなかでもっとも1までの収束に時間がかかるのは何ステップか求めよ。という問題。
元ネタはhttp://www.t-base.ne.jp/~tj/d/?date=20041214#p03らしい。
実行結果
ポイントは、奇数を3倍して1を足すと必ず偶数になることですかね(つまり、偶数の場合は偶奇判定が必須だけど、奇数の場合は次の偶奇判定を省略できる)。
hisashim: [Programming][Fun] コンピュータで解く簡単な問題::
http://www.livejournal.com/users/hisashim/85886.html
任意の自然数nについて、偶数なら2で割り、奇数なら3をかけて1を足して得られる数列に関し、(1)n = 7 のときに1に収束するまでのステップ数を求めよ。(2)n∈[2, 100]のなかでもっとも1までの収束に時間がかかるのは何ステップか求めよ。という問題。
元ネタはhttp://www.t-base.ne.jp/~tj/d/?date=20041214#p03らしい。
#! /usr/local/bin/python
def numeric(n):
count = 0
while n > 1:
if n & 1:
count = count + 2
n = (3 * n + 1) >> 1
else:
count = count + 1
n = n >> 1
return count
print "7 needs", numeric(7), "steps"
i = 0
basej = 0
for j in range(2, 101):
if i < numeric(j):
i = numeric(j)
basej = j
print "most steps in [2,100] is", i, "at n =", basej
実行結果
7 needs 16 steps
most steps in [2,100] is 118 at n = 97
ポイントは、奇数を3倍して1を足すと必ず偶数になることですかね(つまり、偶数の場合は偶奇判定が必須だけど、奇数の場合は次の偶奇判定を省略できる)。
2004/12/28
大好き素数について同僚のM氏のソリューション。
10001番目の素数が知りたいんですよ!
でも、上記のページが掲載されているテネシー大学Martin校のサイトはおもしろそう。
The Prime Pages (prime number research, records and resources)
http://www.utm.edu/research/primes/
ギネスに掲載されている最大の素数といった下世話な話題から、リーマン予想の簡単なサマリーまで、ぱっとみでは実に分かりやすそうな解説がまとめられている。
% X=100; curl --silent http://www.utm.edu/research/primes/lists/small/10000.txt | grep -v "[^0-9 ]" | tr -s " " "\n" | grep -v "^$" | head -n $X | tail -n 1
10001番目の素数が知りたいんですよ!
でも、上記のページが掲載されているテネシー大学Martin校のサイトはおもしろそう。
The Prime Pages (prime number research, records and resources)
http://www.utm.edu/research/primes/
ギネスに掲載されている最大の素数といった下世話な話題から、リーマン予想の簡単なサマリーまで、ぱっとみでは実に分かりやすそうな解説がまとめられている。
2004/12/27
年明けの嵐が怖いので、大好き素数を求めて気を落ち着けるしか。
current_integer = current_integer + 2 の部分がちょっと気が利いているような気がしていたんだけど、実行速度は +1 でもほとんどかわらないんじゃん。
#!/usr/local/bin/python
def get_prime_list(num):
known_prime = [2]
current_integer = 3
while len(known_prime) < num:
for indy in known_prime:
if current_integer % indy == 0:
current_integer = current_integer + 2
break
else:
known_prime.append(current_integer)
current_integer = current_integer + 2
return known_prime
import sys
integer = int(sys.argv[1])
print integer,"th prime is",get_prime_list(integer)[integer-1]
current_integer = current_integer + 2 の部分がちょっと気が利いているような気がしていたんだけど、実行速度は +1 でもほとんどかわらないんじゃん。
2004/12/25
大掃除。埃の量で得る達成感。ベランダとか広くなった気が。あと、大掃除のおかげで、軽く10年以上のキャリアになるACタップ(いちおうBelden)のコード皮膜が劣化してぼろぼろになっていたことを発見した。残念だけど、一歩間違えたら火事になってもおかしくないので、破棄。
それから、大掃除をきっかけに、Musical Fidelity の Tempest にも引退してもらうことにした。まったく不備はないんだけど、もうしばらく使わないだろうから。日本に入っている数は少ないんだろうなあ。あの値段で、あの大きさで、あれだけ艶っぽく鳴るインテグレーテッドアンプは他に知らない。その代わり、ボリュームとかの部品は国産だったら信じられないような安いのを使ってる。回路の構成上、S/Nも悪い。それでも自分は、全体が60点の製品よりも、平均すると40点だけど、ある部分(しかも、自分がその製品にとって本質だと思う部分)では95点を目指している製品のほうが好き。そういう意味で、この Tempest は、とてもお気に入りの工業製品の一つでした。余談だけど、実はパラビッチーニが設計にかかわっているという噂もあったりする(いまだに真偽はわからない)。そのつもりでJazzの女性ボーカルを聴いたりすると、トランジスタがあったまるにつれて、EAR 864を非力にしたような印象になってこないこともない。このトランジスタが、やけくそに熱い。物理的に。ハセガワのゼロ戦を上に置いていたら、尾翼が熔けたことがある。あと、むちゃくちゃ高い。8個のうち2個がいかれて修理に出したら、1個10000円も取られた。まあ、いろいろ思い出はあるので、すぐに捨てたり売ったりするつもりもない。しばらく休んでいてください。
ところで、絶対に気のせいなんだけど、スピーカーケーブルを拭くと音が良くなる。でも絶対に気のせいなのだ。ケーブルをはずす際に接点の錆が落ちるとか、そういうことはあるかもしれないけど、本気で音がよくなると主張するのは絶対にいやだ。
それから、大掃除をきっかけに、Musical Fidelity の Tempest にも引退してもらうことにした。まったく不備はないんだけど、もうしばらく使わないだろうから。日本に入っている数は少ないんだろうなあ。あの値段で、あの大きさで、あれだけ艶っぽく鳴るインテグレーテッドアンプは他に知らない。その代わり、ボリュームとかの部品は国産だったら信じられないような安いのを使ってる。回路の構成上、S/Nも悪い。それでも自分は、全体が60点の製品よりも、平均すると40点だけど、ある部分(しかも、自分がその製品にとって本質だと思う部分)では95点を目指している製品のほうが好き。そういう意味で、この Tempest は、とてもお気に入りの工業製品の一つでした。余談だけど、実はパラビッチーニが設計にかかわっているという噂もあったりする(いまだに真偽はわからない)。そのつもりでJazzの女性ボーカルを聴いたりすると、トランジスタがあったまるにつれて、EAR 864を非力にしたような印象になってこないこともない。このトランジスタが、やけくそに熱い。物理的に。ハセガワのゼロ戦を上に置いていたら、尾翼が熔けたことがある。あと、むちゃくちゃ高い。8個のうち2個がいかれて修理に出したら、1個10000円も取られた。まあ、いろいろ思い出はあるので、すぐに捨てたり売ったりするつもりもない。しばらく休んでいてください。
ところで、絶対に気のせいなんだけど、スピーカーケーブルを拭くと音が良くなる。でも絶対に気のせいなのだ。ケーブルをはずす際に接点の錆が落ちるとか、そういうことはあるかもしれないけど、本気で音がよくなると主張するのは絶対にいやだ。
2004/12/24
というわけで、マイファーストPythonは、配列の要素の全組み合わせ(combination)を得るものでした。
実行結果
自分で忘れないように簡単にメモしておくと、こいつは、まず2つの要素の組み合わせ((n 2)個)を構成する(n:配列の大きさ)。その組み合わせに対して、もう1つの要素を組み合わせたパターン(((n 2) 2)個)を求める。これの繰り返し。構成的に組み合わせの要素を求めるなら、枝も少ないし、けっこういいアルゴリズムな気がする(どうせすぐに認識の甘さを思い知るので、今はこう思わせておいてください)。
その代わり、メモリはやたらに喰う。あと、どんなに演算が早くても、全部で100個の要素から9個取り出す組み合わせを一覧しようとして結果を標準出力したりした日にゃあ、(100 9) = 1,902,231,808,400パターンになりますから! 黙っちゃうよ(計算あってる?)。
#! /usr/bin/python
#
# get combinations set from array.
#
# Keiichirou SHIKANO
def get_combinations(array, n):
if len(array) < n:
print "get_combinations() error: too large combinations for the array"
return -1
kappa = 1
bb = array[ : ]
lena = [[1]]
for i in range(0, len(array) + 1):
lena[0].append(1)
while kappa < n:
aa = []
lena.append([])
for ichiro in range(0, len(array)):
cc = []
del bb[0 : lena[kappa - 1][ichiro]]
lena[kappa].append(len(bb))
for joe in range(0, len(bb)):
if kappa < 2:
cc = [array[ichiro]] + [bb[joe]]
else:
cc = [array[ichiro]] + bb[joe]
aa.append(cc)
bb = aa[ : ]
kappa = kappa + 1
return bb
# test data
b = ["foobar", [0, 1, 2], 3, 0, ["cat", 7]]
s1 = 4
print get_combinations(b, s1)
実行結果
[['foobar', [0, 1, 2], 3, 0], ['foobar', [0, 1, 2], 3, ['cat', 7]], ['foobar', [
0, 1, 2], 0, ['cat', 7]], ['foobar', 3, 0, ['cat', 7]], [[0, 1, 2], 3, 0, ['cat'
, 7]]]
自分で忘れないように簡単にメモしておくと、こいつは、まず2つの要素の組み合わせ((n 2)個)を構成する(n:配列の大きさ)。その組み合わせに対して、もう1つの要素を組み合わせたパターン(((n 2) 2)個)を求める。これの繰り返し。構成的に組み合わせの要素を求めるなら、枝も少ないし、けっこういいアルゴリズムな気がする(どうせすぐに認識の甘さを思い知るので、今はこう思わせておいてください)。
その代わり、メモリはやたらに喰う。あと、どんなに演算が早くても、全部で100個の要素から9個取り出す組み合わせを一覧しようとして結果を標準出力したりした日にゃあ、(100 9) = 1,902,231,808,400パターンになりますから! 黙っちゃうよ(計算あってる?)。
2004/12/22
2004/12/21
これはもしかしてデスマーチという状態なのではないか。つまり、前工程の不備から、物理的に不可能なスケジュールでの納品を目指して進んでいる状態。発注側も、受注側も。
理由は分かりきっている。スケジュールというやつは、生産側の都合ではなく、あくまでも経営側の都合で決まるからだ。ただし、これは、「生産側である自分が経営側についてどうこう言っている」ような問題ではない。そうやって生産側と経営側の対立をあおっても仕方ないし、するつもりもない。じゃあ何をあおっているのか。まあ、ご多分に漏れず、そんなのすぐにはわかんないわけさ。
少なくとも言えるのは、
そんなわけで、
(ようするに悪循環じゃん)
よもや、あおっていたのは銀行/金融と生産業との対立か?
ここまで勢いで書いたけど、ここで言っている「生産業」には、拡大再生産を続ければすむような「工場型のもの」は含まれていない。クライアントしだいだろうけど、物理的に生産にかかる時間を割り出しやすい(そのノウハウがある)産業はデスマーチが顕在化しにくいような気がする。っていうか、物理的に無理だと開き直れるのか。
理由は分かりきっている。スケジュールというやつは、生産側の都合ではなく、あくまでも経営側の都合で決まるからだ。ただし、これは、「生産側である自分が経営側についてどうこう言っている」ような問題ではない。そうやって生産側と経営側の対立をあおっても仕方ないし、するつもりもない。じゃあ何をあおっているのか。まあ、ご多分に漏れず、そんなのすぐにはわかんないわけさ。
少なくとも言えるのは、
- 経営側が策定する年度計画は生産側の「作るつもり」に基づいている
- 年度計画は銀行などの融資や株価にも影響する
そんなわけで、
- 経営側は、一度決めた年度計画は短期的(一般には四半期)なスパンでは崩せない
- これは、体力がない自転車操業な企業ほど顕著
- その一方で、生産側の「作るつもり」はたいていコケる
- これは、体力がない自転車操業な業界(ソフトウェアとか出版とか広告とか)ほど顕著
(ようするに悪循環じゃん)
よもや、あおっていたのは銀行/金融と生産業との対立か?
ここまで勢いで書いたけど、ここで言っている「生産業」には、拡大再生産を続ければすむような「工場型のもの」は含まれていない。クライアントしだいだろうけど、物理的に生産にかかる時間を割り出しやすい(そのノウハウがある)産業はデスマーチが顕在化しにくいような気がする。っていうか、物理的に無理だと開き直れるのか。
2004/12/20
結論は相手に言わせろ(どうでもいいけど、気を抜くと一言日記になってくる)。
ここ数日思うのは、自分ががんばってもがんばれてもだめで、相手をがんばらせることができるかどうかが重要なんじゃないだろうか。でも何に? 「重要なんじゃないだろうか」などといって状況を分析している風を装うのは朝日の社説記者の仕事じゃろがい。おそらく、仕事(業務)が上手く遂行できるかどうかにとって重要で、仕事が上手く遂行できるのはサラリーマンの健全な精神にとって重要で、健全な精神がないと(スコラ哲学では)生きていないのと同じ。つまり、自分が生きるか死ぬかというレベルで「相手にがんばらせる」ことは重要ということか。でも、この期に及んで健全な精神はもう無理です。
今の仕事は一人でできる部分とそうでない部分があって、自分にとってはそうでない部分ほどうまくいかない。そしてきっと、研究や芸術なら自分ががんばれれば何とかなる。うそです。そんな素朴な精神論は太平洋戦争までのものです。しかし、そういう幻想は確実にあって、人はモラトリアム延長にあこがれるわけだ(自分と人一般を摩り替えない>自分)。
要約すると、自分自身でがんばるよりは他人にがんばらせてポルシェを買えと。でなければヴィッツで我慢しろと。
ここ数日思うのは、自分ががんばってもがんばれてもだめで、相手をがんばらせることができるかどうかが重要なんじゃないだろうか。でも何に? 「重要なんじゃないだろうか」などといって状況を分析している風を装うのは朝日の社説記者の仕事じゃろがい。おそらく、仕事(業務)が上手く遂行できるかどうかにとって重要で、仕事が上手く遂行できるのはサラリーマンの健全な精神にとって重要で、健全な精神がないと(スコラ哲学では)生きていないのと同じ。つまり、自分が生きるか死ぬかというレベルで「相手にがんばらせる」ことは重要ということか。でも、この期に及んで健全な精神はもう無理です。
今の仕事は一人でできる部分とそうでない部分があって、自分にとってはそうでない部分ほどうまくいかない。そしてきっと、研究や芸術なら自分ががんばれれば何とかなる。うそです。そんな素朴な精神論は太平洋戦争までのものです。しかし、そういう幻想は確実にあって、人はモラトリアム延長にあこがれるわけだ(自分と人一般を摩り替えない>自分)。
要約すると、自分自身でがんばるよりは他人にがんばらせてポルシェを買えと。でなければヴィッツで我慢しろと。
登録:
投稿 (Atom)