V>Да плевать конкретно на c4. V>Он приведён лишь как пример алгоритма, в котором требуется некая относительная адресация, т.е. относительно текущего элемента. V>Включи хоть раз голову, да проанализируй, что у тебя получилось: V>- реализация поверх лишь двумерного массива; V>- вероятнее всего поданное изображение будет представленно совершенно иначе; V>- как распараллелить обработку? побить в том числе вертикально? V>- сколько всего требуется аналогичных реализаций для разных представлений изображения? если всего одно уже выглядит страшно? какова цена размножения решения?
V>Я ХЗ как можно было убить на это столько времени и не выйти на простую абстракцию, примеры которых я показал, назвав их "индексерами"?
Эта абстракция мне неинтересна ровно потому, что не позволяет сократить запись прикладных алгоритмов и сделать их более понятными.
Мне интересна ровно обратная сторона — записать алгоритм так, чтобы скрыть несущественные подробности.
V>Думаешь, твоё решение читабельней? ))
А что тут думать? Я же его привёл. Там одна строчка — меньше уже некуда. Сколько строчек в вашей реализации самого эффективного c4?
V>В реальных алгоритмах обработки изображений, если по характеру алгоритма ожидаются кравевые эффекты, то они обслуживаются отдельной частью алгоритма.
Отож. V>"Лапша" тут может быть лишь от попыток свалить все части алгоритма в один цикл.
Ну вы же именно это и предложили. И даже хвастаетесь — как раз тем, что детали обработки краёв у вас в том же алгоритме.
V>Разбей алгоритм на несколько частей: V>- безопасное, максимально эффективное тело без краевых эффектов; V>- проход по краевым эффектам.
Совершенно верно. V>Это наилучший подход к таким вещам.
Ага, именно это и ожидается.
V>Мде? V>Наоборот, ты лишний раз показал, что это только перечисления и списки. V>Что при попытке делать "что-то еще", "оно" прибивается гвоздями к конкретному алгоритму, т.е. является грубой архитектурной ошибкой сразу по двум основным метрикам ПО. V>Отрасль с этим Linq подробно разобралась еще лет 10 назад.
Вы представляете прекрасный контрпример этому утверждению.
V>Ты начни туда прикручивать where, например, сделать c4 только для абсолютно чёрных точек.
И в чём проблема? Вы не понимаете, как работает where clause, или что? V>Или сделай из изображения последовательность центральных точек по Вороному. V>Помнишь я говорил тебе о конфликте сигнатур? V>Похоже ты так и не понял этого замечания. ))
Не, не понял. Какая сигнатура и с чем будет конфликтовать?
V>Так вот, "заняв" целиком и полностью сигнатуру Select реализацией с активным возвратом результата, ты обрубил целый пласт алгоритмов.
Ну и кто из нас тут демонстрирует непонимание?
Я привёл маленький, короткий proof of concept. Просто потому, что для форумных обсуждений я не могу потратитьcz на написание полноценного стека с поддержкой всех девяти конструкций query comprehension.
В реальной промышленной библиотеке конечно же будет возвращаться не T[,], а promise, который будет резолвиться либо явно через .ToArray() либо неявно через вызов [,].
Конечно же будет строиться вся цепочка операций.
S>>Б) красота линка вовсе не обязательно связана с performance penalty. Внезапно оказывается, что он ещё и быстрее "идиоматического" кода.
V>Это ложь. Он не быстрее.
Бенчмарки утверждают обратное. V>Что помешало тебе применить все свои трюки к "идиоматическому" коду, чтобы сравнение вышло спортивным?
То, что код с unsafe и манипуляциями указателями не является "идиоматическим".
Естественно, я эти трюки применил первым же делом — я же сначала написал идеальную версию на С#, и уже потом подсмотрел, какой MSIL надо сгенерировать.
Моя задача была дать возможность эти трюки использовать повторно.
В вашем подходе код c4 — это двадцать строк; код с8 — ещё 20 строк; код циклического сдвига — ещё 15.
А в моём каждый из них — это одна строка. Не надо каждый раз считать единички, проверять, куда там сползают указатели, и прочее. Гарантии корректности без потери производительности.
V>Без конфликтов сигнатур?
Ага V>Ты первый раз, что ле, глубоко копаешь Линк? ))
Ага. V>Ну, поупражняйся еще.
Отож. V>Для прочистки сознания, такскаать. V>В ответ справедливые технические замечания, на которые у тебя истерика.
Технических замечаний нет. Ну не считать же таким, в самом деле, комментарий про использование T[,]. При том, что Array2d всё равно, какой там внутри массив — переписывание на struct FastArray по мотивам вашего индексера заняло 15 минут и не дало никакой (естественно) разницы. Потому что от обоих нужен только &[0,0], а дальше вжух. V>Подмена задачи случилась у тебя. V>А я лишь вытащил на свет божий всё это грязное бельё с подменой задачи. ))
Простите, коллега, но вы разговариваете с голосами в своей голове. Я задачу как сформулировал, так и решил.
V>Это ведь ты подменил эксперимент по оценке скорости работы линка на эксперимент по ускорению доступа к двумерному массиву.
Ну конечно же нет. Задача стояла ровно наоборот — исследовать возможность использования linq для 2d-фильтрации, и возможности не просадить при этом производительность.
Это вы с чего-то решили, что главное — это написать оптимальный код, пусть даже и ценой потери читаемости и всего остального.
V>На простую просьбу "а давай-ка посмотрим на суть решение, т.е. развернём упаковку" — паника, переходы на личности и прочий мусор.
Опять разговор с голосами. V>Что тебе не понятно во фразе "ограничения генериков не входят в сигнатуры генерик-типов и методов"?
Непонятно, почему вы решили, что это помешает в рассматриваемой задаче. Пока что у меня всё получается V>Если придуряешься, то можешь считать себя клоуном.
V>Если действительно не понял, то трус и форумный хамло, который вместо простого "я тут недопонял" маскирует своё непонимание через нападки, нимало не смущаясь тем, что увеличивает градус нервозности. Со стороны не пробовал на такие закидоны смотреть? ))
Вот, коллега, вот это — переходы на личности. Я свой сарказм проявляю по отношению к вашим аргументам, а не к вашим личным достоинствам или недостаткам.
Давайте мы в следующий раз всё-таки выпишем вам бан дней на 120, ок?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[38]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Ikemefula, Вы писали:
V>>Прямой доступ к OLEDB. I> Как это повлияет на сеть между приложением и сервером DB ? А на дисковую производительность сервера DB ?
Ясно ))
Re[39]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Danchik, Вы писали:
V>>Прямой доступ к OLEDB.
D>Есть сравнения скорости по разным типам данных, объемах? Не 10 летней давности. D>Ну и к какому серверу конектимся.
А что, sql на сервере, дисковое чтение и передача данных как то по другому начнут выполняться ?
Re[40]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали:
V>>>Прямой доступ к OLEDB. I>> Как это повлияет на сеть между приложением и сервером DB ? А на дисковую производительность сервера DB ?
V>Ясно ))
Можно все-таки раскрыть преимущества? С учетом того что при работе с базой данных основное время занимает именно работа самого серверва БД при его обработке запросов.
Re[39]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Sinclair, Вы писали:
V>>Я ХЗ как можно было убить на это столько времени и не выйти на простую абстракцию, примеры которых я показал, назвав их "индексерами"? S> S>Эта абстракция мне неинтересна ровно потому, что не позволяет сократить запись прикладных алгоритмов и сделать их более понятными.
Ты спрятал важную подробность алгоритма.
Причём, за нечитаемым кодом.
S>Мне интересна ровно обратная сторона — записать алгоритм так, чтобы скрыть несущественные подробности.
Т.е., ты, таки, прямым текстом расписываешься в собственной необъективности? ))
ОК, так и запишем: разрабатывать эффективные хелперы для обхода двумерных массивов Синклер согласен только для Linq и ни боже упаси для чего-то "другого".
V>>Думаешь, твоё решение читабельней? )) S>А что тут думать? Я же его привёл.
Нечитабельно.
S>Там одна строчка — меньше уже некуда.
Одна строчка описывает только часть алгоритма, а не целиком его.
Целиком вышло кошмарно.
S>Сколько строчек в вашей реализации самого эффективного c4?
Полностью если? Намного меньше, чем в твоём полном решении.
Мои строчки читабельные и поддерживаемые.
Твои — категорически нет.
V>>"Лапша" тут может быть лишь от попыток свалить все части алгоритма в один цикл. S>Ну вы же именно это и предложили.
И опять соврал.
Я пока не предлагал ничего, кроме как сделать сравнение честным, т.е. если уж оптимизируется доступ к двумерному массиву, то пусть он оптимизируется для ВСЕХ сравниваемых техник.
S>И даже хвастаетесь — как раз тем, что детали обработки краёв у вас в том же алгоритме.
Но не в том же цикле.
Я ХЗ как можно оставлять процитированное мною, при этом приписывая мне ровно противоположное тому, что я говорил.
Выглядит так, что ты опять и снова запаниковал, бо тут уже запахло сравнением реализации ПОЛНОГО алгоритма, а не упрощенного.
Т.е. когда требуется обработать краевые эффекты согласно некоторому параметру (через заданный цвет бесконечности или через расширение картинки за счёт крайних пикселей).
V>>Разбей алгоритм на несколько частей: V>>- безопасное, максимально эффективное тело без краевых эффектов; V>>- проход по краевым эффектам. S>Совершенно верно.
Ну и где у тебя ограничение прохода лишь по безопасной области массива?
Где и как это выражено?
Ткни пальцем в участок своего кода, если я что-то упустил.
V>>Отрасль с этим Linq подробно разобралась еще лет 10 назад. S>Вы представляете прекрасный контрпример этому утверждению.
Мы?
Ты пока показал, что и близко Linq еще не нюхал, бо даже не понимаешь, о каких граблях тебе говорят. ))
V>>Ты начни туда прикручивать where, например, сделать c4 только для абсолютно чёрных точек. S>И в чём проблема? Вы не понимаете, как работает where clause, или что?
Я понимаю как работает перегрузка методов-расширений, поэтому и предлагаю, таки, окунуться чуть поближе, а потом уже делать выводы.
V>>Или сделай из изображения последовательность центральных точек по Вороному. V>>Помнишь я говорил тебе о конфликте сигнатур? V>>Похоже ты так и не понял этого замечания. )) S>Не, не понял. Какая сигнатура и с чем будет конфликтовать?
Ну так ты начни делать и увидишь.
А я рядом пример уже приводил.
Просто пока у тебя в сигнатурах не появилось Select<T, TResult, TCollection>(this TCollection, ...) where TCollection : ISomeInterface<T> — никакой проблемы нет, разумеется.
Обойти это можно только через ConcreteCollection2<TResult> Select<T, TResult>(this ConcreteCollection1<T>, ...), где ConcreteCollection1 — эдакие value-type обертки-маркеры. Но начав покрывать сценарии из обсуждаемой предметной области ты быстро обнаружишь резкий рост комбинаторики на ровном месте. В "стандартном" линке типы стираются через боксинг, но мы-то хотим его избежать, верно?
Кароч, пока сам не попробуешь, так и будешь не понимать о чём речь.
V>>Так вот, "заняв" целиком и полностью сигнатуру Select реализацией с активным возвратом результата, ты обрубил целый пласт алгоритмов. S>Ну и кто из нас тут демонстрирует непонимание?
Ты, разумеется.
S>Я привёл маленький, короткий proof of concept.
А тебе отвечают люди, которые их делали в количестве за все эти годы.
Просто делятся опытом — с чем пришлось столкнуться и почему так.
И заодно объясняют — почему ты не столкнулся.
Из-за размерности твоего примера.
S>Просто потому, что для форумных обсуждений я не могу потратитьcz на написание полноценного стека с поддержкой всех девяти конструкций query comprehension.
Без боксинга если, то вовсе не 9-ти.
Может я и не прав, что сразу не раскрыл эту часть своих возражений, но до прошлого сообщения я не представлял, насколько ты не в курсе вопроса.
Наивно считал, что простого напоминания о граблях будет достаточно.
S>В реальной промышленной библиотеке конечно же будет возвращаться не T[,], а promise, который будет резолвиться либо явно через .ToArray() либо неявно через вызов [,]. S>Конечно же будет строиться вся цепочка операций.
Ага.
Только у value-типов никаким образом не стираются типы.
S>>>Б) красота линка вовсе не обязательно связана с performance penalty. Внезапно оказывается, что он ещё и быстрее "идиоматического" кода. V>>Это ложь. Он не быстрее. S>Бенчмарки утверждают обратное.
Бенчмарки левые, измеряют шумовые эффекты, а не эффективность линка.
Поставь бенчмарки в одинаковые условия, исключи наведённые помехи и измерь снова.
А до тех пор будешь носить клеймо необъективного человека.
V>>Что помешало тебе применить все свои трюки к "идиоматическому" коду, чтобы сравнение вышло спортивным? S>То, что код с unsafe и манипуляциями указателями не является "идиоматическим".
Сейчас уже можно без unsafe:
[StructLayout(LayoutKind.Sequential, Pack =1)]
public struct Rgb24 {
public byte R;
public byte G;
public byte B;
public Rgb24(byte r, byte g, byte b) {
R = r;
G = g;
B = b;
}
}
class Program {
static void Main(string[] args) {
Rgb24[,] image = {
{ new Rgb24(1, 2, 3), new Rgb24(4, 5, 6) },
{ new Rgb24(7, 8, 9), new Rgb24(10, 11, 12) }
};
var bytes = MemoryMarshal.AsBytes(MemoryMarshal.CreateReadOnlySpan(ref image[0, 0], image.Length));
foreach(byte b in bytes)
Console.WriteLine(b);
}
}
Пока оно немного уступает unsafe по эффективности, но обещается, что будет то же самое.
S>Естественно, я эти трюки применил первым же делом — я же сначала написал идеальную версию на С#, и уже потом подсмотрел, какой MSIL надо сгенерировать. S>Моя задача была дать возможность эти трюки использовать повторно. S>В вашем подходе код c4 — это двадцать строк; код с8 — ещё 20 строк; код циклического сдвига — ещё 15. S>А в моём каждый из них — это одна строка.
В показанном тобой коде это не так.
S>Не надо каждый раз считать единички, проверять, куда там сползают указатели, и прочее. Гарантии корректности без потери производительности.
Дык, ты как раз пренебрег гарантиями корректности. ))
Похоже, ты в "гарантии" отнёс только защиту от выхода за границы массива, но пренебрег корректностью алгоритма.
Но в этом случае твоё решение решением НЕ является.
V>>Без конфликтов сигнатур? S>Ага
Так ты приступи уже, потом приходи, поговорим.
V>>В ответ справедливые технические замечания, на которые у тебя истерика. S>Технических замечаний нет. Ну не считать же таким, в самом деле, комментарий про использование T[,]. При том, что Array2d всё равно, какой там внутри массив — переписывание на struct FastArray по мотивам вашего индексера заняло 15 минут и не дало никакой (естественно) разницы.
Пипец.
Разница не у тебя должна была появиться, а у "идиоматического" кода.
V>>Подмена задачи случилась у тебя. V>>А я лишь вытащил на свет божий всё это грязное бельё с подменой задачи. )) S>Простите, коллега, но вы разговариваете с голосами в своей голове. Я задачу как сформулировал, так и решил.
1. Пока что ты её не решил целиком.
2. В твоей формулировке не утверждалось, что идиоматический код не может пользоваться хелперами.
Хотя в реальных алгоритмах обработки изображений (на тех же плюсах) весь "идиматический" код (т.е. написанный в виде явного итерирования) — он всегда работает поверх неких аналогов показанных мною "индексеров". Потому что по-другому в этой предметной области никак, бо форматов/кодировок даже RAW-изображений слишком много.
Не веришь — спроси у Вольфхаунда, он одно время, вроде бы, занимался такими вещами плотно. ))
V>>Это ведь ты подменил эксперимент по оценке скорости работы линка на эксперимент по ускорению доступа к двумерному массиву. S>Ну конечно же нет. Задача стояла ровно наоборот — исследовать возможность использования linq для 2d-фильтрации, и возможности не просадить при этом производительность.
В показанном тобой виде возможность отсутствует как класс. Задача не решена. Итоговые пиксели подсчитаны неверно.
Т.е., я пока не увидел в твоём коде ничего помимо трюка с ускорением обхода массива.
Поэтому, я как честный человек, могу обсуждать лишь ту часть задачи, которую тебе удалось решить на данный момент.
Всё остальное от тебя — это лишь обещания "прекрасного будущего", какие мы слышали от тебя же еще с 2003-2004-х годов. ))
Просто мне есть чем возразить — никакого прекрасного будущего там не будет.
Проблематику дизайна линка я подробно расковырял еще хрен его знает когда.
Потому что злоупотребляю value-типами в своих разработках на донете.
Когда/если ты попытаешься окучить всю комбинаторику сценариев, пытаясь при этом избежать боксинга — ты сам всё увидишь.
Пока же тебе удалось (впервые в жизни, судя по уровню радости) написать метод-расширение под линк и тебя банально понесло, ты забыл быть объективным.
V>>Что тебе не понятно во фразе "ограничения генериков не входят в сигнатуры генерик-типов и методов"? S>Непонятно, почему вы решили, что это помешает в рассматриваемой задаче. Пока что у меня всё получается
Потому что ты подаешь на вход абстрактный ref-тип, которым является массив.
А даже если пробовал Array2d, то максимум в одном сценарии, т.е. еще не нарвался на каскадные Select.
V>>Если придуряешься, то можешь считать себя клоуном. S> V>Если действительно не понял, то трус и форумный хамло, который вместо простого "я тут недопонял" маскирует своё непонимание через нападки, нимало не смущаясь тем, что увеличивает градус нервозности. Со стороны не пробовал на такие закидоны смотреть? )) S>Вот, коллега, вот это — переходы на личности. Я свой сарказм проявляю по отношению к вашим аргументам, а не к вашим личным достоинствам или недостаткам.
Жалкая отмазка, однако.
Тут всё-таки взрослые дяди, т.е. без подсказок вкурсе сотен способов сообщить человеку, что он дурак каким-нить "косвенным" образом, навроде "так рассуждают только дураки".
Кароч, детсад, первая четверть.
И при этом твой фирменный стиль.
Который рано или поздно задалбывает, ес-но.
S>Давайте мы в следующий раз всё-таки выпишем вам бан дней на 120, ок?
Давай ты в следующий раз не будешь поднимать градус нервозности по собственной инициативе.
Бери пример с меня — я принципиально отвечаю в подобном ключе только в ответ.
И то, первые пару раз почти всегда игнорю — даю возможность "одуматься".
Неплоха стратегия, рекомендую.
Некому начинать — некому продолжать, очевидно ж.
Здравствуйте, vdimas, Вы писали:
V>Давай ты в следующий раз не будешь поднимать градус нервозности по собственной инициативе. V>Бери пример с меня — я принципиально отвечаю в подобном ключе только в ответ.
У тебя 96 нарушений, из них половина — за хамство. У Синклера — всего одно нарушение за всё время.
Если же взять только этот топик, то берем первую страницу сообщений:
Сие было общеизвестно еще аж с 2002-го года, как ты умудрился проспать?
"Трюкач", блин...
Собственно, уже хамство. " я принципиально отвечаю в подобном ключе только в ответ"
Re[41]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Vasiliy2, Вы писали:
V>>>>Прямой доступ к OLEDB. I>>> Как это повлияет на сеть между приложением и сервером DB ? А на дисковую производительность сервера DB ?
V>>Ясно ))
V>Можно все-таки раскрыть преимущества? С учетом того что при работе с базой данных основное время занимает именно работа самого серверва БД при его обработке запросов.
Сиплюсники очень тщательно считают микросекунды и даже такты процессора Им просто не сказали, что в сервере БД тоже есть процессор
Re[41]: 2D-Linq и оптимизация цифровых фильтров - 3
V>С учетом того что при работе с базой данных основное время занимает именно работа самого серверва БД при его обработке запросов.
Этот "учёт" сильно зависит от.
Например, сервак может начать отдавать данные весьма оперативно.
Т.е. еще выборку не закончил, а первые данные тебе уже идут.
Для локальных in-proc баз это вообще чуть ли не закон.
Ну и, быстродействие разных баз (время отклика) тоже сильно разное, т.е. полагаться на то, что "база всё-равно долго отдупляется", не стоит.
Re[41]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали: V>Ты спрятал важную подробность алгоритма. V>Причём, за нечитаемым кодом.
В промышленной библиотеке эта подробность была бы документирована.
S>>Мне интересна ровно обратная сторона — записать алгоритм так, чтобы скрыть несущественные подробности. V>ОК, так и запишем: разрабатывать эффективные хелперы для обхода двумерных массивов Синклер согласен только для Linq и ни боже упаси для чего-то "другого".
Я постараюсь объяснить в четвёртый раз: я вообще не пытаюсь разработать "эффективные хелперы". Я пытаюсь разделить "полный алгоритм" на ту часть, которая "обходит" массив, и ту часть, которая определяет ядро фильтра.
V>Нечитабельно.
Как улучшить читаемость?
V>Одна строчка описывает только часть алгоритма, а не целиком его.
Потому что именно эта часть является "переменной". А стратегия обхода будет более-менее одна для широкого класса фильтров.
V>Полностью если? Намного меньше, чем в твоём полном решении.
Это нечестное сравнение. Давайте тогда включим в оценку размера кода from a in {1, 2, 3} where a % 2 == 0 select a весь Enumerable.cs.
Ключевая идея — в том, что код linq-провайдера можно использовать повторно.
А из вашего кода с4 сделать с8 можно только копи-пейстом и никак иначе.
Если у вас есть какая-то идея, как суметь избежать выписывания вложенных fixed для каждого конкретного ядра — велком, рассказывайте.
V>Твои — категорически нет.
А по-моему — наоборот.
V>>>"Лапша" тут может быть лишь от попыток свалить все части алгоритма в один цикл. S>>Ну вы же именно это и предложили.
V>Я пока не предлагал ничего, кроме как сделать сравнение честным, т.е. если уж оптимизируется доступ к двумерному массиву, то пусть он оптимизируется для ВСЕХ сравниваемых техник.
Я основываюсь на тех примерах кода, которые вы написали. Вот, цитируем:
unsafe void FourNeighborAverage(T array) where T : struct, IArray2d<int>
{
int dx = array.DX;
for(int y = 1, dy = array.DY - 1; y < dy; y++) {
fixed(int* current = array[1, y])
fixed(int* end = array[dx, y])
fixed(int* it1 = array[0, y])
fixed(int* it2 = array[2, y])
fixed(int* it3 = array[1, y - 1])
fixed(int* it4 = array[1, y + 1]) {
int* c = current, _1 = it1, _2 = it2, _3 = it3, _4 = it4;
while(c < end)
*c++ = *_1++ + *_2++ + *_3++ + *_4++;
}
}
}
Здесь — всё вместе:
— описание ядра фильтра: строчки 6-9 и 12
— учёт границ (который нужно обновлять при каждой смене ядра): строчки 3,4,5
— собственно алгоритм обхода — строчки 3 и 11. V>Но не в том же цикле.
А в каком? Вот же он код. Там нет никаких других отдельных циклов. V>Я ХЗ как можно оставлять процитированное мною, при этом приписывая мне ровно противоположное тому, что я говорил.
Код говорит сам за себя.
V>Выглядит так, что ты опять и снова запаниковал, бо тут уже запахло сравнением реализации ПОЛНОГО алгоритма, а не упрощенного. V>Т.е. когда требуется обработать краевые эффекты согласно некоторому параметру (через заданный цвет бесконечности или через расширение картинки за счёт крайних пикселей).
Ну, давайте расширим требования. Покажите мне, как легко изменить ваш алгоритм на случай, например, заданного цвета бесконечности.
V>Ну и где у тебя ограничение прохода лишь по безопасной области массива? V>Где и как это выражено? V>Ткни пальцем в участок своего кода, если я что-то упустил.
Сейчас оно захардкожено в генераторе MSIL:
И в тех местах, где EmitFor().
V>>>Ты начни туда прикручивать where, например, сделать c4 только для абсолютно чёрных точек. S>>И в чём проблема? Вы не понимаете, как работает where clause, или что?
V>Я понимаю как работает перегрузка методов-расширений, поэтому и предлагаю, таки, окунуться чуть поближе, а потом уже делать выводы.
Ну, если вы настаиваете, то вот как выглядит решение задачи "если пиксел — чёрный, то заменить его средним от соседей, а если нет — то скопировать":
var filtered = from d in data select d[0,0] != 0 ? d[0,0]: (d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]) / 4;
Пока что нет никаких проблем с сигнатурами. Как, впрочем, и с where, который тут не нужен.
V>А я рядом пример уже приводил.
Пример чего? V>Просто пока у тебя в сигнатурах не появилось Select<T, TResult, TCollection>(this TCollection, ...) where TCollection : ISomeInterface<T> — никакой проблемы нет, разумеется.
А зачем мне это? Просто берём this IArray2d<T> и всё.
V>Обойти это можно только через ConcreteCollection2<TResult> Select<T, TResult>(this ConcreteCollection1<T>, ...), где ConcreteCollection1 — эдакие value-type обертки-маркеры. Но начав покрывать сценарии из обсуждаемой предметной области ты быстро обнаружишь резкий рост комбинаторики на ровном месте. В "стандартном" линке типы стираются через боксинг, но мы-то хотим его избежать, верно?
Мы избегаем боксинга другим способом, поэтому нет нужды ни в value-типах для обёртывания, ни в сложных where.
V>Без боксинга если, то вовсе не 9-ти.
V>Наивно считал, что простого напоминания о граблях будет достаточно.
"Напоминания о граблях" и прочие туманные намёки на толстые обстоятельства неинтересны.
S>>В реальной промышленной библиотеке конечно же будет возвращаться не T[,], а promise, который будет резолвиться либо явно через .ToArray() либо неявно через вызов [,]. S>>Конечно же будет строиться вся цепочка операций.
V>Ага. V>Только у value-типов никаким образом не стираются типы.
Ну и что.
V>А до тех пор будешь носить клеймо необъективного человека.
Последний шанс даю. Ещё слово про "носить клеймо" или ещё какие характеристики личности — и я продолжу дискуссию с более вменяемыми оппонентами.
V>Сейчас уже можно без unsafe: V>
V> [StructLayout(LayoutKind.Sequential, Pack =1)]
V> public struct Rgb24 {
V> public byte R;
V> public byte G;
V> public byte B;
V> public Rgb24(byte r, byte g, byte b) {
V> R = r;
V> G = g;
V> B = b;
V> }
V> }
V> class Program {
V> static void Main(string[] args) {
V> Rgb24[,] image = {
V> { new Rgb24(1, 2, 3), new Rgb24(4, 5, 6) },
V> { new Rgb24(7, 8, 9), new Rgb24(10, 11, 12) }
V> };
V> var bytes = MemoryMarshal.AsBytes(MemoryMarshal.CreateReadOnlySpan(ref image[0, 0], image.Length));
V> foreach(byte b in bytes)
V> Console.WriteLine(b);
V> }
V> }
V>
V>Пока оно немного уступает unsafe по эффективности, но обещается, что будет то же самое.
Прекрасно. Осталось посмотреть, как будет выглядеть тот же c4 с примененем этого подхода. Я к тому, что чудес-то не бывает, и возможность реинтерпретации памяти не сделает наш код красивее.
V>В показанном тобой коде это не так.
Почему?
S>Похоже, ты в "гарантии" отнёс только защиту от выхода за границы массива, но пренебрег корректностью алгоритма.
Я брал конкретный алгоритм от alex_public. Потому что не хотел подменять задачу — если мы начнём беспокоиться о корректности, то for for вообще превратится в макароны.
V>Разница не у тебя должна была появиться, а у "идиоматического" кода.
Код с обходом массива — 1х. Код с обходом "индексера" — 0.7х. Код linq — 0.5х. Код с unsafe обходом массива или индексера — 0.49х. .
V>2. В твоей формулировке не утверждалось, что идиоматический код не может пользоваться хелперами.
Да пусть пользуется, мне что, жалко что ли. V>Хотя в реальных алгоритмах обработки изображений (на тех же плюсах) весь "идиматический" код (т.е. написанный в виде явного итерирования) — он всегда работает поверх неких аналогов показанных мною "индексеров". Потому что по-другому в этой предметной области никак, бо форматов/кодировок даже RAW-изображений слишком много.
С форматами и кодировками С# не очень хорошо. Я сходу не могу придумать удачного способа написать повторно используемый код усреднения для пикселов, скажем, Rgb16.
Ну, то есть понятно, что можно попробовать сделать что-то типа
public struct Rgb565 : IPixel
{
private ushort raw;
public int R
{
get => (raw & 0xF800) >> 11;
set => raw = (ushort)((raw & ~0xF800) | (value << 11) & 0xF800);
}
public int G
{
get => (raw & 0x07E0) >> 6;
set => raw = (ushort)((raw & ~0x07E0) | (value << 6) & 0x07E0);
}
public int B
{
get => (raw & 0x001F) ;
set => raw = (ushort)((raw & ~0x001F) | (value & ~0x001F));
}
}
Но есть у меня сомнения в том, что джит породит приемлемый код, даже если сделать
public P Avg<P>(P p1, P p2) where P:unmanaged, IPixel
{
return new P{
R = (p1.R+p2.R)/2
G = (p1.G+p2.G)/2
B = (p1.B+p2.B)/2
}
}
V>В показанном тобой виде возможность отсутствует как класс. Задача не решена. Итоговые пиксели подсчитаны неверно.
Строго так же, как в оригинальном решении от alex_public. V>Т.е., я пока не увидел в твоём коде ничего помимо трюка с ускорением обхода массива.
Основной "трюк" — это инлайнинг делегата, с попутной заменой относительных обращений на абсолютные. Всё остальное — рутина, которая малоинтересна.
V>Пока же тебе удалось (впервые в жизни, судя по уровню радости) написать метод-расширение под линк и тебя банально понесло, ты забыл быть объективным.
Мне удалось написать метод-расширение для чего-то необычного. Отсюда и радость.
V>Потому что ты подаешь на вход абстрактный ref-тип, которым является массив. V>А даже если пробовал Array2d, то максимум в одном сценарии, т.е. еще не нарвался на каскадные Select.
А мне вполне достаточно абстрактного реф-типа, например IArray2d<T>.
Потому что внутри я вообще не пользуюсь обращениями к [,].
Каскадные селекты работают тем же способом — в первом приближении.
То есть у нас получается цепочка вызовов монолитных методов с порождением промежуточных массивов.
Дальнейшее развитие может "склеивать" такие цепочки — чтобы в финале был один проход по исходному массиву с генерацией сразу окончательного результата, безо всякой промежуточности.
Вот как раз этим я сейчас и занимаюсь, на примере бинаризации по Sauvola, предложенной Павлом.
Код пока находится в раздолбанном состоянии, потому и не выкладываю.
V>Давай ты в следующий раз не будешь поднимать градус нервозности по собственной инициативе. V>Бери пример с меня — я принципиально отвечаю в подобном ключе только в ответ.
Поднятие градуса нервозности — это вбежать в топик, и сходу, не разобравшись, начать хамить и оскорблять оппонента. Вот, например, как здесь.
Я просто не каждый раз вам указываю на эти некорректности. В основном — потому, что остальным читателям интересны технические вопросы, а не вопросы вашего воспитания.
Так что оферта с баном остаётся открытой. sapienti sat.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали:
V>Его, его. )) V>У двумерного массива для доступа к элементу вызываются специальные методы класса-массива. V>А в случае одномерного массива компилятор подставляет тупо опкоды со смещением по индексу.
Спешу вас обрадовать. Специальные методы устраняются джитом, точно так же, как и для одномерных массивов. V>Вот Синклер и подменил одно на другое (в числе прочего). V>Эта фишка известна еще с забытых 2003-х годов.
Она устарела. Всё, чем плох [,] — это неустранимыми проверками диапазона.
Если озаботиться корректностью своего "индексера", то его быстродействие на единичных операциях будет гарантированно хуже, чем у честного массива — потому что родной массив будет делать 2 проверки, а индексер — 3.
А если мы перелезаем через забор и пользуемся fixed в bulk-операциях, то разницы нет, т.к. сравнивать будем 0 проверок и 0 проверок.
То же самое касается применению Span<T> — он примерно одинаково извлекатся из массива любой размерности, и из LockBitmap.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>>>В ответ справедливые технические замечания, на которые у тебя истерика.
V>>>Если придуряешься, то можешь считать себя клоуном. S>> V>Если действительно не понял, то трус и форумный хамло, который вместо простого "я тут недопонял" маскирует своё непонимание через нападки, нимало не смущаясь тем, что увеличивает градус нервозности. Со стороны не пробовал на такие закидоны смотреть? ))
V>Жалкая отмазка, однако. V>Тут всё-таки взрослые дяди, т.е. без подсказок вкурсе сотен способов сообщить человеку, что он дурак каким-нить "косвенным" образом, навроде "так рассуждают только дураки". V>Кароч, детсад, первая четверть. V>И при этом твой фирменный стиль. :down: V>Который рано или поздно задалбывает, ес-но.
S>>Давайте мы в следующий раз всё-таки выпишем вам бан дней на 120, ок?
V>Давай ты в следующий раз не будешь поднимать градус нервозности по собственной инициативе. V>Бери пример с меня — я принципиально отвечаю в подобном ключе только в ответ. V>И то, первые пару раз почти всегда игнорю — даю возможность "одуматься". V>Неплоха стратегия, рекомендую. V>Некому начинать — некому продолжать, очевидно ж.
Это совсем ни в какие ворота.
vdimas, ты токсичный человек, с которым неприятно иметь дело. До твоего прихода в этих трёх постах (и некоторых других ранее) царила доброжелательная расслабленная атмосфера. Но ты всё руинишь, просто отравляешь среду своим хамством, снисходительностью и чванливостью.
И при этом хватает наглости обвинять окружающих в каком-то не таком тоне и инициировании нервозности.
V>Со стороны не пробовал на такие закидоны смотреть? )) V>Который рано или поздно задалбывает, ес-но.
На RSDN есть возможность добавлять токсичных юзернеймов в игнор-листы?
Здравствуйте, Qbit86, Вы писали:
Q>До твоего прихода в этих трёх постах (и некоторых других ранее) царила доброжелательная расслабленная атмосфера.
Я же говорю — Синклер сбежал в зону комфорта. ))
Q>Но ты всё руинишь
Ага, указываю на ошибки.
Раздражаю.
А надо было играть в поддавки, тогда все были бы счастливы.
Не находишь странным, что такие "обычаи" сложились на этом сайте исключительно вокруг дотнетной тусовки?
Q>просто отравляешь среду своим хамством, снисходительностью и чванливостью.
Мде?
Ты пройдись по ссылке в исходный топик и почтай там Синклера, кто действительно отравляет любое обсуждение хамством и чванливостью.
Q>И при этом хватает наглости обвинять окружающих в каком-то не таком тоне и инициировании нервозности.
Я знаю, кого я обвиняю. Обвинения были адресные, если заметил.
Синклер — один из самых токсичных собеседников на этом сайте.
К тому же, склонен к манипуляциям, выыворачиванием слов оппонентов и просто к глумлению, не связанному вообще ни с чем — ни с темой обсуждения, ни с аргументами оппонента.
В ответ время от времени получает по заслугам.
То, что конкретно в этом топике, до тех пор, пока ему не возражали, он "держал марку" — не меняет ровным счётом ничего — этот топик является продолжением другого, где он показал себя многократно во всей красе.
Так шта, угомонись уже, мистер защитник. ))
Демонстрируемая тобой "корпоративная солидарность" — самая вредительская весчь в технических спорах, бо работает строго против объективности.
Re[41]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Sinclair, Вы писали:
S>Я пытаюсь разделить "полный алгоритм" на ту часть, которая "обходит" массив, и ту часть, которая определяет ядро фильтра.
Ладно, это уже упоротость, как она есть.
Я всё-равно никогда не поверю, что ты не понял аргумента насчёт привязки подробностей такого обхода к конкретным алгоритмам.
Ну конечно, ты всё понял.
Ты даже заранее знал, я более чем уверен.
Просто держишься за всю эту прорву допущений, которые сам же себе соизволил позволить.
Сорри, но в техническом плане ты глубоко несерьезный человек, увы.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Sinclair, Вы писали:
S>>Я пытаюсь разделить "полный алгоритм" на ту часть, которая "обходит" массив, и ту часть, которая определяет ядро фильтра.
V>Ладно, это уже упоротость, как она есть. V>Я всё-равно никогда не поверю, что ты не понял аргумента насчёт привязки подробностей такого обхода к конкретным алгоритмам. V>Ну конечно, ты всё понял. V>Ты даже заранее знал, я более чем уверен. V>Просто держишься за всю эту прорву допущений, которые сам же себе соизволил позволить. V>Сорри, но в техническом плане ты глубоко несерьезный человек, увы.
vdimas, я вообще не понял зачем ты сюда влез со своими алгоритмами и еще чем-то. Читаем главный топик сначала аккуратно каждое слово, и вкуриваем что хотел продемонстрировать Sinclair. Ровно одно — отделить мух от котлет не потеряв в производительности.
Вникни сначала в проблему, а потом наезжай. Твои плахты мыслей меня на этом форуме уже поддостали. Все должно быть коротко и лаконично. Читать это времени нет.
Re[43]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, Danchik, Вы писали:
D>vdimas, я вообще не понял зачем ты сюда влез со своими алгоритмами и еще чем-то.
Продемонстрировать суть мухлежа, который я заметил.
D>Читаем главный топик сначала аккуратно каждое слово
Читал внимательней тебя.
Учись читать не только "слова", но и код.
D>и вкуриваем что хотел продемонстрировать Sinclair.
Ну вот займись.
Только внимательно.
D>Ровно одно — отделить мух от котлет не потеряв в производительности.
Дык, спор от того и возник, что так и не отделил.
Моя основная претензия состоит в прибивании гвоздями конкретного алгоритма к якобы "обобщённому коду".
Т.е. выделенное в кавычках — вранье.
Разнесение запчастей одного аглоритма по разных местам программы не является "отделением мух от котлет", а строго наоборот — является грубой архитектурной ошибкой.
Вторая претензия — к попытке неспортивного сравнения разных подходов.
Тут и вовсе наблюдаю панику, отчаянное желание сделать сравнение именно не спортивным. ))
Третья претензия — к недостаточной проработанности АПИ его расширений к линку.
Но до этого момента Синклер еще не дошёл, хотя я всячески его подталкиваю опробовать его подход на более широком классе задач.
Нас же класс задач интересует, а не конкретный один алгоритм, верно?
D>Все должно быть коротко и лаконично.
В первую очередь не надо замыливать суть происходящего, не надо резать по цитатам, не надо переворачивать слова оппонента на противоположные и т.д.
Лаконично если — не надо врать.
Остальное вторично.
Re[44]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Danchik, Вы писали:
D>>vdimas, я вообще не понял зачем ты сюда влез со своими алгоритмами и еще чем-то.
V>Продемонстрировать суть мухлежа, который я заметил.
D>>Ровно одно — отделить мух от котлет не потеряв в производительности.
V>Дык, спор от того и возник, что так и не отделил. V>Моя основная претензия состоит в прибивании гвоздями конкретного алгоритма к якобы "обобщённому коду". V>Т.е. выделенное в кавычках — вранье. V>Разнесение запчастей одного аглоритма по разных местам программы не является "отделением мух от котлет", а строго наоборот — является грубой архитектурной ошибкой.
Капитан Очевидность, остановись. Эта штука не претендует на закоченность. Или тем более на библиотеку, которую ой как надо будет продумывать. Она дает точку для рзмышления. Мне, например, и в голову не пришло так использовать linq.
V>Вторая претензия — к попытке неспортивного сравнения разных подходов. V>Тут и вовсе наблюдаю панику, отчаянное желание сделать сравнение именно не спортивным. ))
Не увидел тут красной тряпки чтобы на нее бросаться. Сравнили скорость, сравнили человеко затраты на изменение параметров. Разошлись.
V>Третья претензия — к недостаточной проработанности АПИ его расширений к линку. V>Но до этого момента Синклер еще не дошёл, хотя я всячески его подталкиваю опробовать его подход на более широком классе задач. V>Нас же класс задач интересует, а не конкретный один алгоритм, верно?
Не сомневаюсь что у Sinclair есть и без того чем заняться, чем готовить полное API для библиотеки, которой не будет. До широкого подхода тут далеко. Демонстрировался конкретный агоритм, в котором параметры меняются играючись без копипасты. И да, печально что у .NET нет таких мощных темплитов как у C++. Выкрутился же, я себе запомнил как.
D>>Все должно быть коротко и лаконично.
V>В первую очередь не надо замыливать суть происходящего, не надо резать по цитатам, не надо переворачивать слова оппонента на противоположные и т.д. V>Лаконично если — не надо врать. V>Остальное вторично.
Надо начинать переставать повторять мантру «все врут».
Re[31]: 2D-Linq и оптимизация цифровых фильтров - 3
Здравствуйте, vdimas, Вы писали:
V>Да, я помню, что с тобой разве что бесполезное ля-ля-ля разводить можно.
Просто я вежливый мальчик и привык отвечать взаимностью ))
V>Ошибок было наделано масса в первом же сообщении и до сих пор никуда не делись.
Совершенно верно. В своем первом же сообщении ты наделал кучу ошибок и вместо того, чтобы их признать начал изворачиваться, менять условия задачи и переводить стрелки, а когда тебя прижали — начал хамить. Я далек от того чтобы ставить диагнозы по фотографии, но на лицо типичное поведение обиженного неудачника.
V>По-определению налажал тут тот, кто всем врёт в техническом плане и затем настойиво изворачивается.
Да! И совершенно отчетливо видно, кто именно это сделал. Ты налажал, будь мужиком, признай уже.
V>Я думаю, что помешала врожденная слабость характера.
Мне жаль тебя ) Но этот форум не лучшее место, чтобы лечить свои комплексы и самоутверждаться за счет других, так что рекомендую лечить твою слабость характера где-нибудь в другом месте.
V>Ты тоже слабак, коль не можешь признать очевидного.
Да я и не претендую, но пока что только у тебя проблемы с очевидным )
V>Так шта, упражняйся сколько хочешь.
Спасибо, я воспользуюсь )
V>Не до собеседника докопаться.
Ты именно этим и занимаешься и сам в этом признался, не отказывайся от своих слов.
V>Опять старательно уходишь от ЛЮБЫХ технических деталей, только разводишь ля-ля-ля общими словами.
Не надо проецировать свои методы на других, в зеркало посмотрись)
IB>>- ты намеренно скрываешь детали своих утверждений, чтобы потом оставалось пространство для маневра, а то как доходит до деталей, то сразу вылезают ошибки от которых сложно отмазаться. V>И конечно, тебе не трудно будет уточнить каждое из 3-х утверждений в этом предложении?
Легко, начнем с цитат "Сорри, но на конкретный алгоритм пелевать..."(с), далее:
Там было не только про рефлексию, но мне лень обсуждать с тобой разницу происходящего в случае IEnumerable vs IQueryable.
Кто в курсе, тому те слова были понятны.
А кто не в курсе, тот мается ерундой, гоняясь на форуме за словами, смысла которых не понимает.
..... Я только что обозначил куда копать.
Затем у тебя начинается истерика, как только просят конкретный код показать. А закончить можно тем, как ты налажал, когда таки попытался продемонстрировать свое решение и теперь изнурительно отмазываешься.
Жалкое зрелище, откровенно говоря.
V>Слышал я уже эти отмазки и уже отправлял тебя к твоим же словам в том топике. V>Вы обсуждали целый класс алгоритмов, а alex_public привёл лишь пример такого алгоритма.
Фууу, как занудно, даже отмазываться красиво не умеешь. Задача была сформулирована четко и не двусмысленно. Ты решил что-то другое. Ты можешь придумывать что угодно, но ты налажал, успокойся уже =)
V>Я эту задачу вообще не решал и не собирался.
Тогда зачем ты здесь вообще? Скройся уже
V>Я демонстрировал "недоговорённости" в коде Синклера.
Но едиственное что тебе удалось продемонстрировать это собственную ущербность и не способность адекватно вести дискуссию.
V>А где я предоставил готовое к тестам решение исходной задачи?
Ты предоставил достаточно, чтобы понять, что ты накосячил.
V>Чужой код нужен был для сравнения.
Для начала, для сравнения нужно решать ту же задачу и сделать это корректно. Тебе это пока не удалось.
V>Я сюда влез изначально с единственным замечанием — Синклер сравнивает не то и не с тем:
Не то и ни с тем кроме тебя здесь никто не сравнивает.
V>И тебя не смущает, что я именно это сразу же и предложил?
Ты предложил решение другой задачи, причем умудрился ошибиться и там. Выйди и зайди снова, как учили =)
V>Тем более, что ты делаешь оценочные суждения даже не от своего имени, а от имени другого коллеги. V>Это уже звоночек, однако... ))
Хорошо что ты это понимаешь, теперь научись применять это к себе =)
Как это повлияет на сеть между приложением и сервером DB ? А на дисковую производительность сервера DB ?
Мы уже победили, просто это еще не так заметно...
