Три траектории для одной частицы

[Zhelj]

Зато кодеры живут дольше.

По разному. У электриков бывает что и не своей смертью кончают из-за разгильдяев, что не туда думают.

Они сами не понимают того что пишут говнокод.  Это разновидность графомании.

Нет, Липатов, это такие как ты пишут говнокод, по которому есть три траектории для одной частицы. Это разновидность графомании.

Они ничего не понимают в полиморфных иерархиях классов !  Зато распальцовка на миллион. Заняли руководящие посты, бездари.

А ты понимаешь в защитах и автоматике электрооборудования? Проверку уставок сделаешь? Это у вас, свихнувшихся,  распальцовка на миллион. Программа - это только облегчение нашего труда. Да, я пользуюсь программами, на умея программировать. На это программисты есть. А ты пользуешься электричеством смутно представляя что это такое. На это электрики есть.
Поэтому опусти своё сопло до нормального уровня, а то крышу снесёт.

Трёхтомником Дональда Кнута, монографией Гради Буча их надо бить по рукам и по башке.
Они сами не понимают - как надо делать, и другим не дают.
Скоты позорные.

Нет, это программистов надо бить по рукам и по башке трёхтомником Дональда Кнута, монографией Гради Буча если они не понимают что делают. Другим эти книги даром не надь, и с деньгами не надь. Другие другой литературой пользуются.
А скоты позорные  - это авторы подобных сообщений. 

[Zhelj]

!!!!!!!!!!!!!!!!!!!!!!!!!!
Имбецыл подтверждает свой статус имбецыла!!!!!!!!!!!!!

У идиота zero опять понос.

[zero43]

Там где ты её написал, идиот. А может только думал написать,

!!!!!!!!!!!!!!!!!!!!!!!!!!
Имбецыл подтверждает свой статус имбецыла!!!!!!!!!!!!!

[Дрозд]

Цитата: Дрозд от 03-12-2021, 16:53:55

    Ну, тогда к тебе вопрос:
    Есть две линии, которые пересекаются, есть координаты начала и конца каждой линии.
    НАЙТИ:  точку пересечения.
    Написать код.


Это не код. Это школьная математика.
Приводим координаты к базису и тупо вычисляем через формулу для угла наклона.
Это мне не интересно уже.

Меня интересует анимация и интерактив.

Что-то буркнул непонятное.... 
Если бы ты знал, как найти точку пересечения, то ты бы написал. 
Я не спрашивал про угол наклона.
Попробуй со второго захода ТУПО найти точку.

[Владимир Липатов]

Что-то буркнул непонятное.... 
Если бы ты знал, как найти точку пересечения, то ты бы написал. 
Я не спрашивал про угол наклона.
Попробуй со второго захода ТУПО найти точку.

https://mathvox.ru/geometria/dekartovi-koordinati-uravneniya-figur-v-dekartovoi-sisteme-koordinat/glava-4-uravneniya-pryamoi/koordinati-tochki-peresecheniya-pryamih/

[Дрозд]

https://mathvox.ru/geometria/dekartovi-koordinati-uravneniya-figur-v-dekartovoi-sisteme-koordinat/glava-4-uravneniya-pryamoi/koordinati-tochki-peresecheniya-pryamih/

Я спрашивал КОД.....но ты тупой....

[Владимир Липатов]

Я спрашивал КОД.....но ты тупой....

Сам ты тупой как валенок.
Я могу писать в машинных кодах на PDP-11.
Только я этого не делаю, потому что это уже не актуально и мне не интересно.
Я же сказал - я не кодер. Я программист, проектировщик и архитектор.
Если тебе надо - плати деньги.
Ты форумом ошибся. Тебе надо искать фрилансеров.

[Дрозд]

Сам ты тупой как валенок.
Я могу писать в машинных кодах на PDP-11.
Только я этого не делаю, потому что это уже не актуально и мне не интересно.
Я же сказал - я не кодер. Я программист, проектировщик и архитектор.
Если тебе надо - плати деньги.
Ты форумом ошибся. Тебе надо искать фрилансеров.

Не шуми! 
Я просто проверил твой интеллектуальный уровень.

[Владимир Липатов]

