[#38782] [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...>

こんにちは、なかむら(う)です。

15 messages 2009/07/14
[#38784] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/14

永井@知能.九工大です.

[#38790] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38791] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/15

永井@知能.九工大です.

[#38792] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38793] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — Hidetoshi NAGAI <nagai@...> 2009/07/15

永井@知能.九工大です.

[#38794] Re: [Bug:trunk] Re: [ruby-cvs:31281] Ruby:r24063 (trunk): * ext/tk/extconf.rb: New strategy for searching Tcl/Tk libraries. — "U.Nakamura" <usa@...> 2009/07/15

こんにちは、なかむら(う)です。

[#38843] 複素数リテラルについて — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

32 messages 2009/07/21
[#38855] Re: 複素数リテラルについて — Yusuke ENDOH <mame@...> 2009/07/22

遠藤です。

[#38857] Re: 複素数リテラルについて — Tadayoshi Funaba <tadf@...> 2009/07/22

> は十分検討されたのでしょうか。積極的に反対なわけではないですが、

[#38912] String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...>

xibbarこと藤岡です。(なぜか届かないので再送します)

19 messages 2009/07/27
[#38918] Re: String#valid_encoding?にオプションが欲しい — "NARUSE, Yui" <naruse@...> 2009/07/27

成瀬です。

[#38925] Re: String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...> 2009/07/27

xibbarです。

[#38927] Re: String#valid_encoding?にオプションが欲しい — Fujioka <fuj@...> 2009/07/28

xibbarです。

[#38914] [Bug #1819] Ruby-1.9.1を使用しDB(MySQL)接続時にエラー — Ryouhei Saita 斉田 <redmine@...>

Bug #1819: Ruby-1.9.1を使用しDB(MySQL)接続時にエラー

11 messages 2009/07/27

[#38932] Enumerator#peek — Tanaka Akira <akr@...>

Enumerator#peek を新設するのはどうでしょうか。

16 messages 2009/07/28

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

From: Tanaka Akira <akr@...>
Date: 2009-07-31 16:54:29 UTC
List: ruby-dev #38973
In article <E1MWVSs-0006xI-Nc@keiju.ishitsuka.com>,
  keiju@ishitsuka.com (石塚圭樹) writes:

> fairyでは, 分散ソートの内部処理でマージソートを使っているのですが, そ
> ういうのがあるとかなり便利です(^^;;

ソート済みのを複数マージするというのは、内部イテレータではで
きないので、やっぱり外部イテレータを使うことになります。

この場合 peek は... マージの途中で中断したときに要素が蒸発し
てしまわないようにするのに利用できますね。まぁ、すごく役に立
つというほどではありませんが。

あと、2個じゃなくて一般に n個をマージ、とか考えると、まず優
先順位つきキューが欲しいですよねぇ。なんで標準添付されていな
いんだろう。

> 私もそう思っています. それに, threadをまたげないので, 複数スレッドにま
> たがるqueue見たいのも実現できないですし...

あぁ、thread のことは気がついていませんでした。そういう利点
もありますね。

>>IO, Array, Range 等、基本的なクラスの Enumerator は、ちょっ
>>とがんばって効率の良い外部イテレータを提供して良いのではない
>>かと思っています。
>
> Arrayなんかは, 上記の Enumerator.external_iterator みたいな, やり方で
> は実現できそうもない(fiber使えば別ですが(^^;;)ので別途対処が必要ですね.

たとえば配列なら、

  i = -1
  Enumerator.external_iterator { 
    i += 1
    raise StopIteration if ary.length <= i
    ary[i]
  }

というようにできます。

まぁ、rewind や marshal をどうするかとか、each を呼んだらど
うするかとか、あまり完全とはいえないのも事実ではあるのです
が、うまくいくデザインも可能だろう、と思っています。

> a.inject_by(proc{|w| w}){|key, sum, value| sum += 1}.each{|key,sum| puts "#{key} #{sum}"}
>
> でした. この場合valueには w 自身が渡るのですが. ワード数だけカウントす
> るので1足せばよいことになります.
>
>>思うに、複数のマシンに分散させて処理をやろうというなら、単語
>>数を数えるときの足し算のように associative な演算は、
>>associative であることを利用した仕掛けでやったほうがいいんじゃ
>>ないかなぁ、と思います。associative であれば、つまり、
>>(a+b)+c=a+(b+c) のような関係の演算であれば、各マシン内で個々
>>に結果をまとめられますから。
>
> 実際はそのように処理します. まず, ローカルでinject(reduce)して, 各ノー
> ドのものをまとめてinject(reduce)します. ですので, 結合律は前提になって
> います. 

えーと、ブロックの中を sum += 1 としてしまったので、
inject_by はそうはできなくなっている、と思うんですがどうでしょ
う。

sum += 1 というブロックを使って sum1 + sum2 という足し算を行
うのは無理っぽいですよね。

> あー. inject ってそんなイメージあります? いちおう, reduceという名前も
> aliasしていますが, Rubyのinjectと似ているので同じ名前にしました.

inject という名前は Ruby でしか経験がないので、偏ってるかも
しれません。

>>あと、slice_by は配列にしちゃいますから、メモリの点で嫌です。
>
> a = %w[banana banana durian orange orange orange]
> a.slice_by {|w| w }.each {|key, values| puts "#{key} #{values.size}" }  
>
> の values のことです? 

はい。

> 2段のコントロールブレーク処理を勘違いしていなければですが.
>
> なんだか, slice_byは結構使えるかもって気になってきました(^^;;;
> 配列はどんどん出来てしまいますけどね(^^;

配列を作ってしまって良ければ、できます。

peek の意図は、それを避けたいという話です。

> slice_byを Ruby(のスクリプト)で実現したければ peekもしくはpeekと同じ処
> 理が必要になりますね. ---(1)

いや、slice_by は内部イテレータで実装します。外部イテレータ
は使いませんので、peek も使いません。内部イテレータを使うと
きでも先読みを行う (というか、処理を一巡遅延させる)、という
意味でしたらそのとおりですが。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

In This Thread