Я понимаю, что список действительно содержит значения, а последовательность является псевдонимом для IEnumerable<T>
. Когда в практической разработке F # мне следует использовать последовательность, а не список?
Вот несколько причин, по которым я могу понять, когда последовательность будет лучше:
- При взаимодействии с другими языками .NET или библиотеками, которым требуется
IEnumerable<T>
. - Необходимо представить бесконечную последовательность (вероятно, не очень полезно на практике).
- Нужна ленивая оценка.
Есть другие?
seq
сгенерированный таким образом файл будет выдавать разные случайные числа каждый раз, когда вы на него смотрите. Очевидно, это может быть источником недетерминированных ошибок ...Ответы:
Я думаю, что ваше резюме относительно того, когда выбирать
Seq
, довольно хорошее. Вот еще несколько дополнительных моментов:Seq
по умолчанию при написании функций, потому что тогда они работают с любой коллекцией .NET.Seq
если вам нужны расширенные функции, такие какSeq.windowed
илиSeq.pairwise
Я думаю, что выбор
Seq
по умолчанию - лучший вариант, так когда же мне выбрать другой тип?Используйте,
List
когда вам нужна рекурсивная обработка с использованиемhead::tail
шаблонов(для реализации некоторых функций, недоступных в стандартной библиотеке)
Используйте,
List
когда вам нужна простая неизменяемая структура данных, которую вы можете построить шаг за шагом(например, если вам нужно обработать список в одном потоке - чтобы показать некоторую статистику - и одновременно продолжить построение списка в другом потоке по мере получения больше значений, например, от сетевой службы)
Используйте,
List
когда вы работаете с короткими списками - список является лучшей структурой данных для использования, если значение часто представляет собой пустой список , потому что он очень эффективен в этом сценарииИспользуйте,
Array
когда вам нужны большие коллекции типов значений(массивы хранят данные в плоском блоке памяти, поэтому в этом случае они более эффективны с точки зрения памяти)
Используйте,
Array
когда вам нужен произвольный доступ или более высокая производительность (и локальность кеша)источник
List
[...], когда вам нужна простая неизменяемая структура данных, которую вы можете построить шаг за шагом [...] и одновременно продолжить построение списка в другом потоке [...]» Не могли бы вы подробнее рассказать о своем имеется в виду здесь / как это работает? Благодарю.x::xs
без нарушения каких-либо существующих рабочих процессов, которые могут быть в процессеxs
Также предпочитаю,
seq
когда:Вы же не хотите хранить в памяти все элементы одновременно.
Производительность не важна.
Вам нужно что-то сделать до и после перечисления, например, подключиться к базе данных и закрыть соединение.
Вы не соединяетесь (повторение
Seq.append
приведет к переполнению стека).Предпочитаю,
list
когда:Есть несколько элементов.
Вы будете много готовить и обезглавливать.
Ни то,
seq
ни другое неlist
подходят для параллелизма, но это не обязательно означает, что они плохие. Например, вы можете использовать любой из них для представления небольшой группы отдельных рабочих элементов, которые должны выполняться параллельно.источник
Только одна маленькая деталь:
Seq
иArray
лучше, чемList
для параллелизма.У вас есть несколько вариантов: PSeq от F # PowerPack, Array.Parallel модуля и Async.Parallel (асинхронные вычислений). Список ужасен для параллельного выполнения из-за его последовательной природы (
head::tail
композиции).источник
Array
илиPSeq
намного лучше.seq
это лучше, чемlist
параллелизм?seq
также ужасны для параллельного выполнения из-за их последовательной природы ...list более функциональный, удобный для математики. когда каждый элемент равен, 2 списка равны.
последовательность нет.
let list1 = [1..3] let list2 = [1..3] printfn "equal lists? %b" (list1=list2) let seq1 = seq {1..3} let seq2 = seq {1..3} printfn "equal seqs? %b" (seq1=seq2)
источник
Вы всегда должны предоставлять
Seq
в своих общедоступных API. ИспользуйтеList
иArray
в своих внутренних реализациях.источник
Seq
рассматривается какIEnumerable<T>
?seq
, что настолько плохи для параллелизма.