Не шуми! 
Я просто проверил твой интеллектуальный уровень.

Ты просто не дорос до моего уровня чтобы его измерять.

Нака вот позырь чем я последний раз занимался:
https://disk.yandex.ru/client/disk/LiteView
Это обучалка по программированию интерактивной графики для САПР.
Там всё есть - документация, исходники, демонстрашки.

[Дрозд]

Нака вот позырь чем я последний раз занимался:
https://disk.yandex.ru/client/disk/LiteView

Там ысчо регится нуда.....

[Владимир Липатов]

Там ысчо регится нуда.....

Понимаю.
Я ту ссылку привёл, чтобы показать насколько системное программирование отличается от прикладного кода.

Библиотека и встраиваемый редактор интерактивной векторной графики LiteView
Реализация: C# DotNet 2.0.

В проект входит:
1.   Библиотека основных классов LiteView,
2.   Библиотека пользовательских элементов управления LiteViewControls,
3.   Приложение редактор для тестов и демонстрации.
4.   Этот документ описания и история версий.

Проект предназначен для создания встраиваемых редакторов схем, диаграмм, графиков и презентаций. В основу положен 15 летний опыт разработки подобных редакторов. Наиболее близким аналогом является библиотека Objective View от Stingray.
Отличительной особенностью LiteView является сочетание простоты и функциональности, что позволяет её гибко расширять и настраивать под конкретные задачи.

Основа LiteView зависит только от сборок System и System.Drawing. LiteViewControls зависит ещё и от WindowsForms.
Такая слабая зависимость от системных библиотек позволяет её легко портировать на другую платформу или подключить альтернативное графическое ядро.

Основным классом является LContext. Через него происходит взаимодействие редактора с пользовательскими контролами.
Этот класс похож на контроллер из модели MVC. Однако его полномочия намного шире. Он доступен для любых объектов, т.к. объявлен как статический член LContext.Current. Для реализации нескольких редакторов, документов и видов, этот контекст надо переключать при активизации соответствующего элемента управления. Это небольшая плата за простоту и гибкость.

Иерархия объектов приложения может выглядеть следующим образом:
1.   Приложение,
2.   Документ,
3.   Фрейм,
4.   LControlView, - пользовательский элемент управления,
5.   LContext, - контекст,
6.   LComponentView, - вид,
7.   LComponentCanvas, - холст или страницы,
8.   LComponentGroup, - группа (опционно),
9.   LComponentXXX, - любой другой компонент.

В библиотеке реализовано несколько иерархий:
1.   Иерархия компонентов LComponent и фигур LShape.
2.   Иерархия стилей LStyle, для шрифта, кисти и пера.
3.   Иерархия команд LCommand для стеков Undo/Redo.
4.   Иерархия действий для реакции на пользователя LUIAction, LUITracker.

Ещё есть ряд специализированных классов.

[Владимир Липатов]

Базовый класс LComponent реализует несколько механизмов:
1.   Механизм композиции Parent – LComponentGroup.Childs, предназначен для установления агрегатных отношений в модели.
2.   Механизм обновлений Invalidate() – OnUpdate(),предназначен для оптимизации внутренних расчётов и реализован через флаг NeedUpdate.
3.   Механизм каскадной отрисовки компонентов OnDraw() с опционной буферизацией и трансформацией.
4.   Механизм каскадной проверки попаданий HitTest().
5.   Механизм манипуляторов LHandle, для выделенных компонентов.
6.   Опциональные механизмы трансформации и буферизации.

