Скажите, а как Вы собираетесь реализовывать Partition?
У нас так:
function Partition<T>(Self: sequence of T; cond: T->boolean)
: (sequence of T, sequence of T); extensionmethod;
begin
Result := (Self.Where(cond), Self.Where(x -> not cond(x)));
end;
А Вы наверное списком:
function Partition<T>(Self: sequence of T; cond: T->boolean)
: (sequence of T, sequence of T); extensionmethod;
begin
var l := Self.ToList; // Второй проход по списку не страшен - побочного эффекта не будет
Result := (l.Where(cond), l.Where(x -> not cond(x)));
end;
Я его уже почти дописал, я остановился сначала с вами решить всё. Но идея такая: когда читают из 1 коллекции - все элементы которые не подходят её записывать в список с именем temp, а когда из второй коллекции начнут читать - сначала выдать весь этот список, а потом начинать дальше идти по сорс коллекции.
(при этом temp это поле доп. класса который будет только в реализации PABCSystem, поэтому в программы он не будет попадать. Так же, через доп класс, реализованы большинство таких сложный функции из стандарта .Net )
Нет конечно, это ужасное решение. Потому что тут все элементы и обязательно придётся перенести в новый список. На самом деле в реализации всего подобного действует очень простая логика, надо думать что может понадобится в каждый момент и это и выдавать. Не знаю как полностью объяснить, но когда понял - становится очень просто.
Это только в худшем случае. Если дело будет касаться эффективности - можно считать сначала ту часть, которая скорее всего будет содержать больше элементов (по случаю это можно определить обычно).
И - в который раз говорю, дело не в эффективности, а в том что ни 1 из стандартных .Net функций не вычисляет последовательность >1 раза. И это вызовет непонятно поведение, у любого человека привыкшего к нормальную поведению функций последовательностей.
Всё же их >50 всего, а в PABCSystem таких очень мало, я вот умудрился только недавно наткнуться на них.
Не знал этого, ибо сильно удручает. Напомню, что в случае ввода последовательности с клавиатуры, двойное обращение к ней приведет к повторному запросу ввода.
begin
Writeln(ReadSeqInteger(25).Partition(t->t>0))
end.
Тут последовательность из 25 чисел придется вводить дважды. Это ужасно. Для всех подобных реализаций в Справке просто необходимо указать, что в случае использования расширений для последовательностей, вводимых с клавиатуры, данные придется перевводить. Выглядит какой-то капитуляцией перед реализацией: “извините, народ, мы пока что не смогли это сделать, как надо”.
Я уж не говорю о том, что будет, если отдать на вход последовательность от датчика случайных чисел.
Так и есть. Конвертируйте последовательность в массив для подобных применений. Последовательность не хранится в памяти - это её основное свойство. Кто этим не умеет пользоваться - плодят темы на форуме ))
Проблема-то в том, что неизвестно, для каких конвертировать, а для каких нет!
Если для любых - то зачем вообще последовательности вводить с клавиатуры или получать от датчика случайных чисел? Надо тогда просто убрать эти возможности.
С вероятностью 50 процентов либо первая либо вторая.
Ещё раз - для ваших применений сконвертируйте вашу последовательность в список сразу во внешней программе - и делайте что хотите с ней. Память всё равно будет выделяться O(n), но побочных эффектов не будет
Я же говорю, если нужна очень прямо большая оптимизация - надо по случаю делать. А по случаю мож быть и не 50/50. То есть это уже от программиста использующего это зависит.
Но это для оптимизаций. А чтоб небыло нужны догадываться или делать .ToList после каждой операции над последовательностями - надо чтоб все функции последовательностей придерживались хоть каких про правил. .Net уже дало эти правила, так что изобретать ничего не надо.
Я кстати знаю много школьных учителей, которые снижают оценку если алгоритм проходится по массиву два раза и больше. То есть, они вообще приемлют только однопроходные алгоритмы. По чему угодно, не только по последовательностям.
Так что вы не одиноки в своём стремлении и даже не настолько круты.
Обидно, что вы продолжаете считать как будто я делаю это славы или чего то типо того. Мне казалось я не раз уже доказал что мне нужно только адекватная работа данного языка.
Но пример, кстати, не в тему. Один проход по массиву всегда лучше чем несколько. Но 50 проходов по массиву лучше чем последовательности, хотя бы из за конструктора класса-наследника последовательности (который вызывается хотя бы раз для каждой функции). А для большинства функциий из .Net нужно хотя бы 2 конструктора.
В случае формирования последовательности на базе клавиатурного ввода или использования датчика случайных чисел к ней можно применять исключительно однопроходный алгоритм. Если то или иное расширение реализует многопроходный алгоритм, об этом пользователь обязан знать заранее. Иначе это просто подложенная ему бомба. Даже если у меня последовательность генерируется на основе какого-то итератора, я должен знать, не является ли алгоритм многопроходным. Это позволит мне самому решать, использовать ли последовательность или иную информационную структуру.
Такая последовательность мутируемая, а значит одноразовая. Если вы хотите сделать с ней что-то крутое, надо переводить её в массив и спокойно запускать несколько проходов.
Вообще странно, что для опытных программистов оказывается неочевидным факт, что по мутируемой последовательности второй проход даст другие результаты.
Ведь вы не сомневаетесь, что мутируемая функция Random() возвращает всякий раз разные значения и не отстаиваете то, чтобы она всегда возвращала одно и то же?
Совершенно неочевидно, что разделить последовательность на две по знаку элементов - это круто. Уже хотя бы потому, что чисто ручной алгоритм “берем очередной элемент и кидаем его либо направо, либо налево” не кажется чем-то выдающимся. Т.е. здесь как-то вот мутация этой последовательности не проглядывает. Или Вы под мутацией понимаете любую операцию, кроме фильтрации, проецирования и агрегирования?
И главное: Я ведь вовсе не веду речь о том, что разработчиков надо подвергнуть остракизму за подобную реализацию! Я выступаю за то, чтобы пользователь был всего лишь проинформирован о тех чудесах, которые могут происходить в ряде случаев. Как лучше это сделать - совсем другой вопрос.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021