Здравствуйте, vdimas, Вы писали:
V>Ага, байт — это тоже число.
V>Но от double уж слишком отличается. ))
И что?

V>С такими натяжками запросто, ес-но.
V>А для обобщённого блура требуется или указывать цвет "бесконечности" или продлевать крайние пиксели изображения (на выбор).
Или на лету модифицировать ядро фильтра для краёв. Дальше что?
Как раз в linq подходе я могу всё это сделать. При этом код останется читаемым.
А попытка закатить солнце при помощи ручного unsafe превратится в неподдерживаемые макароны уже при адаптации c4.

V>>>Поворот?
S>>Вот для поворота сходу не могу придумать такой записи кода, которая была бы понятнее, чем просто код поворота.
V>Но для этого кода всё-равно ведь нужен эффективный доступ к 2D-массиву, не?
Ну, я в своё время видел код поворота, написанный для win95 одним мальчиком-фанатом. Там внешний цикл менял код внутреннего цикла, чтобы сравнения указателя происходили не с регистром, а с константой.
Регистров ему там не хватало. "Эффективный доступ" к 2d-массиву — это, естественно, никакой не _data[x*w+y], а прямая манипуляция указателями. Требовать её в 2018 году от прикладного программиста — моветон.
Скорее мы отдадим ему готовый метод Rotate(double angle), а что там внутри — не его забота.

V>Далее.
V>Что там насчёт расположения строк в памяти?
V>Последовательно в памяти идут значения последнего индекса в массиве, т.е. запись array[y, x] не самая удобная, т.е. хелпер-индексер в любом случае был бы полезен, который переводил бы индексирование в более привычную нотацию array[x, y].
Это вопрос обозначений. Да, индексер штука полезная. Но при этом код linq, который я написал, работает примерно на 30% быстрее, чем код с индексером вокруг линейного массиаа.
Что вполне предсказуемо — "индексер" делает одну проверку вместо двух, жертвуя корректностью. Если его заставить бросать исключение, получив [10,-1], то его скорость сразу же упадёт до родной в дотнете.

V>Частным случаем является эффект "рыбий глаз", ищется легко.
Это который я на форуме лет 10 назад опубликовал?

V>В реальной разработке у тебя будет фактически по одной стратегии на один алгоритм.
Я не понимаю, что здесь значит "алгоритм".
Алгоритм — это "пошаговая инструкция". с4 в виде linq — это не алгоритм, это спецификация.
Алгоритм — это конкретный способ перебора ячеек. Он в данном случае скрыт от пользователя. Поэтому я свободен менять его так, как мне вздумается.

V>И разделения на "системного" и "прикладного" программиста (как ты предполагал) — не будет.
V>По крайней мере в этой реальности так не бывает. ))
Очень странно. А в том топике, откуда выросла эта идея, вовсю показывают библиотеки video++ и Eigen, показывая чёткое разделение между прикладниками и системщиками.

S>>Типа
S>>var c = from d in data.WithWrap() select d[-5,0];

V>При готовой такой "стратегии" тело цикла тоже не будет архисложным: dst[x, y] = src[x-5, y].
И здесь стратегия зашита в "индексер", то есть в данные.
А в linq подходе я навешиваю её сверху. Потому что она является частью обработки, а не данных. Для c4 делать WrapAround — противопоказано, получится булшит. А для циклического сдвига (зачем бы он нам ни был нужен) — наоборот.
Для поворота надо будет применять стратегию substitute.
Можно, конечно, пойти по пути декораторов — типа "настоящие" данные у нас внутри, в виде, скажем, того же int[height*width], а "индексеры" навешиваются поверх.
Но я не вижу никаких преимуществ от этого, по сравнению с подходом linq, кроме увеличения размера "прикладной" части кода.

V>Я знаю что он уже делает, именно с этой незамутнёности и улыбаюсь.
Тогда откуда все эти вопросы про то, что там будет с краевыми эффектами?

V>Т.е., под впечатлением некоего одного алгоритма ты объявил некую стратегию обслуживания вылета индексов за границы дефолтной.
Я просто решал ровно задачу, поставленную коллегой. Запороть каёмку был его выбор. И он был сделан явно потому, что нормальная реализация c4 фильтрации выглядит на "простом и понятном коде обхода массива" как нечитаемая и неподдерживаемая лапша. Поэтому в "императивном подходе" мы по-бырому решили пожертвовать корректностью в пользу простоты.

V>В реальной разработке сходу получил бы от коллег по шапке за такие странности.
Я всего лишь показал пример. Это же не коммерческая библиотека, которая должна покрывать 5000 сценариев. Это просто иллюстрация того, что
А) линк — это вовсе не только перечисления и списки. Вот, постарались люди максимально неподходящую задачу придумать — упс! внезапно оказалось, что и в ней у linq всё хорошо.
Б) красота линка вовсе не обязательно связана с performance penalty. Внезапно оказывается, что он ещё и быстрее "идиоматического" кода.
V>Это на форуме можно развлекаться, понятное дело, а за деньги подход чуть другой.
Естественно. За деньги бы я покрыл гораздо больше вариантов.
V>У нас всегда неравнозначное общение выходит.
Конечно. Потому что я пишу строго по делу, а в ответ — булшит, передёргивания, подмена задачи, обвинения непойми в чём.
V>И опять самому не?
Не. Зачем я буду делать вашу работу?
V>А как ты вообще работу свою работаешь?
Отлично работаю. Благодарности, премии, повышения по службе. Спасибо за интерес.
V>И как ты с коллегами технические решения обсуждаешь?
Очень просто. Для начала я стараюсь увидеть, в чём решения. А не придумать самостоятельно что-то по мотивам, недослушав и недопоняв, и тут же это критиковать.
Тот код, который я себе представил по вашему описанию, мне не нравится категорически. Но вместо того, чтобы сразу написать по результатам телепатического анализа "да говно у вас код, медленный и нечитаемый", я сдерживаюсь, в надежде, что вы вдруг напишете реально хороший и красивый код, до которого я просто не додумался.

V>>>И всё это на фоне тех моих уже сделанных замечаний, что в системе типов C# не так просто (если вовсе не невозможно) сделать "соседние" перегрузки твоему Select.
V>Ты оценку тому посту ставил, т.е. видел.
Это вот это что ли "замечания"???

Всё-таки, генерики дотнета — это не генерики в полноценном смысле этого слова, т.к. не отвечают привычным требованиям генериков, бо их ограничения не входят в сигнатуры генерик-типов и методов. Это какая-то слаботипизированная хрень по мотивам якобы генериков. Сто процентов за пару вечеров на коленке налабали.

Работать с ними страшно неудобно как в сравнении с обычными типизированными генериками, так и в сравнении с полностью нетипизированными шаблонными параметрами в плюсах.
Даже взять твои рассуждения в первом же посте этой серии — ведь хорошо же видно, что надо еще и ПРИДУМАТЬ, как раскидать абстракции и каким идентификаторам какие ответственности назначить. ПРИДУМАТЬ тут капсом, бо простого/естественного назначения ответственностей не получается из-за мгновенно возникающих конфликтов или неподдерживаемых языком конструкций. ))

Или кроме этого набора слов было что-то более конкретное?

Здравствуйте, vdimas, Вы писали:
V>Ага, байт — это тоже число.
V>Но от double уж слишком отличается. ))
И что?

V>С такими натяжками запросто, ес-но.
V>А для обобщённого блура требуется или указывать цвет "бесконечности" или продлевать крайние пиксели изображения (на выбор).
Или на лету модифицировать ядро фильтра для краёв. Дальше что?
Как раз в linq подходе я могу всё это сделать. При этом код останется читаемым.
А попытка закатить солнце при помощи ручного unsafe превратится в неподдерживаемые макароны уже при адаптации c4.

V>>>Поворот?
S>>Вот для поворота сходу не могу придумать такой записи кода, которая была бы понятнее, чем просто код поворота.
V>Но для этого кода всё-равно ведь нужен эффективный доступ к 2D-массиву, не?
Ну, я в своё время видел код поворота, написанный для win95 одним мальчиком-фанатом. Там внешний цикл менял код внутреннего цикла, чтобы сравнения указателя происходили не с регистром, а с константой.
Регистров ему там не хватало. "Эффективный доступ" к 2d-массиву — это, естественно, никакой не _data[x*w+y], а прямая манипуляция указателями. Требовать её в 2018 году от прикладного программиста — моветон.
Скорее мы отдадим ему готовый метод Rotate(double angle), а что там внутри — не его забота.

V>Далее.
V>Что там насчёт расположения строк в памяти?
V>Последовательно в памяти идут значения последнего индекса в массиве, т.е. запись array[y, x] не самая удобная, т.е. хелпер-индексер в любом случае был бы полезен, который переводил бы индексирование в более привычную нотацию array[x, y].
Это вопрос обозначений. Да, индексер штука в чём-то полезная. Но при этом код linq, который я написал, работает примерно на 30% быстрее, чем код с индексером вокруг линейного массиаа.
Что вполне предсказуемо — "индексер" делает одну проверку вместо двух, при этом жертвуя корректностью. Если его заставить бросать исключение, получив [10,-1], то его скорость сразу же упадёт до родной в дотнете.
А код linq вычислителя не делает проверок вообще. Там же то же самое, что вы писали с fixed(), только корректное, и автоматически учитывает размер переданного ядра.

V>Частным случаем является эффект "рыбий глаз", ищется легко.
Это вот это что ли? https://rsdn.org/forum/alg/191672.1

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

V>В реальной разработке у тебя будет фактически по одной стратегии на один алгоритм.
Я не понимаю, что здесь значит "алгоритм".
Алгоритм — это "пошаговая инструкция". с4 в виде linq — это не алгоритм, это спецификация.
Алгоритм — это конкретный способ перебора ячеек. Он в данном случае скрыт от пользователя. Поэтому я свободен менять его так, как мне вздумается.

V>И разделения на "системного" и "прикладного" программиста (как ты предполагал) — не будет.
V>По крайней мере в этой реальности так не бывает. ))
Очень странно. А в том топике, откуда выросла эта идея, вовсю показывают библиотеки video++ и Eigen, показывая чёткое разделение между прикладниками и системщиками.

S>>Типа
S>>var c = from d in data.WithWrap() select d[-5,0];

V>При готовой такой "стратегии" тело цикла тоже не будет архисложным: dst[x, y] = src[x-5, y].
И здесь стратегия зашита в "индексер", то есть в данные.
А в linq подходе я навешиваю её сверху. Потому что она является частью обработки, а не данных. Для c4 делать WrapAround — противопоказано, получится булшит. А для циклического сдвига (зачем бы он нам ни был нужен) — наоборот.
Для поворота надо будет применять стратегию substitute.
Можно, конечно, пойти по пути декораторов — типа "настоящие" данные у нас внутри, в виде, скажем, того же int[height*width], а "индексеры" навешиваются поверх.
Но я не вижу никаких преимуществ от этого, по сравнению с подходом linq, кроме увеличения размера "прикладной" части кода.

V>Я знаю что он уже делает, именно с этой незамутнёности и улыбаюсь.
Тогда откуда все эти вопросы про то, что там будет с краевыми эффектами?

V>Т.е., под впечатлением некоего одного алгоритма ты объявил некую стратегию обслуживания вылета индексов за границы дефолтной.
Я просто решал ровно задачу, поставленную коллегой. Запороть каёмку был его выбор. И он был сделан явно потому, что нормальная реализация c4 фильтрации выглядит на "простом и понятном коде обхода массива" как нечитаемая и неподдерживаемая лапша. Поэтому в "императивном подходе" мы по-бырому решили пожертвовать корректностью в пользу простоты.

V>В реальной разработке сходу получил бы от коллег по шапке за такие странности.
Я всего лишь показал пример. Это же не коммерческая библиотека, которая должна покрывать 5000 сценариев. Это просто иллюстрация того, что
А) линк — это вовсе не только перечисления и списки. Вот, постарались люди максимально неподходящую задачу придумать — упс! внезапно оказалось, что и в ней у linq всё хорошо.
Б) красота линка вовсе не обязательно связана с performance penalty. Внезапно оказывается, что он ещё и быстрее "идиоматического" кода.
V>Это на форуме можно развлекаться, понятное дело, а за деньги подход чуть другой.
Естественно. За деньги бы я покрыл гораздо больше вариантов.
V>У нас всегда неравнозначное общение выходит.
Конечно. Потому что я пишу строго по делу, а в ответ — булшит, передёргивания, подмена задачи, обвинения непойми в чём.
V>И опять самому не?
Не. Зачем я буду делать вашу работу?
V>А как ты вообще работу свою работаешь?
Отлично работаю. Благодарности, премии, повышения по службе. Спасибо за интерес.
V>И как ты с коллегами технические решения обсуждаешь?
Очень просто. Для начала я стараюсь увидеть, в чём решения. А не придумать самостоятельно что-то по мотивам, недослушав и недопоняв, и тут же это критиковать.
Тот код, который я себе представил по вашему описанию, мне не нравится категорически. Но вместо того, чтобы сразу написать по результатам телепатического анализа "да говно у вас код, медленный и нечитаемый", я сдерживаюсь, в надежде, что вы вдруг напишете реально хороший и красивый код, до которого я просто не додумался.

V>>>И всё это на фоне тех моих уже сделанных замечаний, что в системе типов C# не так просто (если вовсе не невозможно) сделать "соседние" перегрузки твоему Select.
V>Ты оценку тому посту ставил, т.е. видел.
Это вот это что ли "замечания"???

Всё-таки, генерики дотнета — это не генерики в полноценном смысле этого слова, т.к. не отвечают привычным требованиям генериков, бо их ограничения не входят в сигнатуры генерик-типов и методов. Это какая-то слаботипизированная хрень по мотивам якобы генериков. Сто процентов за пару вечеров на коленке налабали.

Работать с ними страшно неудобно как в сравнении с обычными типизированными генериками, так и в сравнении с полностью нетипизированными шаблонными параметрами в плюсах.
Даже взять твои рассуждения в первом же посте этой серии — ведь хорошо же видно, что надо еще и ПРИДУМАТЬ, как раскидать абстракции и каким идентификаторам какие ответственности назначить. ПРИДУМАТЬ тут капсом, бо простого/естественного назначения ответственностей не получается из-за мгновенно возникающих конфликтов или неподдерживаемых языком конструкций. ))

Или кроме этого набора слов было что-то более конкретное?