Функции последовательностей из PABCSystem, реализованные повторным проходом по последовательности

Проблема-то в том, что неизвестно, для каких конвертировать, а для каких нет! Если для любых - то зачем вообще последовательности вводить с клавиатуры или получать от датчика случайных чисел? Надо тогда просто убрать эти возможности.

Вот вот и я про то. Ни для чего кроме этих 3 ваших функций не надо конвертировать. Поэтому логично ожидать что конвертирование не понадобится.

С вероятностью 50 процентов либо первая либо вторая.

Ещё раз - для ваших применений сконвертируйте вашу последовательность в список сразу во внешней программе - и делайте что хотите с ней. Память всё равно будет выделяться O(n), но побочных эффектов не будет

Я же говорю, если нужна очень прямо большая оптимизация - надо по случаю делать. А по случаю мож быть и не 50/50. То есть это уже от программиста использующего это зависит.

Но это для оптимизаций. А чтоб небыло нужны догадываться или делать .ToList после каждой операции над последовательностями - надо чтоб все функции последовательностей придерживались хоть каких про правил. .Net уже дало эти правила, так что изобретать ничего не надо.

Я кстати знаю много школьных учителей, которые снижают оценку если алгоритм проходится по массиву два раза и больше. То есть, они вообще приемлют только однопроходные алгоритмы. По чему угодно, не только по последовательностям.

Так что вы не одиноки в своём стремлении и даже не настолько круты.

Обидно, что вы продолжаете считать как будто я делаю это славы или чего то типо того. Мне казалось я не раз уже доказал что мне нужно только адекватная работа данного языка.

Но пример, кстати, не в тему. Один проход по массиву всегда лучше чем несколько. Но 50 проходов по массиву лучше чем последовательности, хотя бы из за конструктора класса-наследника последовательности (который вызывается хотя бы раз для каждой функции). А для большинства функциий из .Net нужно хотя бы 2 конструктора.

Кстати, вы правы вот в чём.

В справке необходимо написать, что некоторые функции последовательностей будут неверно работать с мутируемыми последовательностями. Здесь я согласен.

В случае формирования последовательности на базе клавиатурного ввода или использования датчика случайных чисел к ней можно применять исключительно однопроходный алгоритм. Если то или иное расширение реализует многопроходный алгоритм, об этом пользователь обязан знать заранее. Иначе это просто подложенная ему бомба. Даже если у меня последовательность генерируется на основе какого-то итератора, я должен знать, не является ли алгоритм многопроходным. Это позволит мне самому решать, использовать ли последовательность или иную информационную структуру.

Неужели? Вот задача. Найти три первых минимума.

Категорически не согласен. Один из примеров Вам уже привели.

Такая последовательность мутируемая, а значит одноразовая. Если вы хотите сделать с ней что-то крутое, надо переводить её в массив и спокойно запускать несколько проходов.

Вообще странно, что для опытных программистов оказывается неочевидным факт, что по мутируемой последовательности второй проход даст другие результаты.

Ведь вы не сомневаетесь, что мутируемая функция Random() возвращает всякий раз разные значения и не отстаиваете то, чтобы она всегда возвращала одно и то же?

Совершенно неочевидно, что разделить последовательность на две по знаку элементов - это круто. Уже хотя бы потому, что чисто ручной алгоритм “берем очередной элемент и кидаем его либо направо, либо налево” не кажется чем-то выдающимся. Т.е. здесь как-то вот мутация этой последовательности не проглядывает. Или Вы под мутацией понимаете любую операцию, кроме фильтрации, проецирования и агрегирования?

И главное: Я ведь вовсе не веду речь о том, что разработчиков надо подвергнуть остракизму за подобную реализацию! Я выступаю за то, чтобы пользователь был всего лишь проинформирован о тех чудесах, которые могут происходить в ряде случаев. Как лучше это сделать - совсем другой вопрос.

Мутируемая последовательность - это либо последовательность, которая возвращает при каждом новом использовании новый результат (как при вводе с клавиатуры), либо последовательность, которая кроме возвращения результата делает что-то ещё (как у @SunSerega - он в промежутке между возвратом значений выводит что-то в консоль)

В справке нужно прописать, что метод Partition будет неправильно работать с мутируемыми последовательностями.

Основная масса последовательностей работает как обычные функции - при повторном вызове с теми же аргументами возвращается то же самое

Только Partition не однопроходный?

Именно потому, что это абсолютно очевидно, возник вопрос о том, чтобы знать, в каких реализациях задействовано более одного прохода.

Нет, почитайте первое сообщение темы - там уже 3 в примере, мож ещё какие то есть.

Мне кажется важнее изменить описание. Справка это конечно хорошо, но ею всю в голове сразу не удержишь. Поэтому когда выбираешь из списка по точке нужный метод - надо видеть сразу оговорку, “с мутирующими последовательностями не работает, подробнее в справке” или что то типо того.

Достаточно пометить “двухпроходный”. Иначе у тех, кто пока не дока в последовательностях, возникнет вопрос про “мутации”.

1 лайк

Да, это автоматически. Справка как раз и генерируется из описаний по точке

Исправил подсказку SplitAt:

/// Разбивает последовательность на две в позиции ind. 
/// Реализуется двухпроходным алгоритмом

Так как должна выглядеть подсказка по ReadSeqInteger?

А по-моему не нужно ее трогать. Достаточно подправить подсказки по функциям и расширениям, реализующим алгоритмы, требующие более одного прохода. А то так потом надо будет править SeqRandom… и пойдет цепная реакция.

“Мы Вас предупредили, что тут начинается минное поле, но писать инструкции по его преодолению не собираемся”

Подправил. Вопрос считаю закрытым