Зачем нам нужна pack_padded_sequence (), когда у нас есть pack_sequence ()?

Question

После прочтения ответов на этот вопрос я все еще немного запутался по поводу всего объекта PackedSequence. Насколько я понимаю, это объект, оптимизированный для параллельной обработки последовательностей переменного размера в рекуррентных моделях, проблема, для которой заполнение нулями является одним [несовершенным] решением. Похоже, что при наличии объекта PackedSequence RNN Pytorch будет обрабатывать каждую последовательность в пакете до конца и не будет продолжать обрабатывать заполнение. Так почему же здесь нужна прокладка? Почему существуют методы pack_padded_sequence () и pack_sequence ()?

Answer 1

В основном по историческим причинам; torch.nn.pack_padded_sequence() был создан до torch.nn.pack_sequence() (позднее он появился в 0.4.0 впервые, если я правильно вижу), и я полагаю, что не было причин удалять эту функцию и нарушать обратную совместимость.

Кроме того, не всегда понятно, какой самый лучший / самый быстрый способ pad вашего ввода, и он сильно зависит от данных, которые вы используете Когда данные были каким-то образом дополнены заранее (например, ваши данные были предварительно дополнены и так вам предоставлены), быстрее использовать pack_padded_sequence() (см. исходный код pack_sequence, он вычисляет length из каждая точка данных для вас и звонит pad_sequence, а затем pack_padded_sequence внутри). Возможно, сейчас pad_packed_sequence редко используется.

Наконец, обратите внимание на аргумент enforce_sorted, предоставленный начиная с версии 1.2.0 для обеих этих функций. Не так давно пользователям go приходилось сортировать свои данные (или пакеты) с самой длинной последовательностью первой и самой короткой последней, теперь это можно сделать внутренне, если для этого параметра установлено значение False.