Re: Enumerable#uniq, anybody?

At 00:06 07/12/22, murphy wrote:
>Martin Duerst wrote:
>> At 20:20 07/12/17, murphy wrote:
>>> Martin Duerst wrote:
>>>> However, it looks somewhat ugly and unnecessary, and it isn't compatible
>>>> with 1.8. This could easily be fixed by adding uniq to Enumerator, the
>>>> simplest form being:
>>>>     def uniq
>>>>       to_a.uniq
>>>>     end
>>> the current implementation of uniq depends on the receiver being
>>> converted into a hash table (to make it O(m) instead of O(m**2)). you
>>> probably wouldn't expect that from an enumerator...to_a makes it clear,
>>> though.
>> 
>> I don't understand your argument. to_a means "convert to an Array",
>> not "convert to a Hash". How uniq is implemented internally shouldn't
>> bother anybody (as long as it is fast).
>I was under the impression that all Enumerator methods only traverse the
>sequence when called with a loop, making them perfectly usable with an
>infinite enumerator

I think I know what you mean, but I think the right way to express this
to say than an Enumerator is only traversed when needed.

>(eg. [0].cycle and breaking after a timeout or
>something), except the obvious #to_a/#entries. but #sortis an  exception
>already.

Yes, it's impossible to sort unless you have all entries. It's
impossible to create an array unless you have all entries. It's
also impossible to check uniqueness unless you have all entries.

>perhaps it feels just strange for me that #uniq would traverse the
>Enumerator twice...not if we implement it as to_a.uniq, of course.

I don't think #uniq would traverse the Enumerator twice,
either way.

There are many Enumerators and enumerators. At least the following
distinctions may be relevant, maybe there are others:
- Finite ones and infinite ones (Arrays and Files are finite,
  but some sensors or loops may be infinite)
- Looping ones and non-looping ones
- Repeatable ones and non-repeatable ones (some repeat by design,
  some can be repeated, but some, e.g. network communications,
  may not be repeatable)

In general, most methods work only with a subset of enumerators.
In general, it's fairly clear what the subset is. This is in many
ways similar to duck typing, but the types are totally  implicit
(there's currently no way to ask an enumerator whether it's
finite or not; there are some brute force methods to show
finiteness, but not to show infiniteness). The main thing to loo
out when designing a method for an iterator is that it should
work for all kinds of iterators where it possibly makes sense.

Regards,    Martin.


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]