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

S>Пока что видно, что стоит вместо from d писать from d.AsRelative(Bounds.Cut).

Можно, но компилятор не подскажет.
Ведь никогда не стоит вопрос "просто убрать лишний код" (тем более, что убираемый код тривиален).
В кавычках лишь следствие цели.
Целью является "убрать из головы разработчика лишние подробности, дав ему возможность решать задачу на более высоком уровне".
В твоём варианте подобные подробности всё-равно надо держать в голове.


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

Так и у меня часть системы на шарпе, которая графы визуально строит.

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

Участки вычислений, ограничивающие сигнал, тоже "поглощают" друг друга. Грубо, вот есть усечение, потом умножение на больше 1, потом опять усечение — первое усечение является избыточным, оно уходит. При этом усечение сигнала — это одна из самых затратных операций, бо делается через условное ветвление. Как раз перекликается с деталями нашего обсуждения.

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

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

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

S>Пока что видно, что стоит вместо from d писать from d.AsRelative(Bounds.Cut).

Можно, но компилятор не подскажет.
Ведь никогда не стоит вопрос "просто убрать лишний код" (тем более, что убираемый код тривиален).
В кавычках лишь следствие цели.
Целью является "убрать из головы разработчика лишние подробности, дав ему возможность решать задачу на более высоком уровне".
В твоём варианте подобные подробности всё-равно надо держать в голове.


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

Так и у меня часть системы на шарпе, которая графы визуально строит.

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

Участки вычислений, ограничивающие сигнал, тоже "поглощают" друг друга. Грубо, вот есть усечение, потом умножение на больше 1, потом опять усечение — первое усечение является избыточным, оно уходит. При этом усечение сигнала — это одна из самых затратных операций, бо делается через условное ветвление. Как раз перекликается с деталями нашего обсуждения.

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

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