Контекст LContext реализует несколько механизмов:
1.   Статический указатель на текущий контекст.
2.   Состояние пользовательского интерфейса LUIState.
3.   Процесс обработки действий пользователя LUIProcessor.
4.   Список выбранных компонентов Selection и HitComponent.
5.   Стеки Undo/Redo LCommandStack.
6.   Компонент вида LComponentView.
7.   Таблица стилей LStyleSheet.
8.   Список настроек LSettings.
9.   LHandleBuffer – для оптимизации отрисовки манипуляторов.

   Диспетчеризация пользовательского управления (обработчиков) осуществляется в LUIProcessor и подразделяется на мгновенные действия LUIAction и протяжённые трекеры LUITracker. Каждый из них может запускаться либо от клавиатуры и мышки (осуществляется проверка нажатия последовательности клавиш), либо от кнопок тулбаров (осуществляется прямой вызов).
   Определение множества действий и трекеров в LUIProcessor делается на стороне приложения (вне библиотеки). Это позволяет гибко настраивать пользовательский интерфейс. Однако следует иметь ввиду, что порядок следования обработчиков в процессоре играет роль. Каждый обработчик (производный от LUIAction), имеет ключ – комбинацию нажатых клавиш, которая сопоставляется с текущим состоянием LUIState. Таким образом осуществляется управление.
   Затем, при удачном выполнении действия, LUIAction или LUITracker формируют обратную команду LCommand и кладут её в стек отмены операций LCommandStack. В случае выделения нескольких компонентов, действие формирует макрокоманду LCommandMacro.

   Теперь хочется отметить ряд оригинальных решений и их побочные эффекты:
1.   Реализация множества документов и видов в одном приложении, зависит от своевременного переключения текущего контекста LContext.Current.
2.   Доступ к большинству параметров и к визуальной модели, осуществляется через текущий глобальный контекст LContext.Current. Это даёт огромные возможности, но усложняет отладку поведения.
3.   Реализация множества страниц не является однозначным решением. Это может быть разбивка холста на страницы, а может быть многостраничной презентацией. Этот вопрос пока пропускаю.
4.   Настройка интерактивного взаимодействия (семейство LUI_ классов) вынесена на уровень пользовательского приложения. Считаю это ценным решением, однако оно требует аккуратности в использовании.
5.   Методы обратного вызова реализованы через действия LUIAction, который передаёт клиенту фазу действия.
6.   Ряд возможностей компонента являются опциональными. Такие опции, как трансформация и буферизация определены в базовом компоненте. С другой стороны фигуры представляют собой семейство классов, унаследованных от LShape, в которой есть GraphicPath. Однако расширение в сторону эффектов, декораторов, анимации и т.п., требует либо развивать LComponent, либо плодить производные семейства классов, что приводит к их комбинаторному взрыву.

[Владимир Липатов]

Действия пользователя проходят несколько этапов:
1.   Вначале их перехватывает оконный контрол LControlView.
2.   Затем эти действия изменяют состояние LUIState.
3.   После этого управление передаётся в LUIProcessor.
4.   Происходит поиск действия LUIAction или LUITracker.
5.   Выполняется действие, которое может вызвать события callback.
6.   Действие порождает команду LCommand и изменяет свойство компонента.
7.   Команда попадает в стек отмены LCommandStack.

   Для предотвращения комбинаторного взрыва компонентов, был выведен ряд ортогональных и опциональных способностей:
1.   Свойства,
2.   Стили,
3.   Связи,
4.   Трансформации,
5.   Буферизация,
6.   Растровые эффекты,
7.   Декораторы,
8.   Анимация,

   Однако ряд компонентов имеет свои особенности, выходящие за рамки ортогональных способностей. Это:
1.   Фигуры,
2.   Картинки, Видео,
3.   Текст,
4.   Связки,
5.   Группы,
6.   Таблицы,
7.   Графики, Диаграммы,
8.   Формулы, Ноты, Шрифты,


Фигуры образуют следующую иерархию классов:
1.   На основе прямоугольника:
1.1.   Прямоугольник,
1.2.   Эллипс,
1.3.   На основе углов:
1.3.1.   Дуга или Сегмент,
1.3.2.   Сектор,
2.   На основе списка точек:
2.1.   Линия или Полигон,
2.2.   Кривая,
2.3.   Безье,

Фигуры (за исключением прямоугольника и эллипса) могут быть открытыми или закрытыми (флаг Closed).
Все фигуры могут быть или с заливкой или только с окантовкой (флаг Filled).
Если фигура без заливки, то проверка пропадания осуществляется только в окантовку.


   Теперь я хочу перечислить предпринятые действия для того чтобы пользователь мог перемещать вершины кривых линий в пару кликов:
