Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я под "поменять задачу" несколько иное имел в виду. Ты вторгся в матричные операции, а фильтры такого рода — это простейшее из того, что там есть. Для обработки изображения, может, этого фильтра и хватит, а вот для чего-то большего ?
А для большего — придумаем своё решение. Linq не позицинируется как замена вообще всему.
Но ему можно найти достаточно неожиданные применения, что я и хочу продемонстрировать.
Не нужно сводить Linq к "медленному способу обработки перечислений".

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

PD>Бинаризация по Sauvola (алгоритм со скользящим окном с целью как раз уменьшить число операций)
PD>http://www.ee.oulu.fi/mvg/files/pdf/pdf_24.pdf
Сходу тяжко врубиться в 20 страниц научного текста. Как выглядит код бинаризации по Sauvola? Какая часть алгоритма является "переменной" (зависит от специфики конкретной задачи), а какая — общей?

PD>Нахождение линий по Хафу
PD>https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B5%D0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%A5%D0%B0%D1%84%D0%B0
Опять же — интересно было бы посмотреть на то, как выглядит типичный код на С++, который ищет какие-то примитивы при помощи преобразования Хафа или
PD>и кое-что еще

PD>Все это 99%, а простенький фильтр — 1%. Это тоже предложишь на LinQ переводить ? А если нет — зачем мне 1% кода переводить на LinQ ?
Нет. Я предложу писать код в максимально читаемой форме, где сказано "что", но не сказано "как".

PD>Эээ, не передергивай. Он как раз потратил время на оптимизацию, потому что в алгоритмах обработки изображений O(N^2) — это очень хорошо, а зачастую бывает существенно хуже. А ты этой оптимизацией и не занимался, да и не ясно, сможешь ли вообще ей заняться.
Я-то как раз смогу. Причём эта оптимизация пригодится не только в этой строчке этой программы, а во всех местах, где у меня вычисляется фильтр по изображению.

PD>И научить вот такому
PD>http://rsdn.org/forum/flame.comp/4098976.1

Автор: Pavel Dvorkin
Дата: 29.12.10

Нет, вот такому: https://rsdn.org/forum/dotnet/7183542.1

Автор: Sinclair
Дата: 27.06.18

PD>В целом же скажу вот что. LinQ заточен под последовательную обработку данных.
Неа. Как раз про последовательность в Linq нету совсем-совсем ничего.

PD>Ты сумел показать, что и этот фильтр можно подвести под механизм последовательной обработки, пусть понимаемой несколько расширенно. Однако когда дело дойдет до тех алгоритмов, где обработка ведется не последовательным, а более хитрым способом, ничего путного у тебя не получится
Ждём пример такого алгоритма. Как обычно — интересует алгоритм, в котором есть "переменная часть". В случае с фильтром у нас было задание ядра; в случае с СУБД — задание предиката для поиска.

PD>Это как с последовательным доступом к файлам vs. прямым доступом. Если надо писать или читать в/из поток(а) — классы последовательного доступа замечательно работают. Если же надо файл модифицировать сложным образом — применять классы последовательного доступа, наверное, все же можно , но лучше не стоит.
Вот как раз "императивный for" — это алгоритм последовательного доступа. А Linq — он весь про "дай мне результат". Что потенциально позволяет выбирать "последовательность" так, как нам это удобно.