[ruby-dev:38937] Re: Enumerator#peek

けいじゅ＠いしつかです.

In [ruby-dev:38935] the message: "[ruby-dev:38935] Re:
Enumerator#peek", on Jul/29 00:29(JST) Tanaka Akira writes:

>> あるグループに分けて集計したいなら, 下記のような方が Ruby ぽいかも.
>> a = %w[banana banana durian orange orange orange]  
>> a.group_by{|w| w}.each{|key, values| puts "#{key} #{values.size}"}
>> MapReduce系では上記のような感じで書くことが多いと思います. 
>
>group_by は残念なことにぜんぶメモリに読み込むことになるんで
>すよね。

たしかに, Rubyのはそうなっていますよね.

ただ, ソート済みを前提としないで処理できるので, ソートされてない状態の
ものをわざわざソートしてコントロールブレーク処理するのと変わらないかも
知れません.

>ソート済みであることを前提としてシーケンシャルに処理できるメ
>ソッドも当然あり得て、それはそれで考えています。
>[ruby-dev:38392] から始まるスレッドで、ちょっとほったらかし
>にしているのですが、忘れているわけではありません。

以前そんな話題がありましたね. 結構参考になるところが多いかも

>そういう、シーケンシャルに処理する操作の中で、peek はかなり
>低級なところを支援する話にあたります。

なるほど.

>狙っているところが違う感じでしょうか。

うーん. Enumeratorってかなり応用的なクラス(Enumerabbleから生成される)
なので, peekっていうのは, ちょっと違和感があるかも.


>[ruby-dev:38392] からの提案はいろいろと変遷しているのですが、
>現時点での形態の slice_by だと次のように書けます。
>
>a = %w[banana banana durian orange orange orange]
>a.slice_by {|w| w }.each {|key, values| puts "#{key} #{values.size}"
>}  

ソートされているという前提でですね. ということは, slice_byさえあれば, 
コントロールブレーク処理ではpeekは必ずしも要らないって言っていません?

>まぁ、values が大きくなるとメモリの点では悲しいケースが出て
>くるかも知れませんが。

たしかに, fairyでもgroup_byでvaluesを渡すのはどうかと言われています
(^^;;

>> の様にも書けます. (1)が味噌なんですが... (1)しなくてもちゃんと処理して
>> くれるeach_with_peek見たいのがあってもよいかも?
>
>最初か最後で特別扱いが必要なのであんまりよくないと思います。

それはそうですね. 

>あと、コントロールブレイクを検索したところ、どうやら複数のキー
>を扱うことも珍しくないようです。

>でも、each_with_peek のようなイテレータではこういう多重ルー
>プは実現できません。おそらく。

うーむ. 

>ここで、上記の多重ループは再帰降下パーザとみなすこともできま
>す。そのように考えてトークンの取得に相当するところに
>Enumerator#{peek,next} を使うと、これは実現できます。

たしかに. ただ:

>なぜ内部イテレータでなく、外部イテレータを拡張しているのか、
>という理由はここにあります。

each_with_peekもEnumeratorのつもりなので外部イテレータにできると考えて
います. それにslice_byでもEnumeratorとして扱えば実現可能な気がしますが?

peekで出来ることが, slice_byの様なものですべて実現可能ではないかも知れ
ませんが, slice_byみたいなものの方が好みだなぁ.


__
---------------------------------------------------->> 石塚 圭樹 <<---
---------------------------------->> e-mail: [e-mail] <<---