パスワードを忘れた？ アカウント作成
Close
247484 journal

okkyの日記： 【教えてPythonのエロい人】固定長配列を一気に作るには? 14

日記 by okky

次の問題(すでにシリーズ化の予感)
今、ファイルを読んで split でキーワードの配列 key を作った。
で、その配列の要素数 len(key) だけ、class Column の配列dを作りたい。
しかし、配列の大きさは判ってるんだから、1つづつ
d.append( Column() )
ってやるのは何となく嫌だ。メモリがフラグメンテーションを起こす予感がする。何より、実際には
 d    = 配列を作れ( len( key ))
for i in range(len(key)):
    d[i] = Column( key[i] )
  
のようにして、d[i].key に key[i] の値が入るようにしたい。とりあえず要素としては None が入っていてくれればいいんだが…。
…まさか
     d      = range( len( key ) )
  
で適当な数字を作って、それを上書きするしかないのか??!
     d      = generate_list( size, initvalue )
  
的なインターフェースはないのか?
キーワードの状態によっては Column オブジェクトではなく None を入れたい(配列としてはスキップできない。この後でデータを読むフェーズが待っていて、d[i]がNoneだったら読んだ値をスキップしたい)。
この議論は、okky (2487)によって ログインユーザだけとして作成されたが、今となっては 新たにコメントを付けることはできません。

