アカウント名:
パスワード:
それより#! /usr/bin/perlが気になります。
ひゃああああ、そこはもちろん、#! /usr/bin/python でございますよ。オリジナルが perl だったってだけで。
しかし。こんなに根性が違うとは思わなかった。python は「初期化時の型」を覚えていて、自動型変換もしてくれないのね…。配列に代入したら自動的に配列に拡張してくれるわけでもない…(そんな配列しらん とか index out of range とか何度言われた事か…いや、まだまだ言われそうだ)。
うぅ、まるでCのようなのに、生半可にいろいろ使える分さらに悩ましい…
> python は「初期化時の型」を覚えていて、自動型変換もしてくれないのね…。Pythonの世界では型のチェックだの変換だのはプログラマの責任でどうぞ、ということになってます。
> 配列に代入したら自動的に配列に拡張してくれるわけでもない「配列」が何を指しているのか判りませんが、ひょっとして文字列を「文字の配列」だと思ってます？Pythonにおいて文字列は文字の配列ではありませんよ。
文字列は文字の配列ではありませんよ。
いえ、そうじゃなく。
Perlでは突如として
$a[12345] = 0.27;
とか書けるんですよ。こう書いた瞬間に配列「a」が宣言され、少なくともaの範囲としてa[12345:12345]が確保される(多分内部的にはリンクリストになっているんでしょうが)。
疎配列(構成要素のほとんどが None で埋められているような配列)の場合、「値を入れなくちゃいけない所だけ代入すれば、あとは触らなくても勝手に配列が大きくなる」という意味でいろいろ便利なんで、この辺りを多用してまして…。
python sparse arrayでぐぐれば、pythonでは面倒そうなことがわかりますね。そもそも、なぜpython?
- そろそろ python でも勉強しないと、RHELのスクリプトが判らない規模になってきたし…
- Googleも Python 使ってるって言うよな。なら疎配列とかも自在でないと困るよな。彼らも穴だらけの情報を元にした統計処理がメインだし。きっと大丈夫だよ。
- じゃぁ、手元にあるこれを Perl から Pythonに移植してみるかね ←(今ここ)
という状態。
それをだまって0にするperlは最悪なような
統計ライブラリ類はこの辺に手抜きがありますよね。自分で書いている分は if defined() で調べまくって、 undef なものは undef として処理させています。
いや、それでもこれはまだいいのですが、最初いくつ要素があって、いくつデータがあるのか判らないTSVファイルを読み込まなくちゃいけないので、正規表現とかでのデータ切り出しも必要だし、配列を動的に拡大しているのでメモリ空間はフラグメントの嵐になっていてメモリを大量に消費するし…でも、そんな部分を改善するために面倒なコーディングしたくないし。
なので、なんかもっとこう…「いい」感じで手間がかからない、処理速度が速い言語はないものかと。
ただし、できる事ならRHELに対して「新しくインストールする」必要性が無いといいなぁ、というのもありまして。# そういう事をしなくちゃいけなくなると、絶対、手離れが悪くなるから。# Go, R, Ruby はこの段階で優先度が下がる。
そのときふと思い出したんですよ。「あぁ、そういえばPython チュートリアルの2007年版、買ったままだったな」と。
PythonはPerlよりも後発だったよな、型bindingも強かったよな。「じゃぁ、いろいろと処理系側で自動的によきに計らってくれるに違いない」(自動型変換とか。配列の自動拡張とか)。
まさかいまどき「純粋逐次処理系」だとは思いませんでした～～。# 実行速度とかを考えると、これは律速にしかならないので。
最初いくつ要素があって、いくつデータがあるのか判らないTSVファイルを読み込まなくちゃいけない
だけなら、Rでread.table()の一言で終わりですん。しかし、
正規表現とかでのデータ切り出しも必要だし、
だと、rubyのほうが有利かな。
$ irbirb(main):001:0> a=Array.new=> []irb(main):002:0> a[13]=1.26=> 1.26irb(main):003:0> a=> [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 1.26]irb(main):004:0> str="1\t\t2\t3\t4\n"=> "1\t\t2\t3\t4\n"irb(main):005:0> str.chomp.split("\t")=> ["1", "", "2", "3", "4"]irb(main):006:0>
のように、配列であると宣言すれば適当なところに突然代入するのはoktab区切りを、空文字列を含めて配列にするのも大丈夫。（バックスラッシュが通貨記号なのはcygwinでやっていたらそう、、、）
処理速度が速いはおそらくRのほうだろうねえ。
とりあえずrubyはcygwinに入っているじゃあありませんか。RHELは知らないけどCentOSと同じだとすると、root様ならyum install rubyすればその後のupdateも自動。ユーザー権限でいくなら、展開後./configure --prefix=$HOME/ruby192makemake installくらい。(gccとかが入っていれば、、、インストール時の選択しだいで入っていないこともある？)
Rをコンパイルするのはもっとだいぶ面倒なのは確か。（fortranも入れておかないといけないし、そのほかライブラリーがいっぱい）一応、redhat用やwindows用のbinaryはダウンロード可能。しかし、あとのグラフ化まで使えるので、結構意味はあると思う。でも、仮にも教祖様が苦労するレベルではないので、「手離れが悪く」っていうのはほかの人にやらせたいということなら、windows版バイナリーでやれがいいかも:p
自動型変換といえば、perlでは3=="1"+"2"が真だったりするんでしたっけ。文字列は文字列ですから、"12" == "1" + "2"の方が人間的ですぞ。強い型bindingとは相性が悪いでしょう。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
あー、それはmain()内で呼ぶ以外にやりようがないかも (スコア:1)
それより#! /usr/bin/perlが気になります。
署名スパムがウザい？アカウント作って非表示に設定すればスッキリさ。
Re: (スコア:1)
ひゃああああ、
そこはもちろん、#! /usr/bin/python でございますよ。
オリジナルが perl だったってだけで。
しかし。こんなに根性が違うとは思わなかった。python は「初期化時の型」を覚えていて、自動型変換もしてくれないのね…。配列に代入したら自動的に配列に拡張してくれるわけでもない…(そんな配列しらん とか index out of range とか何度言われた事か…いや、まだまだ言われそうだ)。
うぅ、まるでCのようなのに、生半可にいろいろ使える分さらに悩ましい…
fjの教祖様
Re: (スコア:1)
> python は「初期化時の型」を覚えていて、自動型変換もしてくれないのね…。
Pythonの世界では型のチェックだの変換だのはプログラマの責任でどうぞ、ということになってます。
> 配列に代入したら自動的に配列に拡張してくれるわけでもない
「配列」が何を指しているのか判りませんが、ひょっとして文字列を「文字の配列」だと思ってます？Pythonにおいて文字列は文字の配列ではありませんよ。
Re: (スコア:1)
いえ、そうじゃなく。
Perlでは突如として
とか書けるんですよ。こう書いた瞬間に配列「a」が宣言され、少なくともaの範囲としてa[12345:12345]が確保される(多分内部的にはリンクリストになっているんでしょうが)。
疎配列(構成要素のほとんどが None で埋められているような配列)の場合、「値を入れなくちゃいけない所だけ代入すれば、あとは触らなくても勝手に配列が大きくなる」という意味でいろいろ便利なんで、この辺りを多用してまして…。
fjの教祖様
sparse array (スコア:1)
python sparse arrayでぐぐれば、pythonでは面倒そうなことがわかりますね。
そもそも、なぜpython?
Re:sparse array (スコア:1)
- そろそろ python でも勉強しないと、RHELのスクリプトが判らない規模になってきたし…
- Googleも Python 使ってるって言うよな。なら疎配列とかも自在でないと困るよな。彼らも穴だらけの情報を元にした統計処理がメインだし。きっと大丈夫だよ。
- じゃぁ、手元にあるこれを Perl から Pythonに移植してみるかね ←(今ここ)
という状態。
fjの教祖様
PageRank (スコア:1)
Googleの原点といえばPageRank。
これを計算するpythonプログラムは第三者から公開されていますね。
http://www.eioba.com/a69792/the_google_pagerank_algorithm_in_126_lines_of_python
しかし、こいつらは、穴だらけというよりは、つながりのほうが少ないですからなあ。
穴だらけの統計処理だったら第一選択はRというのがなんとなくの雰囲気。
（測定値に穴があるときそこは0ではありませんから
それをだまって0にするperlは最悪なような:）
教祖様におかれましてはここはひとつ、Python, R, Ruby, Go, ...と各種の言語で書き比べて
比較されてはいかがでしょう。
Re:PageRank (スコア:1)
統計ライブラリ類はこの辺に手抜きがありますよね。
自分で書いている分は if defined() で調べまくって、 undef なものは undef として処理させています。
いや、それでもこれはまだいいのですが、最初いくつ要素があって、いくつデータがあるのか判らないTSVファイルを読み込まなくちゃいけないので、正規表現とかでのデータ切り出しも必要だし、配列を動的に拡大しているのでメモリ空間はフラグメントの嵐になっていてメモリを大量に消費するし…でも、そんな部分を改善するために面倒なコーディングしたくないし。
なので、なんかもっとこう…「いい」感じで手間がかからない、処理速度が速い言語はないものかと。
ただし、できる事ならRHELに対して「新しくインストールする」必要性が無いといいなぁ、というのもありまして。
# そういう事をしなくちゃいけなくなると、絶対、手離れが悪くなるから。
# Go, R, Ruby はこの段階で優先度が下がる。
そのときふと思い出したんですよ。
「あぁ、そういえばPython チュートリアルの2007年版、買ったままだったな」と。
PythonはPerlよりも後発だったよな、型bindingも強かったよな。「じゃぁ、いろいろと処理系側で自動的によきに計らってくれるに違いない」(自動型変換とか。配列の自動拡張とか)。
まさかいまどき「純粋逐次処理系」だとは思いませんでした～～。
# 実行速度とかを考えると、これは律速にしかならないので。
fjの教祖様
Re:PageRank (スコア:1)
最初いくつ要素があって、いくつデータがあるのか判らないTSVファイルを読み込まなくちゃいけない
だけなら、Rでread.table()の一言で終わりですん。
しかし、
正規表現とかでのデータ切り出しも必要だし、
だと、rubyのほうが有利かな。
$ irb
irb(main):001:0> a=Array.new
=> []
irb(main):002:0> a[13]=1.26
=> 1.26
irb(main):003:0> a
=> [nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, nil, 1.26]
irb(main):004:0> str="1\t\t2\t3\t4\n"
=> "1\t\t2\t3\t4\n"
irb(main):005:0> str.chomp.split("\t")
=> ["1", "", "2", "3", "4"]
irb(main):006:0>
のように、配列であると宣言すれば適当なところに突然代入するのはok
tab区切りを、空文字列を含めて配列にするのも大丈夫。
（バックスラッシュが通貨記号なのはcygwinでやっていたらそう、、、）
処理速度が速いはおそらくRのほうだろうねえ。
ただし、できる事ならRHELに対して「新しくインストールする」必要性が無いといいなぁ、というのもありまして。
# そういう事をしなくちゃいけなくなると、絶対、手離れが悪くなるから。
# Go, R, Ruby はこの段階で優先度が下がる。
とりあえずrubyはcygwinに入っているじゃあありませんか。
RHELは知らないけどCentOSと同じだとすると、
root様ならyum install ruby
すればその後のupdateも自動。
ユーザー権限でいくなら、展開後
./configure --prefix=$HOME/ruby192
make
make install
くらい。
(gccとかが入っていれば、、、インストール時の選択しだいで入っていないこともある？)
Rをコンパイルするのはもっとだいぶ面倒なのは確か。
（fortranも入れておかないといけないし、そのほかライブラリーがいっぱい）
一応、redhat用やwindows用のbinaryはダウンロード可能。
しかし、あとのグラフ化まで使えるので、結構意味はあると思う。
でも、仮にも教祖様が苦労するレベルではないので、
「手離れが悪く」っていうのはほかの人にやらせたいということなら、
windows版バイナリーでやれがいいかも:p
自動型変換といえば、perlでは3=="1"+"2"が真だったりするんでしたっけ。
文字列は文字列ですから、"12" == "1" + "2"
の方が人間的ですぞ。強い型bindingとは相性が悪いでしょう。