#gosh> (do-generator (p (gtake (giota -1) 10)) (d p) )
#<eof>
gosh> (stream->list (stream-take (stream-iota -1) 10) )
(0 1 2 3 4 5 6 7 8 9)
#generatorのgiotaの動作なのですが、無限列を生成できないようです。
#generatorではgiotaは有限、grangeで無限という括りがあるのでしょうか？
#ああ、単純にiotaのインタフェースに合わせただけで、stream-iotaのその動作は失念してました。特に考えがあっての制限ではないので後で拡張しときます。
#了解です。
#grangeでも代用可能だったで、そういう文化なのだろうか？と考えてしまいました ^^;
#というか無限列なら(giota +inf.0)でいけるからいいか、と思ってた覚えがある。
#「-1で無限列」っていうのはちょっと特殊ルールだから。でもstream-iotaが既にそういうルールなら合わせるのにやぶさかではない。
#あーでも(giota +inf.0)だと不正確数の列にならないと一貫性がないか。今、正確数になるのはおかしいな。
#(grange)で無限列になるように、(iota)で無限列が出るといいような気がするのですが、それだとstreamと合わないことになりますね・・・・
#(giota +inf.0)で「不正確数の列にならないと一貫性がない」というのは,
#どういった意味でしょう?
#今の実装だと (iota 3.0) で (0.0 1.0 2.0) が返りますが、そもそも個数なのだから (0 1 2) で良いような気がします。
#Racketだと (iota 3.0) で (0 1 2) が得られますね。
#(iota 3.0) を実行して不正確数だったので合わせた方がいいなと思ったんですが、確かに個数なのだからそこは正確性に影響を与えないでいいか。
#srfi-1には特に記述がないな。なんでcountが不正確数なら不正確にしたか、覚えてないけど、「引数が不正確数なら結果も不正確数」という原則をあまり考えずに適用したのかもしれない。
#寧ろ，個数って正確数じゃなくてもいいものなんでしょうか．
#インデックスに正確数が要求されることを考えると正確数に制限したくなりますが、+inf.0を与えて無限列、という仕組みは諦めるには惜しいなと思います。そういえばそのせいでgrangeのendは結果の正確性に影響を与えないことにしたんだった (endが+inf.0なら無限列、とするため)
#+inf.0すら書きたくないと思っちゃいます．そうするとiotaともrangeとも異なる新たなインタフェイスが必要になりますが．
#デフォルトが+inf.0であるとすればいいんじゃないですか。(giota)で無限列生成。startやstepを指定したい時だけ(giota +inf.0 5)とかになる。(giota -1 5)より見た目わかりやすいと思いますが。
#-1よりは+inf.0の方が分かりやすいと思います．引数の順番がstart, step, lengthみたいなものがあればstart, stepを指定しても+info.0を書かなくて済むなぁと考えていました．
#s/info/inf/
#なるほど。count start step でも start end step でもない順序か。確かにstart stepだけ指定したい場合ってのはあるけど、さすがに似たようなAPIが増えすぎるかなあとは思う。golferにとっては欲しいだろうけど。
#正確数が来るべき所と考えると，+inf.0でも'infinityって書いてるのと気分的にはあんまり変わらないんですよね．似たようなのが増えすぎるというのは私も思いました．やっぱりそうなりますよね…．
#超限順序数を導入して (giota ω) と書けるようにする、とか。
Gauche > Archives > 2012/07/19