探検
pythonがこの先生きのこるには
■ このスレッドは過去ログ倉庫に格納されています
1七色波紋 ◆.VgGY5NKtU
2007/01/05(金) 20:26:11 $python kinoko.py this_teacher
2007/07/01(日) 07:30:23
実用性ゼロ
2007/07/01(日) 07:33:52
>>82
↓これと同じことだと思う。
>>> False==False
True
>>> (1==2)==False
True
>>> 1==2==False
False
>>>
Pythonの比較演算子は複数つなげられる。その場合、
最初の比較演算子が False なら結果は False、そうでなければ
次の比較演算子が False なら結果は False、そうでければ
その次の比較演算子が・・・・・と続けていって
すべての比較演算子が True なら結果は True となる。
ある比較演算子で False になると、そのあとに比較演算子があっても評価されない。
1 in [] in [False] の場合、最初の in 演算子が False になるので
次の in は評価されないまま結果は False となる。
↓これと同じことだと思う。
>>> False==False
True
>>> (1==2)==False
True
>>> 1==2==False
False
>>>
Pythonの比較演算子は複数つなげられる。その場合、
最初の比較演算子が False なら結果は False、そうでなければ
次の比較演算子が False なら結果は False、そうでければ
その次の比較演算子が・・・・・と続けていって
すべての比較演算子が True なら結果は True となる。
ある比較演算子で False になると、そのあとに比較演算子があっても評価されない。
1 in [] in [False] の場合、最初の in 演算子が False になるので
次の in は評価されないまま結果は False となる。
8685
2007/07/01(日) 07:35:53 うへ、かぶった orz
2007/07/01(日) 09:57:05
88デフォルトの名無しさん
2007/07/13(金) 19:19:45 >>> o='oOo'
>>> O='ooOOoo'
>>> def ooOOooOoOOoo(oO): print oO; return ooOOooOoOOoo
...
>>> ooOOooOoOOoo(o)(o)(O)(O)(o)(o)(O)(o)(O)(O)(o)(o)
oOo
oOo
ooOOoo
ooOOoo
oOo
oOo
ooOOoo
oOo
ooOOoo
ooOOoo
oOo
oOo
>>> O='ooOOoo'
>>> def ooOOooOoOOoo(oO): print oO; return ooOOooOoOOoo
...
>>> ooOOooOoOOoo(o)(o)(O)(O)(o)(o)(O)(o)(O)(O)(o)(o)
oOo
oOo
ooOOoo
ooOOoo
oOo
oOo
ooOOoo
oOo
ooOOoo
ooOOoo
oOo
oOo
2007/07/15(日) 18:27:29
いまのOctalは危険な気がするので0o123で良いんだが
(つーかどうせ使わん)、そんなことより2進表記を
用意して欲しいものよ・・
(つーかどうせ使わん)、そんなことより2進表記を
用意して欲しいものよ・・
2007/07/15(日) 19:56:40
危険って?
91デフォルトの名無しさん
2007/07/16(月) 01:57:48 こういうことじゃないの?
>>> 064 # base 8
52
>>> int('064') # base 10
64
2進表記って↓とは違う話?
http://www.python.org/dev/peps/pep-3127/
>>> 064 # base 8
52
>>> int('064') # base 10
64
2進表記って↓とは違う話?
http://www.python.org/dev/peps/pep-3127/
2007/07/16(月) 23:20:16
あ〜まさにこのPEPで言い尽くされてます。
ちなみにハードウェア寄りの仕事してると
ビット列扱うことが結構あるんですわ。
ちなみにハードウェア寄りの仕事してると
ビット列扱うことが結構あるんですわ。
2007/07/16(月) 23:27:52
>>92
ハードウェア寄りの仕事でPython使うのん?
ハードウェア寄りの仕事でPython使うのん?
2007/07/16(月) 23:59:25
いつでもどこでもPythonを使いたいもんだ。
2007/07/26(木) 16:22:29
http://groups.google.com/group/comp.lang.python/browse_thread/thread/8359c264e516570e/b56603ecfb574ef3#b56603ecfb574ef3
flattenとか結構共通の話題なんだなぁという感じ・・・
2chよりレベル低いのがわらわらいて笑える
flattenとか結構共通の話題なんだなぁという感じ・・・
2chよりレベル低いのがわらわらいて笑える
96名無しさん@そうだ選挙に行こう
2007/07/29(日) 11:00:32 きのこ
97デフォルトの名無しさん
2007/07/31(火) 06:56:03 そんなことは無い
グッスミン、ララ〜、ララッラ、ラッラッラ〜
グッスミン、ララ〜、ララッラ、ラッラッラ〜
2007/07/31(火) 23:11:09
死にかけてるわけじゃ無いんだから、
このスレいらんがな。
このスレいらんがな。
99デフォルトの名無しさん
2007/08/01(水) 23:08:15 このスレは本スレにはとても書けない様なかっこいいネタを見つけてしまった人専用の隔離スレです。
100デフォルトの名無しさん
2007/08/01(水) 23:13:32 今日optparseに感動しますた
101デフォルトの名無しさん
2007/08/02(木) 11:26:54 でもついついgetopt って書いちゃったり
102デフォルトの名無しさん
2007/08/02(木) 23:47:30 ちょっとしたうれしい発見
>>> def g():yield 1;yield 2;yield 3
...
>>> g()
<generator object at 0x00BE5490>
>>> a,b,c=g()
>>> a
1
>>> b
2
>>> c
3
>>> def g():yield 1;yield 2;yield 3
...
>>> g()
<generator object at 0x00BE5490>
>>> a,b,c=g()
>>> a
1
>>> b
2
>>> c
3
103デフォルトの名無しさん
2007/08/03(金) 08:03:15 あ、ジェネレータでもできるんだ。
でもイテレータやジェネレータって個数わかんないことが多いから使う機会少なそう……。
でもイテレータやジェネレータって個数わかんないことが多いから使う機会少なそう……。
104デフォルトの名無しさん
2007/08/03(金) 08:04:45 a, b, c = 'abc'
もっと使わなそうなのもあるぜ
もっと使わなそうなのもあるぜ
105デフォルトの名無しさん
2007/08/03(金) 08:17:52 左辺がリストの場合、
・sequenceである式
・yield式
のどちらか。
・sequenceである式
・yield式
のどちらか。
106デフォルトの名無しさん
2007/08/13(月) 17:42:20 http://www.python.jp/doc/2.4/ref/indentation.html
小文字の "l" 一文字は使ってはいけませんと自分たちで言っておいて、ドキュメントの例の中で使ってる件
小文字の "l" 一文字は使ってはいけませんと自分たちで言っておいて、ドキュメントの例の中で使ってる件
107デフォルトの名無しさん
2007/08/13(月) 17:43:58 だから大人は嫌いなんだぁぁうわぁぁぁぁああああああ
108デフォルトの名無しさん
2007/08/13(月) 23:15:17 このドキュメントを作ったのは誰だぁっ!?
109デフォルトの名無しさん
2007/08/14(火) 01:57:54 pythonって元々の哲学から逸脱してるような気がする。
110デフォルトの名無しさん
2007/08/14(火) 04:01:00111デフォルトの名無しさん
2007/08/14(火) 06:01:19 Neal Norwitz:
>Alpha 1 is a few *weeks* away. The release will hopefully come
>shortly after the sprint at Google which is Aug 22-25.
windows用installerとかもすぐ出るんだろうか・・・?
>Alpha 1 is a few *weeks* away. The release will hopefully come
>shortly after the sprint at Google which is Aug 22-25.
windows用installerとかもすぐ出るんだろうか・・・?
112デフォルトの名無しさん
2007/08/23(木) 09:56:13 http://www.python.org/dev/peps/pep-3124/
いつの間にかGeneric Functionが無期限延期に、・・・・
正体不明で期待してたのに・・・・
なんか、相当根本的な難点にぶつかったらしい・・・
いつの間にかGeneric Functionが無期限延期に、・・・・
正体不明で期待してたのに・・・・
なんか、相当根本的な難点にぶつかったらしい・・・
113デフォルトの名無しさん
2007/08/23(木) 20:38:48 本家のgrammer.txtがバグバグな件
http://docs.python.org/ref/grammar.txt
ちなみにPyJUGも
http://www.python.jp/doc/release/ref/grammar.txt
http://docs.python.org/ref/grammar.txt
ちなみにPyJUGも
http://www.python.jp/doc/release/ref/grammar.txt
114デフォルトの名無しさん
2007/08/23(木) 22:40:00 どこらへんが?
PythonのBNFは専用に拡張されてたはずだけど
そのこと?
PythonのBNFは専用に拡張されてたはずだけど
そのこと?
115デフォルトの名無しさん
2007/08/24(金) 09:14:30 a_expr とか and_expr とか xor_expr とか augop とかで、
texから変換したときのミスで出てきたっぽい意味ない記号がポロポロ混じってる。
ひどいのがprint_stmtでこれは相当カンを働かせないと元が何だったか分からない。
(まあ、本文見れば正解が分かるけど、・・・
texから変換したときのミスで出てきたっぽい意味ない記号がポロポロ混じってる。
ひどいのがprint_stmtでこれは相当カンを働かせないと元が何だったか分からない。
(まあ、本文見れば正解が分かるけど、・・・
116デフォルトの名無しさん
2007/08/24(金) 12:02:16 callもひどい、変な重複があるし、なぞのTab文字が混入してるし、
117デフォルトの名無しさん
2007/08/24(金) 16:30:20 ソース見ればいいし
誰も必要としてないから
きちんと保守されてないのかな。
誰も必要としてないから
きちんと保守されてないのかな。
118デフォルトの名無しさん
2007/08/25(土) 00:12:29 確認
>>> class A(object):pass
...
>>> isinstance(A,type)
True
>>> isinstance(A(),A)
True
>>> class A(object):pass
...
>>> isinstance(A,type)
True
>>> isinstance(A(),A)
True
119デフォルトの名無しさん
2007/08/27(月) 21:34:18 もーいーくつねーるーとーあーるーふぁーいーちー
120デフォルトの名無しさん
2007/09/13(木) 04:08:35 α何とか出したけど、実際はまだまだ問題山積みっぽい感じだ、ML見てると・・・、
121デフォルトの名無しさん
2007/09/13(木) 06:40:40122デフォルトの名無しさん
2007/09/14(金) 22:47:52 会社のおっさんSE(昔の自慢話ばかりしてる)にPythonの説明してたら、
偉そうに「みんな同じようなソースになってつまらない」とか言ってた。
俺は教養主義者じゃないけど、こういうアホを見ると計算機科学の基礎くらいはやった方がいいと思った。
なんか自分が発明したアルゴリズムがいくつかもパクられてるとか言ってるし…。
つーか仕事の邪魔だよおっさんひっこんでろ!
偉そうに「みんな同じようなソースになってつまらない」とか言ってた。
俺は教養主義者じゃないけど、こういうアホを見ると計算機科学の基礎くらいはやった方がいいと思った。
なんか自分が発明したアルゴリズムがいくつかもパクられてるとか言ってるし…。
つーか仕事の邪魔だよおっさんひっこんでろ!
123デフォルトの名無しさん
2007/09/15(土) 01:48:33 ・・・・・・
124デフォルトの名無しさん
2007/09/15(土) 16:51:42 同じことやるソースなら、同じになっていいんだよ。
だから、同じようなソースを書くのがいやなら、同じことをやらなければいい。
みんなで同じのを作って競うんでもない限り、やったことないことをやった方が楽しいじゃん。
同じ問題に対して、今までと違うやり方でやるのも含めてね。
だから、同じようなソースを書くのがいやなら、同じことをやらなければいい。
みんなで同じのを作って競うんでもない限り、やったことないことをやった方が楽しいじゃん。
同じ問題に対して、今までと違うやり方でやるのも含めてね。
125デフォルトの名無しさん
2007/09/15(土) 20:47:44 同じになるのはインデントだけ
126デフォルトの名無しさん
2007/09/15(土) 22:35:17 同じ処理でもクラス作りたがる奴、ローカル関数作りたがる奴、
ワンライナーにしたがる奴…と色々特徴はあるぜ
ワンライナーにしたがる奴…と色々特徴はあるぜ
127デフォルトの名無しさん
2007/09/16(日) 00:39:28 すまん、板違いだった…。
>126
λを知らないし、そもそも関数の意味とか分かってない。
だから、ジェネレータや高階関数の意義も理解できないし、思い浮かびもしないはず。
(それでアルゴリズムを作ったとか言っているあたりが…。)
ただ、最近の若手はこのあたりを抑えてて、頼もしく感じる。
あと、お詫びにこのスレに沿った話題も。リスト内包はジェネレータ表現に統合されていくらしいね。
これはときどきリスト内包しか使えない場所にジェネレータ表現を使ってしまうことがあるので、個人的には助かる。
(書く内容はほとんど一緒なわけだし)
>126
λを知らないし、そもそも関数の意味とか分かってない。
だから、ジェネレータや高階関数の意義も理解できないし、思い浮かびもしないはず。
(それでアルゴリズムを作ったとか言っているあたりが…。)
ただ、最近の若手はこのあたりを抑えてて、頼もしく感じる。
あと、お詫びにこのスレに沿った話題も。リスト内包はジェネレータ表現に統合されていくらしいね。
これはときどきリスト内包しか使えない場所にジェネレータ表現を使ってしまうことがあるので、個人的には助かる。
(書く内容はほとんど一緒なわけだし)
128デフォルトの名無しさん
2007/09/16(日) 03:09:29 抑えてどーするw
129デフォルトの名無しさん
2007/10/16(火) 10:21:37 C++のプロジェクトからPythonのモジュールを利用する方法教えて下さいでつ。
130デフォルトの名無しさん
2007/10/24(水) 23:10:31 >>129
boost.python
boost.python
131デフォルトの名無しさん
2007/11/01(木) 00:53:04 (1.0 + 2.0j).realのリアルは何で、methodじゃなくて属性なんだろう、・・・
conjugateはメソッドなのに、・・・なんかシンメトリーが崩れてる気がする。
conjugateはメソッドなのに、・・・なんかシンメトリーが崩れてる気がする。
132デフォルトの名無しさん
2007/11/01(木) 06:01:44 複素数に対して共役は関数だが実数部は関数じゃないからでは
133デフォルトの名無しさん
2007/11/01(木) 08:45:03 ???
R を実数全体、C を複素数全体とすると
real: C→R
conjugate: C→C
で両方とも関数だけど、そういうことじゃなくて?
R を実数全体、C を複素数全体とすると
real: C→R
conjugate: C→C
で両方とも関数だけど、そういうことじゃなくて?
134デフォルトの名無しさん
2007/11/01(木) 09:23:35 確かに実数部を取り出す操作は関数で表せるが、この場合は実数部が
複素数の属性(項)だということを強調したんじゃないか、ということ。
複素数の属性(項)だということを強調したんじゃないか、ということ。
135デフォルトの名無しさん
2007/11/12(月) 07:53:07 単なる容量節約のような気もする・・・
136デフォルトの名無しさん
2007/11/12(月) 07:54:31 どうせ属性値として持ってんだから、わざわざ関数作るまでもないだろ、みたいな不精
137デフォルトの名無しさん
2007/11/12(月) 10:13:21 >>131
崩れてない。
崩れてない。
138デフォルトの名無しさん
2007/11/13(火) 22:51:54 >>137
kwsk
kwsk
139デフォルトの名無しさん
2007/11/15(木) 04:02:42 http://mail.python.org/pipermail/python-3000/2007-November/011103.html
>Currently (in 3.0), "".join(<seq>) automatically applies str() to the
>items of <seq>,
いつのまにかきもい仕様が入りだしてる。
joinはstringの列以外が来たらエラーを吐くのがpythonらしくていいと思ってたのに・・
>Currently (in 3.0), "".join(<seq>) automatically applies str() to the
>items of <seq>,
いつのまにかきもい仕様が入りだしてる。
joinはstringの列以外が来たらエラーを吐くのがpythonらしくていいと思ってたのに・・
140デフォルトの名無しさん
2007/11/15(木) 04:33:41 IOをハックしてた人(でも、contributeするほどには知識がなかった人)にGuidoがやさしい言葉をかけてるのが和んだ
141デフォルトの名無しさん
2007/11/19(月) 07:30:25 おいおいマジか・・・
def a():
p = yield 1
for i in a(): print i
def a():
p = yield 1
for i in a(): print i
142デフォルトの名無しさん
2007/11/19(月) 12:02:01 >p = yield 1
構文エラーにならないのかよってこと?
構文エラーにならないのかよってこと?
143デフォルトの名無しさん
2007/11/19(月) 21:40:42 そうそう、
文を式として使うなんて、・・・
こんなのなんで必要なんだろう・・・
文を式として使うなんて、・・・
こんなのなんで必要なんだろう・・・
144デフォルトの名無しさん
2007/11/19(月) 22:00:33 ジェネレータ使う側との通信用だよ
まあもっと良い書き方はないのかという気はするが
まあもっと良い書き方はないのかという気はするが
145デフォルトの名無しさん
2007/11/20(火) 01:37:11 値を出力する言語要素は少ないからな。
importに倣って yield_stmt ::= "yield" expr ["receive" name] とか?
しかしまぁ今のでもlambdaと同程度には穏当かと。
importに倣って yield_stmt ::= "yield" expr ["receive" name] とか?
しかしまぁ今のでもlambdaと同程度には穏当かと。
146デフォルトの名無しさん
2007/11/21(水) 14:48:37 >>143
assignment_stmt ::=
(target_list "=")+
(expression_list | yield_expression)
yield_stmt ::=
yield_expression
なんだが?
むしろyield文は、式文のように値を捨てている。
yield式は、常に値をスタックに積んで、
yield「文」なら(制御から戻った時に)要らないから捨てる。
単純な実装だとこうなる。
構文に合致していてスタックマシンで実装しやすい。
assignment_stmt ::=
(target_list "=")+
(expression_list | yield_expression)
yield_stmt ::=
yield_expression
なんだが?
むしろyield文は、式文のように値を捨てている。
yield式は、常に値をスタックに積んで、
yield「文」なら(制御から戻った時に)要らないから捨てる。
単純な実装だとこうなる。
構文に合致していてスタックマシンで実装しやすい。
147デフォルトの名無しさん
2007/11/21(水) 21:17:52 (expression_list | yield_expression)
expression_listなんていうかなり一般的なものと、yield_expressionつう割と特殊な
ものが並列で並んじゃうこと自体がおかしいと思う。
expression_listなんていうかなり一般的なものと、yield_expressionつう割と特殊な
ものが並列で並んじゃうこと自体がおかしいと思う。
148デフォルトの名無しさん
2007/11/21(水) 21:48:11 >>147
Python構文のBNFの構造(grammar.txt)は、
単純な実装コードへ自然に変換できるような書き方になってる。
優先順位を埋め込んだり。
特別な処理が必要なものは、
コンパイラ・コンパイラのアクション部に実装を書けるところまで、
特別なノンターミナルとして扱うとコード生成が簡単。
かなり構文/意味解析に手慣れた人たちが書いているなあと思う。
ただ、後から拡張した部分が、継接的に残っているところもあるみたい。
Python構文のBNFの構造(grammar.txt)は、
単純な実装コードへ自然に変換できるような書き方になってる。
優先順位を埋め込んだり。
特別な処理が必要なものは、
コンパイラ・コンパイラのアクション部に実装を書けるところまで、
特別なノンターミナルとして扱うとコード生成が簡単。
かなり構文/意味解析に手慣れた人たちが書いているなあと思う。
ただ、後から拡張した部分が、継接的に残っているところもあるみたい。
149デフォルトの名無しさん
2007/11/26(月) 12:12:07 α2遅い
150デフォルトの名無しさん
2007/12/01(土) 18:51:41 Pythonオワタ・・・orz
俺もう乗り換えるわ
Running the snippets above, I got the following results:
Python 2.5.1: 31.507s
Ruby 1.9.0: 11.934s
The Ruby code:
def fib(n)
if n == 0 || n == 1
n
else
fib(n-1) + fib(n-2)
end
end
36.times do |i|
puts "n=#{i} => #{fib(i)}"
end
And the Python equivalent:
def fib(n):
if n == 0 or n == 1:
return n
else:
return fib(n-1) + fib(n-2)
for i in range(36):
print "n=%d => %d" % (i, fib(i))
俺もう乗り換えるわ
Running the snippets above, I got the following results:
Python 2.5.1: 31.507s
Ruby 1.9.0: 11.934s
The Ruby code:
def fib(n)
if n == 0 || n == 1
n
else
fib(n-1) + fib(n-2)
end
end
36.times do |i|
puts "n=#{i} => #{fib(i)}"
end
And the Python equivalent:
def fib(n):
if n == 0 or n == 1:
return n
else:
return fib(n-1) + fib(n-2)
for i in range(36):
print "n=%d => %d" % (i, fib(i))
151デフォルトの名無しさん
2007/12/01(土) 22:00:55 うちの環境だとpython2.5は37秒ぐらいで、ruby1.8は100秒前後だった、(まるっきり↑のコードまんまで
ruby1.9ってほんとにそんなに早いの?(入れるのめんどくさくて試せない
つうか、py3000は速度的な改善はないんだっけ?
ruby1.9ってほんとにそんなに早いの?(入れるのめんどくさくて試せない
つうか、py3000は速度的な改善はないんだっけ?
152デフォルトの名無しさん
2007/12/02(日) 03:48:48 どうやってパフォーマンス計るの?
153デフォルトの名無しさん
2007/12/02(日) 10:03:55 >>152
time(1)
time(1)
154デフォルトの名無しさん
2007/12/02(日) 10:48:03 >>153
ありがとうございます。
自分でもやってみました。
python2.5.1: 49.147s
python2.5.1+psyco: 2.958s
ruby 1.8.6: 1m59.859s
ruby 1.9: 36.132s
ありがとうございます。
自分でもやってみました。
python2.5.1: 49.147s
python2.5.1+psyco: 2.958s
ruby 1.8.6: 1m59.859s
ruby 1.9: 36.132s
155デフォルトの名無しさん
2007/12/02(日) 12:02:17 python 2.5.1
0m49.463s
jython 2.1 on java1.6.0 (JIT: null)
0m28.918s
0m49.463s
jython 2.1 on java1.6.0 (JIT: null)
0m28.918s
156デフォルトの名無しさん
2007/12/02(日) 12:04:24 誰かIronPythonでも計測して!
157デフォルトの名無しさん
2007/12/02(日) 12:59:33 python 2.5.1
102.657s
IronPython 2.0A6
54.043s
102.657s
IronPython 2.0A6
54.043s
158デフォルトの名無しさん
2007/12/02(日) 14:27:01 JRubyかもん!
159デフォルトの名無しさん
2007/12/03(月) 00:14:35 IronPythonは起動に時間がかかるのがふにふに。
ruby1.9は何が変わったんでしょう?
あと、ついでなのでF#もおいときますね。
let rec fib n = if n = 0 || n = 1 then n else fib(n-1) + fib(n-2)
let _ =
for i = 0 to 35 do
printfn "n=%d=> %d" i (fib i)
done;;
ruby1.9は何が変わったんでしょう?
あと、ついでなのでF#もおいときますね。
let rec fib n = if n = 0 || n = 1 then n else fib(n-1) + fib(n-2)
let _ =
for i = 0 to 35 do
printfn "n=%d=> %d" i (fib i)
done;;
160デフォルトの名無しさん
2007/12/03(月) 00:56:52 Ruby 1.9の最大の変更点は。
RoRが動かなくなることだよ。
RoRが動かなくなることだよ。
161デフォルトの名無しさん
2007/12/03(月) 23:13:27 >>159
税金が投入されたこと
税金が投入されたこと
162デフォルトの名無しさん
2007/12/03(月) 23:54:58 PyFinalizeでメモリ回収しきる前にGC終わらせる動作なんとかならないの?
163デフォルトの名無しさん
2007/12/04(火) 17:41:05 >>155
> python 2.5.1
> 0m49.463s
>
> jython 2.1 on java1.6.0 (JIT: null)
> 0m28.918s
つづき (全く同じ環境です)
ruby 1.8.5
1m50.823s
ruby 1.9.0
2m28.901s
jruby 1.1.b1 on java1.6.0
0m30.278s
やっぱJVM w/HotSpotはこういう単純なテストだと速いね。
俺の環境(Intel L2300 @ 1.50GHz)だとruby 1.9.0はかなり遅い。
> python 2.5.1
> 0m49.463s
>
> jython 2.1 on java1.6.0 (JIT: null)
> 0m28.918s
つづき (全く同じ環境です)
ruby 1.8.5
1m50.823s
ruby 1.9.0
2m28.901s
jruby 1.1.b1 on java1.6.0
0m30.278s
やっぱJVM w/HotSpotはこういう単純なテストだと速いね。
俺の環境(Intel L2300 @ 1.50GHz)だとruby 1.9.0はかなり遅い。
164デフォルトの名無しさん
2007/12/04(火) 17:49:42 あ、同じ1.9.0でも20060609→20070830としたら、
ruby 1.9.0 (20070830)
0m34.250s
となりました。
ruby 1.9.0 (20070830)
0m34.250s
となりました。
165デフォルトの名無しさん
2007/12/05(水) 12:41:04 うちの環境 @PentiumM 1.7GHz
Python 2.5.1
40.00s user 0.32s system 98% cpu 41.066 total
Python 2.5.1 + Cython
18.73s user 0.11s system 98% cpu 19.174 total
Python 2.5.1 + psyco
2.13s user 0.04s system 91% cpu 2.371 total
Python 2.5.1
40.00s user 0.32s system 98% cpu 41.066 total
Python 2.5.1 + Cython
18.73s user 0.11s system 98% cpu 19.174 total
Python 2.5.1 + psyco
2.13s user 0.04s system 91% cpu 2.371 total
166デフォルトの名無しさん
2007/12/05(水) 21:50:15 >>165
Cythonはもっと速度が出ると思うけど
Cythonはもっと速度が出ると思うけど
167デフォルトの名無しさん
2007/12/06(木) 08:24:32 自分で計測したら?
168デフォルトの名無しさん
2007/12/06(木) 09:00:10 >>166
糞コードそのままだからね
書き換えたら100まででこんな感じ
…略…
n=98 => 135301852344706746049
n=99 => 218922995834555169026
python fibtest.py 0.03s user 0.01s system 13% cpu 0.295 total
糞コードそのままだからね
書き換えたら100まででこんな感じ
…略…
n=98 => 135301852344706746049
n=99 => 218922995834555169026
python fibtest.py 0.03s user 0.01s system 13% cpu 0.295 total
169デフォルトの名無しさん
2007/12/06(木) 09:06:21 書き換えたらどれでも速いだろ。
170デフォルトの名無しさん
2007/12/06(木) 09:17:26 どこをどう書き換えたか書いとけよ
171デフォルトの名無しさん
2007/12/07(金) 06:42:57 >>150は計測専用だろ、
むしろこんなアルゴリズムでフィボナッチ数計算しようなんて逆に思いつかない
むしろこんなアルゴリズムでフィボナッチ数計算しようなんて逆に思いつかない
172デフォルトの名無しさん
2007/12/07(金) 12:27:23 普通はそういうのを糞コードとは呼ばないけどな
173デフォルトの名無しさん
2007/12/07(金) 12:42:05 haskellを優位に見せるためだけのコードでしょ、あれは
174デフォルトの名無しさん
2007/12/07(金) 13:35:10 インタープリタの Moscow ML でも Python の 10 倍くらい速かったよ。
175デフォルトの名無しさん
2007/12/09(日) 03:31:38 3.0で
単に[0, 1, 2, 3, 4, 5, 6, 7, 8]が欲しいごときで
list(range(9))
って書かなきゃいけないのって長くね?
対話実行時にストレス感じそう
単に[0, 1, 2, 3, 4, 5, 6, 7, 8]が欲しいごときで
list(range(9))
って書かなきゃいけないのって長くね?
対話実行時にストレス感じそう
176デフォルトの名無しさん
2007/12/09(日) 03:46:49177デフォルトの名無しさん
2007/12/21(金) 13:19:04 def N():
i = 0
while 1:
yield i
i += 1
def enumerate(g):
return zip(N(), g)
i = 0
while 1:
yield i
i += 1
def enumerate(g):
return zip(N(), g)
178デフォルトの名無しさん
2007/12/24(月) 06:34:09 本家MLでmetaclassの話題振ってきたやつに対する海老ーの対応が
いやな奴過ぎてドン引きした。
いやな奴過ぎてドン引きした。
179デフォルトの名無しさん
2007/12/25(火) 10:44:15 ttp://mail.python.org/pipermail/python-3000/2007-May/007107.html
この辺?
この辺?
180デフォルトの名無しさん
2007/12/28(金) 21:48:48 それは全然普通に議論してるように見えるけど・・・
それじゃなくて、ごく最近ので、初ポストですって言ってメタクラスの話題振ってた奴に対して
の扱いがなんか異常だった。
で、その人の最後の捨て台詞が、「なんでpythonに貢献することが、楽しみというよりもむしろつまんねー作業なのかが
良く分かりました。本当にありがとうございました。」
それじゃなくて、ごく最近ので、初ポストですって言ってメタクラスの話題振ってた奴に対して
の扱いがなんか異常だった。
で、その人の最後の捨て台詞が、「なんでpythonに貢献することが、楽しみというよりもむしろつまんねー作業なのかが
良く分かりました。本当にありがとうございました。」
181デフォルトの名無しさん
2008/01/01(火) 21:28:01 今年もきのこる!
182デフォルトの名無しさん
2008/01/02(水) 21:17:44 >Python 3.0 compatibility
>------------------------
>As it will be used for Python 3.0 too, the toolset should be kept in a state
>where it is fully usable Python 3 code after one run of the ``2to3`` utility.
> 3.0でも使えなきゃやだ。道具箱の手入れは怠るべからず。3.0でも使えるように。
>一連の2to3ユーティリティが登場したら。
2to3コンバータツールをかまして互換性を取るというのは本当?
もしそうだとしたらコードを書く時どういう点に注意したら良いでしょうか。
>------------------------
>As it will be used for Python 3.0 too, the toolset should be kept in a state
>where it is fully usable Python 3 code after one run of the ``2to3`` utility.
> 3.0でも使えなきゃやだ。道具箱の手入れは怠るべからず。3.0でも使えるように。
>一連の2to3ユーティリティが登場したら。
2to3コンバータツールをかまして互換性を取るというのは本当?
もしそうだとしたらコードを書く時どういう点に注意したら良いでしょうか。
183デフォルトの名無しさん
2008/01/05(土) 19:11:14 きのこる揚げ
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 「中国側も日本機のレーダーを感知していた」 中国メディアが報道 [♪♪♪★]
- 【YouTuber】バイク事故で入院のゆたぼん、振込で「お見舞金」募る [muffin★]
- 高市早苗首相、消費税減税に後ろ向き 足かせはレジシステム? 「責任ある積極財政」期待高いが [蚤の市★]
- 堀江貴文、キャッシュレス非対応の店にモヤッ 『PayPay』立ち上げの人物にまさかの直談判「現金決済しかできないんだけど…」 [冬月記者★]
- 低所得層のマクドナルド離れが深刻に 広がる「ファストフード格差」の真相 米国 [少考さん★]
- バリ島で男子生徒ら集団万引きか、防犯カメラ映像が拡散 京都の大谷中学・高校が「窃盗行為」謝罪★7 [七波羅探題★]
- 中国がここまで過敏になるのは日本に前科があるから。盧溝橋、満州事変。ジャップの先制攻撃は挙げればキリがないけど [472617201]
- 防衛省、中国を完全論破www 「事前通告があったのは海自であって空自ではない」 高市早苗勝利 [175344491]
- エイとかいうどう見ても魚っぽくない奴いるよな
- 乳首触らんと立たないやつ
- 一人ぼっち、ガチで辛かった…
- きつねき
