From: "marcandre (Marc-Andre Lafortune)" <ruby-core@...>
Date: 2012-07-25T00:26:53+09:00
Subject: [ruby-core:46732] [ruby-trunk - Feature #6636] Enumerable#size


Issue #6636 has been updated by marcandre (Marc-Andre Lafortune).


Hi,

mame (Yusuke Endoh) wrote:
>  > I am proposing `Enumerator.new(size_lambda){ block }`, i.e. only if a block
>  > is given, then the first argument can be a lambda/proc that can lazily
>  > compute the size.
>  
>  This is just my guess, but matz will not like such a method whose
>  meaning of its argument varies depending on whether block is given
>  or not.

I understand the concern.

It could still be acceptable here because the other form is already documented as 'discouraged'. Maybe we should deprecate it?

Other possibility would be to add a different creator, e.g. `Enumerator.sized(size_lambda){|yielder| ... }`.

>  > The old syntax of `Enumerator.new` without a block does not change meaning.
>  
>  Is it okay that there is no way to specify size in this case?

This old syntax is already discouraged and `to_enum`/`enum_for` should be used instead.

>  > This is why I propose that `to_enum` accepts a block that can calculate the
>  > size, and Enumerator.new with a block can accept a lambda/proc for the
>  > same.
>  
>  What argument(s) will the lambda/proc receive?

We could consider passing the receiver and/or any arguments passed to `to_enum`, but I would propose to keep it simple and pass no arguments.

This is because enumerators are immutable and all information held in Enumerators should be accessible from the block/lambda anyways.
--
Marc-Andr��
----------------------------------------
Feature #6636: Enumerable#size
https://bugs.ruby-lang.org/issues/6636#change-28400

Author: marcandre (Marc-Andre Lafortune)
Status: Open
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: 2.0.0


Now that it has been made clear that `Enumerable#count` never calls `#size` and that we have `Enumerable#lazy`, let me propose again an API for a lazy way to get the size of an Enumerable: `Enumerable#size`.

* call-seq:
*   enum.size  # => nil, Integer or Float::INFINITY
* 
* Returns the number of elements that will be yielded, without going through
* the iteration (i.e. lazy), or +nil+ if it can't be calculated lazily.
* 
*   perm = (1..100).to_a.permutation(4)
*   perm.size              # => 94109400
*   perm.each_cons(2).size # => 94109399
*   loop.size              # => Float::INFINITY
*   [42].drop_while.size   # => nil

About 66 core methods returning enumerators would have a lazy `size`, like `each_slice`, `permutation` or `lazy.take`.

A few would have `size` return `nil`:
  Array#{r}index, {take|drop}_while
  Enumerable#find{_index}, {take|drop}_while
  IO: all methods

Sized enumerators can also be created naturally by providing a block to `to_enum`/`enum_for` or a lambda to `Enumerator.new`.

Example for `to_enum`:

    class Integer
      def composition
        return to_enum(:composition){ 1 << (self - 1) } unless block_given?
        yield [] if zero?
        downto(1) do |i|
          (self - i).composition do |comp|
            yield [i, *comp]
          end
        end
      end
    end

    4.composition.to_a
    # => [[4], [3, 1], [2, 2], [2, 1, 1], [1, 3], [1, 2, 1], [1, 1, 2], [1, 1, 1, 1]]
    42.composition.size # => 2199023255552

Example for `Enumerator.new`:

    def lazy_product(*enums)
      sizer = ->{
        enums.inject(1) do |product, e|
          break if (size = e.size).nil?
          product * size
        end
      }
      Enumerator.new(sizer) do |yielder|
        # ... generate combinations
      end
    end

    lazy_product(1..4, (1..3).each_cons(2)).size # => 8
    lazy_product(1..4, (1..3).cycle).size # => Float::INFINITY



-- 
http://bugs.ruby-lang.org/