Можно ли выполнить сгиб в государственной монаде в постоянном стеке и куче пространства? Или другой функциональный метод лучше подходит для моей проблемы?
В следующих разделах описывается проблема и мотивирующий прецедент. Я использую Scala, но решения в Haskell тоже приветствуются.
Сгиб в State Монада заполняет кучу
Предположим, что Scalaz 7. Рассмотрим монадическую складку в государственной монаде. Чтобы избежать, мы будем трамплировать складку.
import scalaz._
import Scalaz._
import scalaz.std.iterable._
import Free.Trampoline
type TrampolinedState[S, B] = StateT[Trampoline, S, B] // monad type constructor
type S = Int // state is an integer
type M[B] = TrampolinedState[S, B] // our trampolined state monad
type R = Int // or some other monoid
val col: Iterable[R] = largeIterableofRs() // defined elsewhere
val (count, sum): (S, R) = col.foldLeftM[M, R](Monoid[R].zero){
(acc: R, x: R) => StateT[Trampoline, S, R] {
s: S => Trampoline.done {
(s + 1, Monoid[R].append(acc, x))
}
}
} run 0 run
// In Scalaz 7, foldLeftM is implemented in terms of foldRight, which in turn
// is a reversed.foldLeft. This pulls the whole collection into memory and kills
// the heap. Ignore this heap overflow. We could reimplement foldLeftM to avoid
// this overflow or use a foldRightM instead.
// Our real issue is the heap used by the unexecuted State mobits.
Для большой коллекции col это заполнит кучу.
Я считаю, что во время сложения для каждого значения в коллекции (параметр x: R) создается замыкание (мобильность государства), заполняющее кучу. Ни один из них не может быть оценен до выполнения run 0, обеспечивая исходное состояние.
Можно ли избежать использования этого кучи O (n)?
Более конкретно, может ли начальное состояние быть предоставлено перед сгибом, чтобы государственная монада могла выполняться во время каждой привязки, а не закрывать закрытие для последующей оценки?
Или можно построить складку так, чтобы она выполнялась лениво после государственной монады run? Таким образом, следующее закрытие x: R не будет создано до тех пор, пока предыдущие не будут оценены и не станут пригодными для сбора мусора.
Или существует ли лучшая функциональная парадигма для такого рода работ?
Пример приложения
Но, возможно, я использую неправильный инструмент для работы. Далее следует эволюция примера использования примера. Я здесь блуждаю по неверному пути?
Рассмотрим выборки коллектора, т.е. выбор за один прием однородных случайных элементов k из коллекции, слишком большой для размещения в памяти. В Scala такая функция может быть
def sample[A](col: TraversableOnce[A])(k: Int): Vector[A]
и если вы можете использовать тип TraversableOnce, как это показано
val tenRandomInts = (Int.Min to Int.Max) sample 10
Работа, выполняемая sample, по существу, является fold:
def sample[A](col: Traversable[A])(k: Int): Vector[A] = {
col.foldLeft(Vector()){update(k)(_: Vector[A], _: A)}
}
Тем не менее, update является stateful; это зависит от n, количества элементов, которые уже видели. (Это также зависит от RNG, но для простоты я предполагаю, что это глобальный и stateful. Методы, используемые для обработки n, будут распространяться тривиально.). Итак, как справиться с этим состоянием?
Нечистое решение прост и работает с постоянным стеком и кучей.
/* Impure version of update function */
def update[A](k: Int) = new Function2[Vector[A], A, Vector[A]] {
var n = 0
def apply(sample: Vector[A], x: A): Vector[A] = {
n += 1
algorithmR(k, n, acc, x)
}
}
def algorithmR(k: Int, n: Int, acc: Vector[A], x: A): Vector[A] = {
if (sample.size < k) {
sample :+ x // must keep first k elements
} else {
val r = rand.nextInt(n) + 1 // for simplicity, rand is global/stateful
if (r <= k)
sample.updated(r - 1, x) // sample is 0-index
else
sample
}
}
Но как насчет чисто функционального решения? update должен принимать n в качестве дополнительного параметра и возвращать новое значение вместе с обновленным образцом. Мы могли бы включать n в неявное состояние, накопитель складывания, например,
(col.foldLeft ((0, Vector())) (update(k)(_: (Int, Vector[A]), _: A)))._2
Но это скрывает намерение; мы только намереваемся накапливать вектор образца. Эта проблема кажется готовой для государственной монады и монадической левой складки. Повторите попытку.
Мы будем использовать Scalaz 7 с этими импортами
import scalaz._
import Scalaz._
import scalaz.std.iterable_
и работайте над Iterable[A], так как Scalaz не поддерживает монадическое сгибание Traversable.
sample теперь определен
// sample using State monad
def sample[A](col: Iterable[A])(k: Int): Vector[A] = {
type M[B] = State[Int, B]
// foldLeftM is implemented using foldRight, which must reverse `col`, blowing
// the heap for large `col`. Ignore this issue for now.
// foldLeftM could be implemented differently or we could switch to
// foldRightM, implemented using foldLeft.
col.foldLeftM[M, Vector[A]](Vector())(update(k)(_: Vector[A], _: A)) eval 0
}
где обновление
// update using State monad
def update(k: Int) = {
(acc: Vector[A], x: A) => State[Int, Vector[A]] {
n => (n + 1, algorithmR(k, n + 1, acc, x)) // algR same as impure solution
}
}
К сожалению, это ударяет стек в большой коллекции.
Так пусть батут это. sample теперь
// sample using trampolined State monad
def sample[A](col: Iterable[A])(k: Int): Vector[A] = {
import Free.Trampoline
type TrampolinedState[S, B] = StateT[Trampoline, S, B]
type M[B] = TrampolinedState[Int, B]
// Same caveat about foldLeftM using foldRight and blowing the heap
// applies here. Ignore for now. This solution blows the heap anyway;
// let fix that issue first.
col.foldLeftM[M, Vector[A]](Vector())(update(k)(_: Vector[A], _: A)) eval 0 run
}
где обновление
// update using trampolined State monad
def update(k: Int) = {
(acc: Vector[A], x: A) => StateT[Trampoline, Int, Vector[A]] {
n => Trampoline.done { (n + 1, algorithmR(k, n + 1, acc, x) }
}
}
Это исправляет переполнение стека, но все равно удаляет кучу для очень больших коллекций (или очень маленьких куч). Одна анонимная функция за
значение в коллекции создается во время сгиба (я считаю, что нужно закрыть каждый параметр x: A), потребляя кучу до того, как батут будет запущен. (FWIW, версия State также имеет эту проблему: переполнение стека сначала покрывает меньшие коллекции.)