(я боюсь, что вообще не туда попал. Здесь все очень серьёзные)
По рекомендации господина LaptevVV, я осмелюсь предложить Вашему вниманию краткую выжимку из своего опыта и ряд соображений. Здесь речь идёт об управлении многообразием графических компонентов, известное как комбинаторный взрыв. Тема актуальна для разработчиков всевозможных редакторов, САПР и игр.
Если это окажется интересным, то я постараюсь экстраполировать свой опыт по этой теме, написать библиотеку и оформить статью.
За 20 лет моей работы в сфере ИТ, 80% работы было связано с рисованием и управлением, — то есть с интерактивной графикой. Это были всякого рода редакторы, GUI и игрушки.
Классическим руководством по этой тематике я считаю книгу Гради Буча про ООП. В ней есть ряд хороших примеров по построению иерархии классов и объектов с методами рисования и управления.
Следующим этапом исследования этой темы является библиотека Objective View на C++ от компании Stingray. Несмотря на то, что такой компании уже нет, реализованная архитектура MVC – модель, вид, контроллер, до сих пор является актуальной.
С точки зрения GUI эта тема имеет множество реализаций, начиная от WIN_API_32 – MFC, виджетами *nix – X-Windows и заканчивая множеством других подобных технологий.
Существенным вкладом в тему я считаю технологию Ангуляр 2. Основы её разрабатывались тогда (2008 – 2010 гг), когда я увлечённо писал собственную библиотеку. Теперь я нахожу много эффективных сходств. Прежде всего – это контекст управления. Во-вторых, — это каскадные свойства.
Это было введением в тему.
А теперь – постановка задачи:
— При отображении графических примитивов и организации управления ими, необходимо учитывать множество вариантов. Это я называю «способностью компонента». Сюда относятся такие вещи, как способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, эффекты, связки, стрелочки и т.п.
Таким образом проявляется эффект комбинаторного взрыва.
Крупные компании могут себе позволить форсирование этой проблемы, нанимая 10, 100 и 1000 программистов, для обслуживания всех частных случаев. Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.
Что же можно сделать? И причём тут тензорная архитектура?
Прежде всего, я предлагаю разделить интерактивную задачу на 4 пространства:
1. пространство пользовательских операций,
2. пространство команд для стека Undo/Redo,
3. пространство управляемых компонентов,
4. пространство способностей компонентов — элементов.
Теперь рассмотрим эти пространства подробнее.
1.Пространство пользовательских операций.
Каждая операция должна иметь метод или признак срабатывания. При этом, надо учитывать что обращение к каждой операции происходит в последовательном цикле. К сожалению, ничего более умного пока придумать не удалось. Может быть введение кодов типа MouseMove что-то изменит.
Кстати!
Вы можете существенно облегчить свой редактор, если будете игнорировать MouseMove, который происходит слишком часто.
Для интерактивной программы достаточно опрашивать позицию курсора синхронно с частотой обновления экрана – 25 Гц.
Здесь ещё надо добавить, что ряд операций захватывают управление. Типа перетаскивания.
Значит Вам надо где-то хранить: координаты курсора, нажатые клавиши, активную операцию и т.п.
Вот здесь мы приходим к пониманию важного класса – Контекст Управления. Его экземпляр нам надо передавать в каждую операцию, как при опознавании актуальной операции, так и при её реализации.
2.Пространство команд для стека Undo/Redo.
Надеюсь, что всем понятно – пользовательские операции не меняют объектов редактирования, за исключением операций выделения, изменением масштаба вида, положения холста и т.п.
Потому что при редакции они должны порождать команды.
В архитектуре MVC эта тема очень хорошо проработана.
Надо заметить, что в тензорной архитектуре нам придётся писать большинство команд не для компонентов, а для их элементов.
3.Пространство управляемых компонентов.
В идеале, класс компонента должен быть одним, универсальным. Объект этого класса — это та единица, с которой работает пользователь.
Что он должен делать? – Иметь список своих элементов-способностей и работать с Контекстом Управления. А именно: быть активным, выделенным, перемещаться, копироваться, трансформироваться, быть группой или членом группы и т.п.
Однако есть исключения. Такие компоненты, как Холст, Лист и Вид, легче породить от универсального класса как частный случай.
4.Пространство способностей компонентов – элементов.
Здесь сосредоточена вся работа: способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, трансформации, эффекты, связки, стрелочки и т.п. Поскольку элементы заносятся в список компонента, то пользователь может настраивать свои компоненты динамически, определяя порядки и способности.
Итак. Мы рассмотрели 4 пространства классов, которые можно обозначить k, l, m, n. При нахрапистом подходе потребуется написать код примерно для k * l * m * n методов!
Всё будет очень жёстко и фирма изнасилует много программистов, чтобы добиться элементарного единообразия.
При тензорной архитектуре, которую я нарисовал, Вам достаточно написать примерно k + l + m + n методов. Ещё можно написать ряд методов для настройки компонентов. Единообразие гарантировано самой архитектурой.
***
Я очень надеюсь, что для программистов с опытом создания редакторов — тема ясна.
Я очень надеюсь, что для всяких специалистов — тема будет интересна и полезна.
Прошу не вдаваться в демагогию. И требовать от меня определений — пока не надо. Тема ещё сырая.
Далее — мне проще приводить конкретный код с комментариями, чтобы постепенно довести его до практической применимости.
Пускай мой код служит доказательством. Чтобы мы не уходили в словоблудие.
Здравствуйте, LVE, Вы писали:
LVE>По рекомендации господина LaptevVV, я осмелюсь предложить Вашему вниманию краткую выжимку из своего опыта и ряд соображений. Здесь речь идёт об управлении многообразием графических компонентов, известное как комбинаторный взрыв. Тема актуальна для разработчиков всевозможных редакторов, САПР и игр. LVE>Если это окажется интересным, то я постараюсь экстраполировать свой опыт по этой теме, написать библиотеку и оформить статью.
LVE>За 20 лет моей работы в сфере ИТ, 80% работы было связано с рисованием и управлением, — то есть с интерактивной графикой. Это были всякого рода редакторы, GUI и игрушки.
Судя по написанному ниже, игрушек было больше (вот такое сложилось мнение). А т.к. подходы для проектирования принципиально разные, то я не стал бы собирать всё в одну кучу.
LVE>Следующим этапом исследования этой темы является библиотека Objective View на C++ от компании Stingray. Несмотря на то, что такой компании уже нет, реализованная архитектура MVC – модель, вид, контроллер, до сих пор является актуальной.
Стингреевские контролы в свое время были неплохи. Ихнее MVC для графических редакторов ну никак не вписывалось. Может для каких-нибудь табличных редакторов оно и пригодно —
LVE>А теперь – постановка задачи: LVE>- При отображении графических примитивов и организации управления ими, необходимо учитывать множество вариантов. Это я называю «способностью компонента». Сюда относятся такие вещи, как способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, эффекты, связки, стрелочки и т.п. LVE>Таким образом проявляется эффект комбинаторного взрыва. LVE>Крупные компании могут себе позволить форсирование этой проблемы, нанимая 10, 100 и 1000 программистов, для обслуживания всех частных случаев. Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.
Но тут пришел наш камрад Андрей Федонюк (АКА c-smile) и одним махом решил все проблемы, создав замечательную библиотеку htmlayout.
LVE>Что же можно сделать? И причём тут тензорная архитектура? LVE>Прежде всего, я предлагаю разделить интерактивную задачу на 4 пространства:
LVE>1.Пространство пользовательских операций. LVE>Каждая операция должна иметь метод или признак срабатывания. При этом, надо учитывать что обращение к каждой операции происходит в последовательном цикле. К сожалению, ничего более умного пока придумать не удалось. Может быть введение кодов типа MouseMove что-то изменит.
Непонятное утверждение. Какая операция? В каком цикле?
Жмякнули на checkbox, получили уведомление, обработали событие. Где цикл?
LVE>Кстати! LVE>Вы можете существенно облегчить свой редактор, если будете игнорировать MouseMove, который происходит слишком часто. LVE>Для интерактивной программы достаточно опрашивать позицию курсора синхронно с частотой обновления экрана – 25 Гц.
Мой опыт подсказывает, что MouseMove приходит реже, чем 25Гц.
Поэтому если надо делать графический редактор, то лучше привязываться к MouseMove. Для игр, где графика должна быть плавной и изображение может меняться без участия пользователя (анимация — дует ветер, деревья колышутся, персонаж стоит и ковыряется в носу) нужна привязка к FPS.
LVE>Здесь ещё надо добавить, что ряд операций захватывают управление. Типа перетаскивания. LVE>Значит Вам надо где-то хранить: координаты курсора, нажатые клавиши, активную операцию и т.п. LVE>Вот здесь мы приходим к пониманию важного класса – Контекст Управления. Его экземпляр нам надо передавать в каждую операцию, как при опознавании актуальной операции, так и при её реализации.
Для этого существуют конечные автоматы. А контекст элементарный — исходное положение курсора + текущее положение курсора.
LVE>2.Пространство команд для стека Undo/Redo. LVE>Надеюсь, что всем понятно – пользовательские операции не меняют объектов редактирования, за исключением операций выделения, изменением масштаба вида, положения холста и т.п. LVE>Потому что при редакции они должны порождать команды.
Агащяззз.
Существует два способа реализации Undo/Redo.
1. "действие-антидействие" (АКА паттерн "Команда")
2. Сделать snapshot БД перед началом редактирования (паттерн "состояние").
Первый способ применим для дискретных операций — удалить объект, сменить состояние крыжика.
А вот если тебе надо переместить объект, а во время перемещения надо объект отрисовывать, попутно перестраивая какие-нибудь связи... тут я пожелаю тебе удачи. Здесь необходим второй метод.
Реализация второго способа простая, достаточно хранить не всю базу, а только модифицируемые объекты.
Оба способа легко комбинируются.
LVE>3.Пространство управляемых компонентов. LVE>В идеале, класс компонента должен быть одним, универсальным. Объект этого класса — это та единица, с которой работает пользователь. LVE>Что он должен делать? – Иметь список своих элементов-способностей и работать с Контекстом Управления. А именно: быть активным, выделенным, перемещаться, копироваться, трансформироваться, быть группой или членом группы и т.п. LVE>Однако есть исключения. Такие компоненты, как Холст, Лист и Вид, легче породить от универсального класса как частный случай.
Как только появляются связи между объектами (или компонентами в твоей терминологии??? я уже запутался), так все эти общие классы летят к чертям.
Можно выделить некоторые общие интерфейсы, но это предел.
С интерфейсами, кстати, есть занятная проблема. Полиморфизьм это, конечно, замечательно. Но! Следует помнить, что алгоритмы определяют структуры данных, а не наоборот. Можно нарисовать красивые структуры данных, разные там интерфейсы, но если из-за этого алгоритм из O(N) превращается в О(N^3), то нафиг такие структуры данных.
LVE>4.Пространство способностей компонентов – элементов. LVE>Здесь сосредоточена вся работа: способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, трансформации, эффекты, связки, стрелочки и т.п. Поскольку элементы заносятся в список компонента, то пользователь может настраивать свои компоненты динамически, определяя порядки и способности.
Если говорить о редакторе, то число состояний каждого компонента конечно. Определяется на уровне представления (View в MVC).
LVE>Итак. Мы рассмотрели 4 пространства классов, которые можно обозначить k, l, m, n. При нахрапистом подходе потребуется написать код примерно для k * l * m * n методов! LVE>Всё будет очень жёстко и фирма изнасилует много программистов, чтобы добиться элементарного единообразия.
LVE>При тензорной архитектуре, которую я нарисовал, Вам достаточно написать примерно k + l + m + n методов. Ещё можно написать ряд методов для настройки компонентов. Единообразие гарантировано самой архитектурой.
Это в обычной архитектуре будет примерно l + m + n методов (k — лишнее, а кстати, что такое k? ), без всяких комбинаторных взрывов.
LVE>Я очень надеюсь, что для программистов с опытом создания редакторов — тема ясна.
LVE>Далее — мне проще приводить конкретный код с комментариями, чтобы постепенно довести его до практической применимости. LVE>Пускай мой код служит доказательством. Чтобы мы не уходили в словоблудие.
Сдается мне, Владимир Евгенич, что ты сильно усложняешь.
Но подождём кода.
_____________________
С уважением,
Stanislav V. Zudin
Re[2]: Тензорная архитектура на примере интерактива
Я рад Вашему вниманию к теме.
Сожалею, что не могу ответить на все Ваши замечания.
Давайте знакомиться. Меня зовут – Владимир Евгеньевич.
Меня интересует создание учебных пособий по интерактивной графике и по тензорной архитектуре.
Всё хочется сделать с пошаговой демонстрацией рабочего кода.
Я ориентируюсь на С#. Можно продублировать код на С++.
Вы можете выступить в качестве соавтора методички, если представите свою концепцию интерактивных взаимодействий.
Я уверен, что Ваш опыт будет очень интересен читателям.
Более того. Вы можете выступить в качестве эксперта по интерактивным технологиям, но только если есть возможность документально подтвердить свою квалификацию.
Здравствуйте, LVE, Вы писали:
LVE>Что же можно сделать? И причём тут тензорная архитектура? LVE>Прежде всего, я предлагаю разделить интерактивную задачу на 4 пространства: LVE>1. пространство пользовательских операций, LVE>2. пространство команд для стека Undo/Redo, LVE>3. пространство управляемых компонентов, LVE>4. пространство способностей компонентов — элементов.
Никакая это не "тензорная архитектура", обыкновенный частный случай Separation of Concerns
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Меня интересует создание учебных пособий по интерактивной графике и по тензорной архитектуре.
Благое начинание, а есть потребность в таком учебном пособии?
Методичка обычно пишется в формате "делай так". Такой формат хорош для выполнения отдельно взятой задачи, но в общем виде, для расширения кругозора, кмк не подходит.
Если есть чем поделиться, то лучше книга в формате "как я рожал ёжиков", т.е. с описанием задачи, проблем, с которыми пришлось столкнуться и способов, какими эти проблемы разрулили.
В качестве примера замечательная книжица (думаю, в библиотеке возможно найти).
LVE>Вы можете выступить в качестве соавтора методички, если представите свою концепцию интерактивных взаимодействий. LVE>Я уверен, что Ваш опыт будет очень интересен читателям.
У нас, я подозреваю, несколько различный взгляд на проблему, передерёмся Поэтому сразу беру самоотвод.
LVE>Более того. Вы можете выступить в качестве эксперта по интерактивным технологиям, но только если есть возможность документально подтвердить свою квалификацию.
Даже не представляю, как можно документально подтвердить квалификацию.
_____________________
С уважением,
Stanislav V. Zudin
Re[2]: Тензорная архитектура на примере интерактива
Здравствуйте, alpha21264, Вы писали:
A>Чё пристал? A>Ну нравится человеку слово "тензор". A>Он таким образом воспринимает многомерность и независимость этих ваших "концернов".
A>Я под его влиянием даже начал книжку про тензоры читать
Не, ну тогда, конечно, польза есть
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>ТЕНЗОРНАЯ АРХИТЕКТУРА (с) — Владимир Евгеньевич Липатов.
Ну да, если копирайт налепить на любое сочетание слов, оно, конечно же станет осмысленным
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, Arsen.Shnurkov, Вы писали:
A>>Ну нравится человеку слово "тензор". A>>Я под его влиянием даже начал книжку про тензоры читать
AS>А силён ли ты в "миварных технологиях"?
Оооо, какая интересная штучка!
Слово такое вижу впервые, но про что-то подобное много думал.
Может быть и силён. Начну с того, что про это почитаю.
Течёт вода Кубань-реки куда велят большевики.
Re[5]: Тензорная архитектура на примере интерактива
Здравствуйте, vmpire, Вы писали:
LVE>>ТЕНЗОРНАЯ АРХИТЕКТУРА (с) — Владимир Евгеньевич Липатов. V>Ну да, если копирайт налепить на любое сочетание слов, оно, конечно же станет осмысленным
Мне совершенно не важно — что вы думаете об этом сочетании слов.
Мне интересно то, что вы можете сделать, услышав их.
Re[5]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
AS>>А силён ли ты в "миварных технологиях"? LVE>Похоже наш ТРИЗ украли, перевели, а теперь нам обратно его впаривают.
Не, похоже это что-то для распила бюджета
Re[5]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Мне совершенно не важно — что вы думаете об этом сочетании слов. LVE>Мне интересно то, что вы можете сделать, услышав их.
Сделать я могу только одно: заявить о том, что не понимаю их смысла.
По начальному посту — это просто частный случай SoC. По крайней мере, я не понял, в чём отличие.
Если сможете объяснить — тогда смогу прокомментировать подробнее.
А так — разбить систему на подзадачи и компоненты, чтобы не было связей всех со всеми — это абсолютно типовая задача любого проектировщика ПО.
Под которую давно уже есть и теоретическая база и метрики качества этой работы (coupling/cohesion) и эмпирические правила по её осуществлению.
Само разбиение будет, естественно, разным для разных решаемых задач.
Re[6]: Тензорная архитектура на примере интерактива
V> Под которую давно уже есть и теоретическая база и метрики качества этой работы
И такой код с Undo/Redo уже написано на C# (я его не сам писал, но в моём репозитории на Github такой есть)
приведённое топикстартером решение является банальностью, которая применяется в графических редакторах лет 15 точно.
И всё это вещается с жутчайшим апломбом, мол "20 лет опыта, внимайте мне, меня волнует как я вас вдохновил".
Re[7]: Тензорная архитектура на примере интерактива
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>И такой код с Undo/Redo уже написано на C# (я его не сам писал, но в моём репозитории на Github такой есть) AS>приведённое топикстартером решение является банальностью, которая применяется в графических редакторах лет 15 точно. AS>И всё это вещается с жутчайшим апломбом, мол "20 лет опыта, внимайте мне, меня волнует как я вас вдохновил".
Твоё возмущение — абсолютно не обосновано. Банальная зависть и личная неприязнь.
А вот у меня есть серьёзные основания для развития этой темы.
Дело в том, что множество фирм имеют либо избыток ресурсов, либо тырят готовые компоненты без оглядки.
Ярким примером этого является то, что частенько в редакторе ввода и в окне вывода — используются разные шрифты.
Меня это напрягает, потому что иногда я публикую таблицы.
В такой ситуации я не знаю — как будет выглядеть моё сообщение и как сделать так, чтобы всё было выровнено.
Здравствуйте, LVE, Вы писали:
LVE>(я боюсь, что вообще не туда попал. Здесь все очень серьёзные)
Мне кажется, тут обратная ситуация.
LVE>За 20 лет моей работы в сфере ИТ, 80% работы было связано с рисованием и управлением, — то есть с интерактивной графикой. Это были всякого рода редакторы, GUI и игрушки.
Я вообще не в этой теме.
LVE>- При отображении графических примитивов и организации управления ими, необходимо учитывать множество вариантов. Это я называю «способностью компонента». Сюда относятся такие вещи, как способ отображения (Заливка и Окантовка), буферизация, способы редактирования, декоративные навески (типа лейблов, рамочек и заголовков), хендлы редактирования, эффекты, связки, стрелочки и т.п. LVE>Таким образом проявляется эффект комбинаторного взрыва. LVE>Крупные компании могут себе позволить форсирование этой проблемы, нанимая 10, 100 и 1000 программистов, для обслуживания всех частных случаев. Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.
... LVE>Итак. Мы рассмотрели 4 пространства классов, которые можно обозначить k, l, m, n. При нахрапистом подходе потребуется написать код примерно для k * l * m * n методов!
Но тут у меня появились дилетантские вопросы. Вот эти крупные компании нанимают толпы разработчиков, но не могут вырастить и/или нанять немного архитекторов? И даже если так — не могу себе представить, что можно нанять 1000 студентов разрабов, все как один упорно месяцами строящих архитектуру на неких принципах комбинаторного взрыва. Ну — т.е. это даже специально невозможно так сделать.
LVE>При тензорной архитектуре, которую я нарисовал, Вам достаточно написать примерно k + l + m + n методов. Ещё можно написать ряд методов для настройки компонентов. Единообразие гарантировано самой архитектурой.
Да при обычной архитектуре средней руки будет то же самое. Я бы, вот реально, лучше бы на архитектуру с k * l * m * n методами взглянул — дико любопытно, особенно внутри продукта от компании, нанимающей 1000 разработчиков на доходы от продажи этого продукта.
Re[2]: Тензорная архитектура на примере интерактива
Здравствуйте, vmpire, Вы писали:
V>Никакая это не "тензорная архитектура", обыкновенный частный случай Separation of Concerns
Почему бы Вам не заявить, что я у них всё слизал?
Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию!
Ведь именно это у нас является национальной традицией.
Re[2]: Тензорная архитектура на примере интерактива
Здравствуйте, viellsky, Вы писали:
V>Но тут у меня появились дилетантские вопросы. Вот эти крупные компании нанимают толпы разработчиков, но не могут вырастить и/или нанять немного архитекторов? И даже если так — не могу себе представить, что можно нанять 1000 студентов разрабов, все как один упорно месяцами строящих архитектуру на неких принципах комбинаторного взрыва. Ну — т.е. это даже специально невозможно так сделать.
Делают так. Я Вас уверяю. Полно продуктов, в которых дублируется функционал и нарушается системный подход.
Т.е. происходит именно форсирование вопросов проектировки через привлечение дополнительного числа разработчиков.
V>Да при обычной архитектуре средней руки будет то же самое. Я бы, вот реально, лучше бы на архитектуру с k * l * m * n методами взглянул — дико любопытно, особенно внутри продукта от компании, нанимающей 1000 разработчиков на доходы от продажи этого продукта.
Наймитесь в крупную контору и Вам предложат писать методы для огромного количества частных случаев.
Причём, без какой либо систематизации.
Потому что время — деньги.
Решения нужны конкретные, а не общие.
Причём нужны уже вчера.
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
V>>Никакая это не "тензорная архитектура", обыкновенный частный случай Separation of Concerns LVE>Почему бы Вам не заявить, что я у них всё слизал?
У кого "у них"?
LVE>Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию! LVE>Ведь именно это у нас является национальной традицией.
Опа, в качестве аргументации уже политика и патриотизм пошли...
Я так понимаю, других аргументов больше нет.
Re[8]: Тензорная архитектура на примере интерактива
Здравствуйте, vmpire, Вы писали:
LVE>>Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию! LVE>>Ведь именно это у нас является национальной традицией. V>Опа, в качестве аргументации уже политика и патриотизм пошли... V>Я так понимаю, других аргументов больше нет.
Это, чисто культурно-лингвистический аспект.
У вас есть знакомый англичанин?
Попробуйте ему сказать при каком либо несогласии — "you're wrong", и посмотрите на его реакцию.
Если у вас нет такой возможности — то я вам скажу, что для английской культуры это большая грубость.
Это всё равно что на х*й послать. Разговор будет сразу окончен.
Однако мы привыкли говорить друг другу:
— бла-бла, ты не прав.
— бла-бла, нет, ты не прав.
Именно поэтому русских воспринимают на западе как грубых варваров.
Ну а кто мы ещё есть, если сходу отвергаем опыт друг друга.
Неудивительно, что с таким подходом мы не можем создать никакой технологии без передёргивания затвора автомата.
Вы знаете — я просто устал спорить. Я это дело никогда не любил и всегда старался понять людей.
Теперь я понял — русский человек ВСЕГДА неправ.
Это как первородный грех.
Родился русским? Тогда ты не прав.
Здравствуйте, LVE, Вы писали:
LVE>Делают так. Я Вас уверяю. Полно продуктов, в которых дублируется функционал и нарушается системный подход.
Полно, все верно. Системность нарушают, дублируют функционал. Но комбинаторики и близко при этом нет.
LVE>Т.е. происходит именно форсирование вопросов проектировки через привлечение дополнительного числа разработчиков.
Неверная причинно-следственная связь, подмена понятий. Количество разработчиков растет вследствие роста объема задач. Разве рост числа задач обусловлен только (или хотя бы в основном!) необходимостью форсировать вопросы проектировки? Нет конечно.
V>>Да при обычной архитектуре средней руки будет то же самое. Я бы, вот реально, лучше бы на архитектуру с k * l * m * n методами взглянул — дико любопытно, особенно внутри продукта от компании, нанимающей 1000 разработчиков на доходы от продажи этого продукта. LVE>Наймитесь в крупную контору и Вам предложат писать методы для огромного количества частных случаев.
Понятие "огромное" — оно субъективное. И собственно я как раз о том, что будет k + l + m + n + "огромное", а вовсе не k * l * m * n.
LVE>Причём, без какой либо систематизации.
Т.е. сидит некто, у кого в голове нет никакой системы и предлагает закрывать каждый отдельный случай. Продукта на выходе не будет. Никакого.
В реальности конечно же системность есть, она превалирует и выходит за рамки архитектуры кода, есть и исключения сплошь и рядом — вызванные рациональным подходом в разработке продукта.
LVE>Потому что время — деньги. LVE>Решения нужны конкретные, а не общие. LVE>Причём нужны уже вчера.
Вы удивитесь, но что с "тензорной архитектурой" что с любой другой в хоть сколько то крупном коммерческом продукте будет то же самое. Будут в результате и частные решения, нужные "уже вчера" и будет некая "средняя" архитектура. Перефразируя, архитектура — это процесс, а не состояние. Она будет адаптироваться под реальные, не лабораторные, условия. Будет способна терпеть разработчиков, текучку кадров, ошибки архитектора, терпеть "срочно надо вчера" и многое другое. Если не будет — не будет этого продукта и не будет компании.
Концепт архитектуры это красиво — но только потому, что кажется будто весь поток задач и реальный процесс разработки в него вписываются.
Re[5]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Здравствуйте, vmpire, Вы писали:
LVE>>>Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию! LVE>>>Ведь именно это у нас является национальной традицией. V>>Опа, в качестве аргументации уже политика и патриотизм пошли... V>>Я так понимаю, других аргументов больше нет. LVE>Это, чисто культурно-лингвистический аспект. LVE>У вас есть знакомый англичанин? LVE>Попробуйте ему сказать при каком либо несогласии — "you're wrong", и посмотрите на его реакцию. LVE><...>
Я постоянно общаюсь с англоговорящими уже много лет. То, что Вы написали для меня очевидно, но никоим образом не относится к сути обсуждаемого вопроса.
Так же, как не относятся политика, национальность и патриотизм.
LVE>Ну а кто мы ещё есть, если сходу отвергаем опыт друг друга.
Вы ещё ничего не написали, чтобы отвергать.
Сейчас для меня это всё выглядит как изобретение велосипеда после большого времени проведённого в изоляции от индустрии разработки ПО.
Которая (изоляция) недавно всё-таки закончилась (возможно, смена работы или окончание очень длинного проекта).
Изобретение, спору нет, нужное и полезное. Только вот давно не новое, а много лет назад освоенное промышленностью.
В частности, по приведённой мною ссылке Вы можете увидеть множество альтернативных способов уменьшения сложности в дополнение к Вашему.
Насколько я понимаю, он ближе всего к "Subject-oriented programming", но точно не сказать, так как у Вас только весьма общие рассуждения.
LVE>Неудивительно, что с таким подходом мы не можем создать никакой технологии без передёргивания затвора автомата.
Неудивительно, что некоторые не могут дискутировать без передёргивания темы.
LVE>Вы знаете — я просто устал спорить. Я это дело никогда не любил и всегда старался понять людей.
Вы не спорите. Вы не приводите аргументов. Вы не опровергаете аргументы оппонентов.
Это не спор. Это размахивание флагами, выкрикивание лозунгов и навешивание ярлыков.
Извините за прямоту, как Вы написали, это национальная черта.
LVE>Теперь я понял — русский человек ВСЕГДА неправ. LVE>Это как первородный грех. LVE>Родился русским? Тогда ты не прав.
А кто неправ, если спорят двое русских?
Re[4]: Тензорная архитектура на примере интерактива
Вы очень хорошо высказались. Согласен с большинством ваших умозаключений.
Однако вот в этом месте существует интересный аспект:
LVE>>Причём, без какой либо систематизации. V>Т.е. сидит некто, у кого в голове нет никакой системы ...
Во многих бородатых компаниях существуют старожилы, которые не понимают ООП, полиморфизм, шаблоны и прочие технологии.
Они когда-то наваяли код на голом си, с malloc() от которых я вздрагиваю.
И ничего менять они не хотят, чтобы не утратить своего влияния.
Существуют как собака на сене.
Вот такая практика.
Как же в такой ситуации действуют управляющие?
В одной такой фирме управляющий нанимал людей для работы с чистого листа.
Т.е. рабочим контекстом был только принятый формат файлов.
Каждый работник сам писал код для работы с файлами и строил свою объектную модель.
Функциональная обвязка решалась с помощью копипасты.
Видите, какие ужасы бывают в жизни!
Re[5]: Тензорная архитектура на примере интерактива
Здравствуйте, vmpire, Вы писали:
V>Сейчас для меня это всё выглядит как изобретение велосипеда после большого времени проведённого в изоляции от индустрии разработки ПО. V>Которая (изоляция) недавно всё-таки закончилась (возможно, смена работы или окончание очень длинного проекта). V>Изобретение, спору нет, нужное и полезное. Только вот давно не новое, а много лет назад освоенное промышленностью.
Да. Так оно и произошло. Причём именно из-за подобной интерактивной библиотеки.
Это была моя грандиозная катастрофа.
Я 15 лет собирал материал по этой теме.
Выдался такой случай, что я уволился с работы.
Заперся дома и за 3 месяца написал её — like.view.
Работал по 20 часов в сутки.
Потом я совершил пару глупостей.
Во-первых, я опубликовал код.
Во-вторых, я отверг коммерческое предложение, чтобы закрыть код.
В тот момент у меня была сильная заинтересованность в развитии проекта.
Библиотека позволяла писать множество расширений как по функционалу управления, так и по добавлению новых компонентов, эффектов и прочих вкусностей.
Однако я плохо рассчитал реакцию общества.
Никаких иных предложений не поступало. Никто со мной не связывался.
Время шло, а люди качали мой код втихаря.
Никто даже спасибо не сказал.
Я тогда чуть с собой не покончил.
И в тот момент меня осенило, что своей открытой разработкой я может быть сломал не одним людям их бизнес.
Тогда я принял решение — стереть.
И стёр. И из инета убрал.
И сам ушёл.
Интерес к программированию поутих, но не пропал.
Примерно раз в год у меня были небольшие задачки.
Я их доводил до уровня прототипа.
Однако никто не собирался за них платить.
Как будь-то меня кто-то проклял.
Это как злой рок, как испорченная карма.
Сейчас я вылез из норы.
Я теперь понимаю, что в архитектурном новаторстве действительно отстал.
Однако если будет интерес к теме интерактивной библиотеки, то я готов к сотрудничеству.
Re[8]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Тема актуальна для разработчиков всевозможных редакторов, САПР и игр.
Тоже тогда поделюсь опытом, а точнее напишу в очередной раз тоже самое, что уже писал неоднократно.
Для начала опишу парадигмы программирования существующие в С++ из коробки, потому что не из коробки их ещё больше.
1. Процедурное программирование
2. Функциональное программирование
3. Объектно-ориентированное программирование
4. Обобщённое программирование (шаблоны C++)
Теперь, что касается связывания объектов:
1. Во время компиляции (compile time)
2. Во время исполнения (runtime)
Каждая парадигма реализует свои варианты связывания, да и объекты в данном случае условное понятие, скажем так это данные и методы работы с ними.
Object Management Group (OMG) и другие уже давно исследуют способы гибкого управления объектами, но если обобщить существуют всего два подхода:
1. Передача данных
2. Передача методов
Передача данных это то, что следует принципу CRUD, то есть REST, SQL и прочие. Передача методов соответственно XML-RPC, CORBA и так далее. И то и другое позволяет передать данные или методы, но делается это принципиально разными способами.
Осуществить передачу данных или методов можно разными способами, например, обратиться к оперативной памяти (стек, куча), по tcp/ip и тому подобное. Соответственно и скорость работы будет очень сильно различаться. Просто обращаясь к свойству объекта (передача данных) или вызывая метод (передача методов) мы уже делаем выбор в пользу того или иного способа работы.
Далее поговорим о двух конкретных платформах, это .NET и QT. Первое, что хотелось бы сказать, что с .NET нужно сваливать именно на Qt, если хочется приобрести в одних возможностях и при этом не потерять в других. Но в принципе тем кто работал с тем или другим будет понятно о чём дальше пойдёт речь.
В основе многих классов лежит некий корневой класс называемый объектом, так же поддерживается рефлексия. Если брать Qt, то рассмотрение можно начать с мета-объектой системы.
Если нужно создать скоростную битомолку произведя связывание во время компиляции, то отлично подойдёт обобщённое программирование с теми же шаблонами C++. Во время же исполнения можно передавать интерфейсы, свойства, методы и сигналы-слоты (аналог событий). Пусть это и не так быстро и работает где-то на полиморфизме, где-то на свитчах (см. генерируемые moc файлы), зато открывает широкие возможности.
При этом не играет особой роли зашиты ли подобные объекты непосредственно в исполняемую программу или подключаются с помощью плагинов являющихся динамическими библиотеками. При этом кроссплатформенность достигается уже на этом уровне, причём благодаря рефлексии ничто не мешает подключить другие способы передачи данных или методов поверх существующего слоя.
Всё это добавляет гибкости, но не избавляет от нудного написания компонентов. Теперь, что касается книг, в моей личной библиотеке тщательно отобранных книг есть Буч Гради (не считая более старых изданий):
1. Объектно-ориентированное проектирование с примерами применения
2. Объектно-ориентированный анализ и проектирование 3-е издание
3. Унифицированный процесс разработки программного обеспечения
4. UML Руководство пользователя 2-е издание
Но по архитектуре я бы рекомендовал Фаулер Мартин "Архитектура корпоративных программных приложений". Это именно про enterprise, чем собственно говоря и являются большие программы комбайны.
Re[4]: Тензорная архитектура на примере интерактива
Здравствуйте, Stanislav V. Zudin, Вы писали:
LVE>>Более того. Вы можете выступить в качестве эксперта по интерактивным технологиям, но только если есть возможность документально подтвердить свою квалификацию.
SVZ>Даже не представляю, как можно документально подтвердить квалификацию. SVZ>
Сделать скриншоты разработанных технологий и их исходных текстов, заверить у нотариуса — чего тут непонятного?
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Здравствуйте, vmpire, Вы писали:
V>>Никакая это не "тензорная архитектура"...
LVE>ТЕНЗОРНАЯ АРХИТЕКТУРА (с) — Владимир Евгеньевич Липатов.
Idée fixe — (фр.) сверхценная идея
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Здравствуйте, vmpire, Вы писали:
V>>Никакая это не "тензорная архитектура", обыкновенный частный случай Separation of Concerns
LVE>Почему бы Вам не заявить, что я у них всё слизал? LVE>Тогда Вы сможете более эффективно втоптать в грязь своего соотечественника и превознести импортную технологию!
Только патент спасёт отца тензорной архитектуры!
Re[4]: Тензорная архитектура на примере интерактива
Здравствуйте, Vladek, Вы писали:
V>Только патент спасёт отца тензорной архитектуры!
Между прочим NVidia анонсировала тензорные ядра в следующем поколении видеокарт на архитектуре Volta, потому в ближайшие годы ожидаемо возрастание интереса к TPU (Tensor Processor Unit).
https://www.opendesign.com Советую глянуть сюда, это серьезная библиотека для работы с автокадовскими чертежами, используется во многих проектах,
public api очень даже неплохо спроектирован. Есть некоторое пересечение с вашими идеями
Re[4]: Тензорная архитектура на примере интерактива
Здравствуйте, Vladek, Вы писали:
V>Только патент спасёт отца тензорной архитектуры!
Патент на программы не выдают.
Можно только зарегистрировать авторские права.
У нотариуса — это сделать проще и дешевле.
Только надо учитывать, что с лазерных распечаток тонер может посыпаться.
Поэтому лучше печатать на матричном принтере.
Re[2]: Тензорная архитектура на примере интерактива
Здравствуйте, velkin, Вы писали:
V>Теперь, что касается связывания объектов: V>1. Во время компиляции (compile time) V>2. Во время исполнения (runtime)
V>Каждая парадигма реализует свои варианты связывания, да и объекты в данном случае условное понятие, скажем так это данные и методы работы с ними.
V>Object Management Group (OMG) и другие уже давно исследуют способы гибкого управления объектами, но если обобщить существуют всего два подхода:
V>1. Передача данных V>2. Передача методов
...
Есть ещё один способ — через компиляцию производных пользовательских классов во время исполнения основной программы с помощью встроенного компилятора.
Кстати, мне интересно попробовать именно этот способ для борьбы с комбинаторным взрывом.
Это делалось 7 лет назад.
Конечно есть ряд глюков и багов.
Если винда будет отчаянно бороться за свой курсор — то кликните в меню.
Чтобы хорошенько поиграться с демкой — прочитайте описание — Description.
Re[2]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали: LVE>Нашёл одну из первых версий LikeView
Занятная игрушка.
Стресс-тесты делал?
Скажем, пару миллионов примитивов без анимации нарисовать сможет?
Что-то подобное рисовать можно?
Кусок платы
При работе с тяжелой графикой приходится оперировать с несколькими представлениями одних и тех данных. Скажем, пользователь редактирует объекты, которые лежат в структурах данных в, так сказать, исходном виде, при этом поиск выполняется в 2Д-(или 3Д-)хеше, а рисуются те же объекты, но в триангулированном виде, которые хранятся в виде массива вершин. И таких представлений могут быть десятки — зависит от решаемых задач.
Если в собственном движке все эти представления данных хорошо укладываются и выводятся одни из других, то как с этим обстоят дела в универсальных движках?
Вот в твоей архитектуре это учитывается? Её можно будет применить для рисования через OpenGL/DirectX?
Кстати, поделюсь опытом. В одном из проектов мой предшественник , которого покусал Александреску, применил Визитёра для работы с данными.
Всё было сделано так, как ты мечтал — никакого комбинаторного взрыва , все операции над объектами проходят через единственный метод, а в зависимости от визитёра, подсунутого в этот метод, мы получаем и поиск, и рисование, и формирование тултипов, и перебор объектов с какими-то трансформациями...
Но вот проблема в том, что такой приём хорош для лабораторной работы в институте. А в реальной жизни, когда число объектов выросло до пары тысяч вся программа встала колом. Потому что перебор через Визитёр вырождался в O(N^2). А уж отлаживать такой код — проще повеситься. Нам стоило немалых усилий, чтобы выпилить этот шлак и заставить работать как надо.
_____________________
С уважением,
Stanislav V. Zudin
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, Stanislav V. Zudin, Вы писали:
LVE>>Нашёл одну из первых версий LikeView
SVZ>Занятная игрушка.
Спасибо.
SVZ>Стресс-тесты делал? SVZ>Скажем, пару миллионов примитивов без анимации нарисовать сможет?
В некотором смысле — да.
У сложных объектов — сделал буферизацию.
У сетки и хендлов — быстрый растровый вывод.
Так что это зависит от уровня рукожопости.
SVZ>Что-то подобное рисовать можно?
Без проблем. Была бы только объектная модель.
Для примера — нажмите Ctrl+D — это дебажная отрисовка.
SVZ>При работе с тяжелой графикой приходится оперировать с несколькими представлениями одних и тех данных. Скажем, пользователь редактирует объекты, которые лежат в структурах данных в, так сказать, исходном виде, при этом поиск выполняется в 2Д-(или 3Д-)хеше, а рисуются те же объекты, но в триангулированном виде, которые хранятся в виде массива вершин. И таких представлений могут быть десятки — зависит от решаемых задач.
Да. С графами работа отлажена через списки зависимых компонентов.
SVZ>Если в собственном движке все эти представления данных хорошо укладываются и выводятся одни из других, то как с этим обстоят дела в универсальных движках? SVZ>Вот в твоей архитектуре это учитывается? Её можно будет применить для рисования через OpenGL/DirectX?
Думаю, что здесь будет проблема с HitTest.
SVZ>Кстати, поделюсь опытом. В одном из проектов мой предшественник , которого покусал Александреску, применил Визитёра для работы с данными. SVZ>Всё было сделано так, как ты мечтал — никакого комбинаторного взрыва , все операции над объектами проходят через единственный метод, а в зависимости от визитёра, подсунутого в этот метод, мы получаем и поиск, и рисование, и формирование тултипов, и перебор объектов с какими-то трансформациями... SVZ>Но вот проблема в том, что такой приём хорош для лабораторной работы в институте. А в реальной жизни, когда число объектов выросло до пары тысяч вся программа встала колом. Потому что перебор через Визитёр вырождался в O(N^2). А уж отлаживать такой код — проще повеситься. Нам стоило немалых усилий, чтобы выпилить этот шлак и заставить работать как надо.
Тогда я тоже поделюсь опытом.
Во многих подобных иерархиях для компонента делают привязку на родителя или владельца.
Это отнимает внимание программиста на связку компонентов, не говоря уже про небольшой расход памяти.
А когда делаешь многостраничный вывод холста — то эти связки только мешают.
Тогда я поступил просто: Я делаю стек текущих компонентов в классе Контекста.
Экземпляр контекста я передаю в методы компонента при всяких иерархических обходах модели.
Получается так — с какой бы стороны я не зашёл в компонент, его метод знает историю обхода.
Здравствуйте, LVE, Вы писали:
LVE>Сейчас я вылез из норы. LVE>Я теперь понимаю, что в архитектурном новаторстве действительно отстал.
Ничего, нагоните. Если фундаментальная база есть — то нагоните быстро.
LVE>Однако если будет интерес к теме интерактивной библиотеки, то я готов к сотрудничеству.
Лично у меня нет потребности, но может кому-то и пригодится.
Небольшой совет: сделайте демо в виде видео, с красивыми картинками и примерами API. Может, кто-то заинтересуется.
Можно послать демо разработчикам разных ыизуальных компонентов, такая целевая реклама часто работает лучше.
Re[8]: Тензорная архитектура на примере интерактива
Здравствуйте, vmpire, Вы писали:
LVE>>Однако если будет интерес к теме интерактивной библиотеки, то я готов к сотрудничеству. V>Лично у меня нет потребности, но может кому-то и пригодится. V>Небольшой совет: сделайте демо в виде видео, с красивыми картинками и примерами API. Может, кто-то заинтересуется. V>Можно послать демо разработчикам разных ыизуальных компонентов, такая целевая реклама часто работает лучше.
Спасибо за добрые слова.
Однако Вы не поняли — библиотека уничтожена из принципиальных соображений.
Я здесь показал то, что случайно осталось.
Теперь всё надо начинать заново, если будет поддержка.
Немного о наболевшем.
Я не случайно наезжаю на Макса Шеманарёва и его agg.
1. Очень неудобно работать с agg.
Его шаблоны битмапов угнетают всю работу.
Лучше бы он менял указатели на функции, и грубо кастил указатели на данные.
2. Я уже писал о том, что не надо сортировать сканлайны.
Достаточно просто транспонировать вектор векторов.
Прирост производительности для кривых и полигонов — до 30%.
3. Создавать графические объекты на стеке — очень не эффективно.
Мне нужен корневой графический класс, чтобы я обновлял его производные только при необходимости.
4. Короче — у меня есть хорошая идея — сделать 2Д рисовалку и интерактив — в одном флаконе.
Re[8]: Тензорная архитектура на примере интерактива
Здравствуйте, vmpire, Вы писали:
V>Лично у меня нет потребности, но может кому-то и пригодится.
Вот именно!
На нахрапистых ура-инвесторов я уже не рассчитываю.
На наших чинуш — тем более.
Однако, лично мне интересно сделать эту тему как пошаговое образовательное руководство с целью получения оптимального результата.
Много денег не надо. Достаточно 20 тыс.р. в месяц. + Премии до 10 тыс.р.
Вот такая простая стратегия.
Re[8]: Тензорная архитектура на примере интерактива
Здравствуйте, LVE, Вы писали:
LVE>Немного о наболевшем. LVE>Я не случайно наезжаю на Макса Шеманарёва и его agg.
LVE>1. Очень неудобно работать с agg. LVE>Его шаблоны битмапов угнетают всю работу. LVE>Лучше бы он менял указатели на функции, и грубо кастил указатели на данные.
"Павшие сраму не имут". Нет Макса с нами больше.
LVE>2. Я уже писал о том, что не надо сортировать сканлайны. LVE>Достаточно просто транспонировать вектор векторов. LVE>Прирост производительности для кривых и полигонов — до 30%.
Генерировать scanlines где-либо кроме GPU и его shaders — себя не любить.
Re[3]: Тензорная архитектура на примере интерактива
Здравствуйте, c-smile, Вы писали:
CS>"Павшие сраму не имут". Нет Макса с нами больше.
Ну, пипец. Надеюсь, что он был счастлив и не мучился.
Теперь кто-то должен продолжать его дело.
Был проект по портированию AGG на C# — это имхо фигня.
Уж лучше его портировать на голый Си. Делать структуры, указатели на функции и грубые касты.
Потом уже, можно сделать интерфейс для C#.
Это как в Москву через Владивосток. Зато в производительности не проиграешь.
Надо специальную тему где-то открыть...
Я открыл тему:
Проекты — Открытые проекты — AGG жив и будет развиваться!
Ну Вы понимаете – что эта тошнятина – словно закат солнца в ручную.
