Я заметил этот метод combinations (из здесь ) возвращает Iterator. Кажется разумным, что метод должен быть ленивым, чтобы избежать генерирования всех комбинаций заранее. Теперь мне интересно, почему он возвращает Iterator вместо Stream (это ленивый список в Scala).
Итак, почему combinations возвращает Iterator, а не Stream?
С Stream более вероятно, что все сгенерированные значения будут храниться в памяти.
scala> val s = Stream.iterate(0)(_ + 1)
s: scala.collection.immutable.Stream[Int] = Stream(0, ?)
scala> s.drop(3).head
res1: Int = 3
scala> s
res2: scala.collection.immutable.Stream[Int] = Stream(0, 1, 2, 3, ?)
Когда вы сохраните ссылку на свой Stream, все сгенерированные элементы останутся в памяти. С Iterator это менее вероятно.
Конечно, это не должно быть причиной того, что библиотека Scala спроектирована именно так...
Я думаю, потому что Stream кэширует все ранее возвращенные элементы, поэтому в конечном итоге все они будут в памяти. Итератор возвращает только следующий
Как я вижу в коде CombinationsItr, у вас есть ленивая оценка каждый раз, когда вы вызываете метод next. См. https ://lampsvn.epfl.ch/trac/scala/browser/scala/tags/Rnext9CombinationsItrfinal/src//library/scala/collection/SeqLike.scala#L198
Итак, при использовании next для получения следующей комбинации, например:
scala> val combinations = "azertyuiop".combinations(2)
scala> combinations.next
res9: String = az
результат next оценивается лениво.
Iterator (lampsvn.epfl.ch/trac/scala/browser/scala/tags/Rdrop9Iteratorfinal/src/), метод drop вернет новый экземпляр Iterator, который ссылайтесь на предыдущий (где вы вызываете drop). Это означает, что даже отброшенная версия Iterator будет оцениваться лениво (но будет содержать собственный счетчик remaining).
- person David; 02.12.2011
Iterator дешевле, чем Stream. Вы всегда можете получить последнее из первого, если вам нужно.