【教えてPythonのエロい人】固定長配列を一気に作るには? More


  • といういうか初心者で、これからPython勉強しようとしてるところ。
    のでググってみた、まだためしてない。
    Python: リストの初期化・出力・代入 - Yukun's Blog [yukun.info] 
    inilist = [0] * 4 # 0で初期化された要素が4つのリスト
    というのがあった、これPython3系でも問題なく使えるのかな?
    直感的というとちょっとアレですが
       [] : リストのリテラルであること
       0 : 初期化する時の要素リテラル
       * 4 : その要素数についてのHint
    と見ればいいのかな、でもちょっとだけ変な気もする。
    --
    M-FalconSky (暑いか寒い)

  • 少なくとも CentOS5 には標準でパッケージがあるので yum で一発インストールだし。
    この辺 [nasuinfo.or.jp]が参考になるのでは。


  • そもそもリスト︵﹁配列﹂ではありません。なぜなら﹁配列﹂は別にあるから！︶の要素がメモリ上にズラリと連続して割り当てられる保証はどこにもありませんので、気にしたら負け。
    どうしてもそこにこだわるなら、処理系に頼らず自分でメモリ管理する︵＝Cとか他の言語で拡張モジュールを書く︶以外に方法はありません。
    なお、すでに他の方のコメントに出ている
    >>> d = [None] * len(key)
    >>> d = [Column(k) for k in key]
    とか、
    >>> d = map(Column, key)
    の類は、内部的には﹁空のリストを生成して逐一append()﹂と全く同じです。
    標準のarrayモジュールとかNumeric Pythonのarrayモジュールとかは、連続したメモリ領域に要素を格納する﹁配列﹂を提供しますが、格納できるデータの型に制約がある︵早い話が﹁数﹂しか格納できない︶のでアウト。
    つまり﹁無理﹂ってことです。
    そもそも、とりあえず書いて動かしてみて﹁遅くて堪らん、原因はメモリの断片化だ﹂と判明したときに初めて﹁連続したメモリに割り当てられないものか﹂と考えるのがPython流です。教えてエロい人してる暇があったら、とっとと書き上げて動かしてみては。

  • 何となく嫌だ。メモリがフラグメンテーションを起こす予感

    とか

    d[i]がNoneだったら読んだ値をスキップしたい


    とか発想がなんかずれとります。所詮Cより2－3桁遅いインタープリターで
    解釈するのにいまさらフラグメンテーションて、、、。
    後で読んだ値は、各Columnの値受け取りメソッドに渡すんですよね、
    わざわざd[i]がNoneかどうか調べてスキップするとかするよりは、
    ブラックホールなobject︵同名メソッドで何もしないサボり︶を入れておいて、
    全部そのまま渡したほうがすっきりするだろうし。
    なんか無駄に勤勉ですね。
    小人さんにやってもらうべしという教義だと思っていたのですが。

    • 所詮Cより2－3桁遅いインタープリターで解釈するのにいまさらフラグメンテーションて、、、。
      これを考えないと、メモリ不足…というよりもアドレス不足が乱発するからです。GCがかなりの頻度で動き続けているので。
      後で読んだ値は、各Columnの値受け取りメソッドに渡すんですよね、
      わざわざd[i]がNoneかどうか調べてスキップするとかするよりは、
      ブラックホールなobject︵同名メソッドで何もしないサボり︶を入れておいて、
      全部そのまま渡したほうがすっきりするだろうし。
      んー、それはひとつの手ではありますが…どうだろう。Noneを使っておいて、例外がでたら exception で捕まえて﹁わかった、じゃ、それは処理しなくていいから、次﹂ってやるのとどっちが楽かな～
      なんか無駄に勤勉ですね。
      小人さんにやってもらうべしという教義だと思っていたのですが。
      小人さんに丸投げするのは、小人さんの気持ちが見抜いて得手不得手が判るようになってからです。
      小人さんの得手不得手をきちんと見極めるには、
      ﹁多くのお手本にはこう書いてある﹂
      的なコーディングじゃ駄目なんですよ。いろいろ表現を替えてみて、どこで変化がでるのか見なくちゃいけない。別にお手本が最適な書き方だったとしても、じゃぁなぜそれが最適になるのか、は知っておかないといけない。だから違う書き方で様子をみる必要がある。
      そして、それこそが新しいプログラミング言語を身につける上で楽しいところじゃないですか。
      同じことをするのに複数の書き方で書いてみて、何がどう変わるのか知ってこそ、﹁処理系の気持ちが判った﹂と言えるというものです。
      --
      fjの教祖様
      シェア
      親コメント

      • 小人さんの気持ちが見抜いて得手不得手が判るようになってからです。

        メモリ不足…というよりもアドレス不足が乱発するからです。GCがかなりの頻度で動き続けているので。


        うーん。小人さんの気持ちを調べるということをしていないのですね。
        GCが動くのは、どういうときなのか、べつに、メモリやアドレスが不足するからじゃあないですよ？
        http://docs.python.org/library/gc.html [python.org]
        700ほどobjectの生成が破壊より多いと、早速はじめるんですよ。
        pythonはreference countingでの管理が効いているから、
        cycleを作っていない限り読み込んでデータ構造の
        構築中GCはとめて置いたらいいでしょう？
        メモリーが足りないというのは、OS側でswapが発生してthrashingしたり、allocateできないといって殺されたり
        するようなら足りないのでしょう。
        シェア
        親コメント

        • pythonはreference countingでの管理が効いているから、
          cycleを作っていない限り読み込んでデータ構造の
          構築中GCはとめて置いたらいいでしょう？
          それはもうやりました。メモリ不足で吹き飛びました。
          インタープリターが消費しているメモリの総量は top で観察できます。
          こいつがもうすでにアドレス空間の限界ギリギリまで行ってますので、アドレス不足なのは確実です。
          # 同じことは Windows だとパフォーマンスモニターを使って観察できる。
          GCが動くのは、どういうときなのか、べつに、メモリやアドレスが不足するからじゃあないですよ？
          http://docs.python.org/library/gc.html [python.org]
          700ほどobjectの生成が破壊より多いと、早速はじめるんですよ。
          それはGCを kick する条件の1つに過ぎません。
          メモリがフラグメントを起こして﹁空き領域的にはちゃんとありそうだが、連続したメモリを確保できない﹂場合にもGCは動きます。PythonのGCにはコンパクション機能があるので、データを動かして空き領域を連続させる機能があります (このへんが Perl と違ってえらいところやね)。これを使って、連続した空きメモリを確保するわけです。
          テキストを読んで、split しては、floatに変換し、またテキストを読んで…を繰り返しているので、コンパクション大活躍状態のようです。
          --
          fjの教祖様
          シェア
          親コメント

          • 32bit world! (スコア:1)

            by tslashn (37583) on 2010年08月19日 21時30分 (#1812444)

            アドレス空間の限界


            おお、そんなことでは、銀河制圧は遠そうですね。
            しかし、instanceが一つしかないColumnのコンテナを工夫するよりは、
            Columnの構造をがんばるほうが先でしょう。
            ここは、一般のObjectじゃなくて数値の配列とかを使う余地があるでしょう？
            とりあえずこれで倍くらいは効きそう。
            あと、連続して値がないところはサボるとか。
            行数が微妙なところまではいけているのか、桁が違うのかそこも問題ですな。
            シェア
            親コメント

      • Noneを使っておいて、例外がでたら exception で捕まえて「わかった、じゃ、それは処理しなくていいから、次」ってやるのとどっちが楽かな～

        Columnのほうで生じた悪い例外でなくて、「それは処理しなくていい」ことなのを保証するのが面倒すぎ。 それなら、勤勉なコードのほうがましだと思います。

        シェア
        親コメント

      • 目的と手段を混同しているような。
        インタプリタの挙動を把握したいのであれば、ここで聞く前に自分でいろいろ書いてみるべきでは。
        さらに手離れを良くしたいのであれば速度云々より変則的なコーディングは避けるほうがいい。
        なんとなく個人的なスキルとしてあるだけで、引き継ぎの際には﹁速いコーディング﹂とやらは引き継がれない気がする。
        業務で使用するなら、本来はpythonを使用すべきか︵今perlで稼働しているなら、積極的に置き換える理由︶から検討すべきじゃない？
        本当にpythonが必要なんですか、Rじゃダメなんですか、と。
        シェア
        親コメント

        • インタプリタの挙動を把握したいのであれば、ここで聞く前に自分でいろいろ書いてみるべきでは。
          それは順序を混同している。
          ﹁いろいろ書く﹂ためには﹁いろいろな書き方﹂を先に知らなくちゃいけない。
          ﹁いろいろな書き方﹂は普通に調べても簡単には出てこない。
          もちろん、アルゴリズム的なものに関してはおっしゃるとおりだが、
          ﹁配列﹂的なものを最初に一括して領域確保する方法、
          のようにかなりシステムプリミティブな場合は、聞かないと判らない。
          --
          fjの教祖様
          シェア
          親コメント
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond