Здравствуйте, Sinclair, Вы писали:

S>В нефиксированном размере ядра, из-за чего unsafe оптимизации через "ограничение каймы" являются некорректными.

Во втором же своём сообщении я про это упомянул.
Потом долго испытывал странную эмоцию из разряда "я один это вижу?" (С)


S>Ну, во-первых, давайте посмотрим на то, как выглядит этот код без линка, а с применением любого другого подхода по вашему выбору.

В коде без линка никто не мешает задавать диапазон обхода непосредственно в алгоритме:

for(y = offset1, end = array.Count - offset2; y < end; y++)
   ...

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


S>В-третьих, не вполне понятен реальный сценарий, в котором на это наступишь.

Сценарий известный — градиент размытия от центра или к центру.
Т.е. в центре самый фокус, по краям самое размытие.
Или наоборот.


S>Ну, то есть пока что все задачки, которые обсуждались на уровне кода, использовали статические ядра.

Это как раз нормально.
Ненормальной была реакция на моё предложение посмотреть на более широкий класс задач.


S>Так что есть искушение просто запретить такое при исполнении запроса — то есть обнаружив неконстантные выражения в IRelativeAccess<>.get_Item, сразу выкидывать IndexOutOfRange, не дожидаясь проблемы.

Тогда ты "займёшь" данную сигнатуру конкретной реализацией.
Впрочем, я уже повторяюсь десятикратно тут...


S>Можно сделать наоборот — продолжать применять проверки диапазонов при каждом обращении, кроме доказанно-константных случаев.

Всё можно.
Пока опять на что-то не напорешься.

Мне как раз разнесение целевого кода от "контракта" сходу и не понравилось, если уж начистоту.
Понятное дело, что запись алгоритма в пару строк — мечта любого программиста.
Но всерьёз если, то под это дело нужны специальные языки.

Под обработку звука я периодически ковыряю свой эксперимент. Но там больше графическая нотация подходит, чем текстовая.
В текстовой форме упираешься сразу в представление параметризации исходного алгоритма — оно чудовищное.
Это таблица со значениями, а лучше эдакий "девайс" с большим окл-вом крутилок.
И чтобы впрямо в реалтайме эти крутилки крутить, т.е. сосредоточиться не на подробностях реализации эффекта, а на его конкретных параметрах.
Кое-то работающее есть, но это посто хобби.


Я периодически экспериментрирую именно в области разработки языков — то под обработку звука, то под обработку изображений.

Здравствуйте, Sinclair, Вы писали:

S>В нефиксированном размере ядра, из-за чего unsafe оптимизации через "ограничение каймы" являются некорректными.

Во втором же своём сообщении я про это упомянул.
Потом долго испытывал странную эмоцию из разряда "я один это вижу?" (С)


S>Ну, во-первых, давайте посмотрим на то, как выглядит этот код без линка, а с применением любого другого подхода по вашему выбору.

В коде без линка никто не мешает задавать диапазон обхода непосредственно в алгоритме:

for(y = offset1, end = array.Count - offset2; y < end; y++)
   ...

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


S>В-третьих, не вполне понятен реальный сценарий, в котором на это наступишь.

Сценарий известный — градиент размытия от центра или к центру.
Т.е. в центре самый фокус, по краям самое размытие.
Или наоборот.


S>Ну, то есть пока что все задачки, которые обсуждались на уровне кода, использовали статические ядра.

Это как раз нормально.
Ненормальной была реакция на моё предложение посмотреть на более широкий класс задач.


S>Так что есть искушение просто запретить такое при исполнении запроса — то есть обнаружив неконстантные выражения в IRelativeAccess<>.get_Item, сразу выкидывать IndexOutOfRange, не дожидаясь проблемы.

Тогда ты "займёшь" данную сигнатуру конкретной реализацией.
Впрочем, я уже повторяюсь десятикратно тут...


S>Можно сделать наоборот — продолжать применять проверки диапазонов при каждом обращении, кроме доказанно-константных случаев.

Всё можно.
Пока опять на что-то не напорешься.

Мне как раз разнесение целевого кода от "контракта" сходу и не понравилось, если уж начистоту.
Понятное дело, что запись алгоритма в пару строк — мечта любого программиста.
Но всерьёз если, то под это дело нужны специальные языки.

Под обработку звука я периодически ковыряю свой эксперимент. Но там больше графическая нотация подходит, чем текстовая.
В текстовой форме упираешься сразу в представление параметризации исходного алгоритма — оно чудовищное.
Это таблица со значениями, а лучше эдакий "девайс" с большим кол-вом крутилок.
И чтобы впрямо в реалтайме эти крутилки крутить и слушать, т.е. сосредоточиться не на подробностях реализации эффекта, а на его конкретных параметрах.
Кое-что работающее есть, но это посто хобби.


Я периодически экспериментрирую именно в области разработки языков — то под обработку звука, то под обработку изображений.