1.   Создал стиль рисования хэндлов HandleVertex.
2.   Сделал отрисовку этого хэндла в буфере LHandleBuffer.
3.   Создал класс LHandleVertex.
4.   Добавил список HandleVertexs в основной класс LShapePolyline.
5.   Создал трекер LUITrackerMoveVertex.
6.   Подключил этот трекер к конфигурации редактора.
7.   Создал команду изменения позиции LCommandMoveVertex для стека отмены.
8.   В классе компонента LShapePolyline реализовал методы UpdateVertexs(), HitTestHandle(), DrawVertexs().
9.   Скорректировал ряд взаимодействий. Исправил ошибки.


   Вопрос о трансформациях. Пока в библиотеке используются только аффинные трансформации. Для реализации прочих трансформаций необходима реализация отрисовки и проверка попадания. Это можно сделать через трансформацию объекта GraphicPath. Тогда первичное формирование, рисование рамки и заполнения, а также проверка попадания, будут использовать стандартную реализацию.
   Здесь следует быть осторожным, поскольку в System.Drawing есть некорректная реализация GraphicPath.AddClosedCurve(). Особенность заключается в том, что неверно вычисляется ограничивающий прямоугольник такой кривой. Поэтому пока от этой функции пришлось отказаться.

[Владимир Липатов]

   При манипуляции линиями, полигонами и кривыми есть одна тонкая проблема. Она заключается в том, что манипуляция с простой аффинной трансформацией такого объекта и манипуляция с его вершинами, приводит к расхождению координат. Об этом стоит сказать чуть подробнее.
   Пусть есть линия, у которой имеется окантовочный прямоугольник Baunds и аффинная трансформация. Пока мы управляем только трансформацией или только вершинами – всё будет нормально. Однако если при манипуляции вершинами изменились границы фигуры, то существующая матрица аффинных преобразований уже не будет соответствовать окантовке этой фигуры.
Что же можно сделать?
Вариантов несколько. Например, можно корректировать трансформацию такого объекта при перемещении вершин. А можно преобразовывать вершины при каждой новой трансформации, сводя её к единичной матрице.
Решение зависит от рода поставленной задачи редактирования.
Оставляю эту проблему в версии 0.8, чтобы можно было посмотреть.


Теперь о том, что пришлось предпринять, чтобы реализовать функционал создания новых фигур:
1.   Создал панель со списком LControlNew, для выбора типа создаваемых компонентов.
2.   Сделал параметрический трекер для создания простых фигур - public class LUITrackerNew<T> : LUITracker where T : LComponent {}.
3.   Подключил панель к редактору и сделал наполнение списка создаваемых фигур через параметрический трекер.
4.   Поправил класс LUIProcessor для установки текущего трекера.
5.   Сделал класс-команду вставки/удаления компонентов LCommandInsertRemove.
6.   Подключил команду к трекеру.

[Вашкевич Виктор]

   [...........]

Программирование настолько иссушает мозг, что в 35 лет надо уходить на пенсию.

Да, это видно и неспециалисту.

[Владимир Липатов]

Да, это видно и неспециалисту.

молодец! классно подъе6ал.

[Вашкевич Виктор]

молодец! классно подъе6ал.

Ну тык. Мозг программированием не иссушен...
Так ты смог из трех возможных траекторий планет СС выбрать одну, истинную?

[Владимир Липатов]

Так ты смог из трех возможных траекторий планет СС выбрать одну, истинную?

Опыт показывает стабильность орбиты.
Однако это не означает что со временем планета никуда не улетит и никуда не упадёт.

[Вашкевич Виктор]

Опыт показывает стабильность орбиты.
Однако это не означает что со временем планета никуда не улетит и никуда не упадёт.

Опыт у тебя неверный.  Спишь там на диване без просыпу.

https://ru.wikipedia.org/wiki/%D0%94%D0%BE%D0%BF%D0%BE%D0%BB%D0%BD%D0%B8%D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%81%D0%B5%D0%BA%D1%83%D0%BD%D0%B4%D0%B0

[zero43]

планета никуда не улетит и никуда не упадёт.

План это земли т.е. глобус никуда не улетит!!!! А вот упасть со стола может.

Опыт показывает стабильность орбиты.

Опыт?!!!!!! Или картинки от имбецылов?
Орбиты?!!!! Но земля летит не по орбите а по спирали.