Вам нужно идти на программу Соловьёва. Вернётся только один.
Да ну? А откуда же их брать? Получать из последовательности, которая не хранится в памяти? За каждым индексом обращаться к последовательности? Ну хорошо, как Вы себе представляете обработку пятого вхождения, если восьмое пересекается с девятым?
И да, забыл, последовательности в школе могут не проходить вообще, а вот поиск и замену в строках проходят всегда.
Как и лямбды. И ничего в этом хорошего.
Это не практичный случай. Загадать можно что угодно.
Из того что я могу представить - когда надо взять несколько индексов вместе, всего их будет штук 5-10.
Да и, опять же, конкретно то что вы сказали - делается записыванием пятого индекса в локальную переменную, с последующей проверкой 8 и 9. То есть 3 индекса в памяти одновременно. И то - на стеке.
В любом случае. Последовательностью оказалось таки немного медленнее, чем если возвращать список. Но в общем случае - если возвращать массивом то, что в любом случае вычисляется потоково - это навязывание.
Кому надо - может вызвать .ToList, сделав, по сути, то же самое, что и заполнение списка внутри подпрограммы поиска.
Но если возвращать последовательность - тот же вариант, получается, сможет работать и без сохранения элементов в памяти. Чего не достичь, если список уже создаётся в подпрограмме поиска.
1 лайк
Потоково - это лично Ваша страсть, и делать выводы о том, что всем нужна последовательность - это как раз и есть навязывание.
Честно говоря, в данном случае я затрудняюсь, что возвращать, последовательность, массив или список. Однако a.Indices(…) возвращает последовательность, s.Matches - тоже последовательность. В стандартной библиотеке должна быть какая-то регулярность.
Я недавно принимал решение по поводу типа, возвращаемого gg.EachCount. Я несколько дней мучался. Список пар, массив пар… В Котлине возвращается словарь. И я вернул словарь. Причем, Dictionary.
Возвращать массив имеет смысл только тогда, когда нужна особая скорость + заранее известно кол-во элементов.
Если тоже нужна скорость, но не известно кол-во элементов - список.
А если универсальность важнее скорости - лучше использовать последовательность. И давать пользователю подпрограммы возможность решить, что дальше с последовательностью делать.
Но, опять же, если заранее известно кол-во элементов результата - эту информацию выкидывать не стоит.
Но, что точно можно сказать - универсальность в стандартной библиотеке всегда важнее регулярности решений. Потому что весь смысл стандартной библиотеки - иметь стандартный набор инструментов, которые в большинстве случаев позволят не писать что то вроде своего .Select для каждого проекта.
Это же какую такую универсальность последовательность дает? Чем она универсальнее массива? Тем, что для доступа к i-му элементу надо просмотреть i-1 предыдущий? Тем, что по последовательности нельзя идти от начала к концу? Если бы последовательность была такой “универсальной”, мы бы до сих пор работали не с дисковыми накопителями и флеш-памятью, а с магнитной лентой! Это же надо сморозить такое: последовательноый доступ УНИВЕРСАЛЬНЕЕ, чем прямой.
Да, “спасибо” за это, я уже вдоволь “нахлебался” с ней, потому что каждый раз приходится цеплять .ToArray - без хранения последовательность эта и нафик не нужна ни в одной задаче, что я видел.
Вот очередная задачка, опубликована пару часов назад. И что мне тут последовательность дает по сравнению с массивом? Ну кроме того, что “последовательность - это круто!”
А что должен возвращать просто a.Indices по вашему?
Я уже сказал. Когда вывод поточный - преобразовать последовательность в список легко. А использовать список как последовательность это не то, потому что все элементы храняться в памяти одновременно.
То есть если возвращать последовательность - с результатом получиться работать как с последовательностью И как со списком, когда как надо. Если возвращаться список - грубо говоря, половина возможностей отпадает.
А если вы не встречали где не нужны последовательности - вы или такие задачи смотрели, или, считая последние ваши примеры где последовательности “не удобны” - не умеете использовать их возможности на максимум.
По-моему, сейчас возвращается SeqGen(a.Length, t -> t), так что это просто более короткая запись. Зачем она нужна в задачах с одномерными массивами - не знаю. Для двумерных массивов -это просто удобная нумерация элементов в кортежах, но я пользуюсь ElementsWithIndices
Опять - двадцать пять! Как у Вас в свое время было “А в С# вот так!”, теперь “в потоке”. Оставьте Вы эти свои потоки в покое! Я говорю, что универсальность - это прямой (произвольный) доступ, а Вы восхваляете последовательный. Мы не договоримся. Вы рассказываете, что из последовательности можно легко получить массив, а я говорю, что массив чаще нужен, а в отдельных редких случаях можно его в последовательность рассыпать.
Умелец Вы наш, великий гуру! Научите меня, всего такого, беспросветно темного, своим магическим приемам работы с таинственными последовательностями!
a.Indices используется в цикле
foreach var i in a.Indices do
...
Если бы он возвращал массив, это был бы кошмар
А in SeqGen(a.Length, t -> t) тут никак?
И потом, чем это лучше for var i := 0 to a.High do ?
А чем, по вашему, SeqGen лучше чем Range, который сейчас используется в Indices?
Вот реализация:
function SeqGen<T>(count: integer; f: integer->T): sequence of T;
begin
Result := Range(0, count - 1).Select(f)
end;
Я где-то писал, что он лучше? Я хотел сказать, что это практически то же, т.е. зачем-то есть два способа делать одно и то же.
Это лучше тем, что не надо вспоминать что такое a.High и не выйдет ли индекс за границу. А a.Indices - это просто цикл по всем индексам - чего ж тут непонятного?
Вот тут честно: не понял! У динамического массива индексация от 0 до a.High - как это он может выйти за границу?
a.High - это существенно менее известное свойство. Я например им не рискую пользоваться если я пытаюсь что-то объяснить
Жаркий спор о двух алгоритмах, которые решают разные задачи. Не договоритесь никогда. Например, для сортировки данных существует множество алгоритмов. Обычно используют алгоритм быстрой сортировки, но не на всех наборах данных он самый быстрый. Если не хочется заморачиваться, следует использовать универсальный алгоритм. Если хочется эффективный алгоритм, то его следует подбирать (или разрабатывать) к конкретной задаче. Для этого нужно понимать задачу, а это лень и тяжкий труд.
Скорость работы алгоритма нужно замерять после разогрева JIT. Поэтому первый замер всегда более длительный, чем последующие. И это вовсе не особенность самого алгоритма.
Высказал - и полегчало - собственное мнение. В дискуссию вступать не намерен, ибо…
1 лайк
Да, спасибо! Полностью согласен. Я например не знаю, какой способ правильнее
А ее уже и нет. Стороны высказали свои аргументы. Если продолжать настаивать и вымученно еще что-то придумывать - перерастет в ругань. Но состав участников дискуссии таков, что наезды никому из нас не нужны - не так уж тут и народу много, чтобы позволить себе еще и раздоры. Посему и затихло. В конце-концов, культура ведения дискуссий включает еще и способность почувствовать, когда пора остановиться.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021