Последнее время часто слышу мнение, что для современного программиста нужно лишь знание библиотек, да софтскилы - быть не токсичным и не говорить матом. Что касается алгоритмов или понимания как работает операционная система, или прости господи математики - это лишь преграды от старперов-гейткиперов на пути к вожделенной "пилюли от бедности".
Работа программиста в принципе очень простая, всяко проще работы экономиста или юриста. Интеллект и знания нужны минимальные.
Скажу честно, меня такие рассуждения немало задели, поэтому решил написать отдельный пост про рутинную работу программиста на примере своего биржевого проекта.
По современным меркам это обычный пет-проект, который, впрочем, мало кого заинтересует на собеседовании. Что же нужно было знать, что бы его создать.
Во-первых на счет "ненужной математики" - для визуализации применяется линейная алгебра, а именно все те же кватернионы, матрицы, вектора. Нужно понимать что такое матрица, как работает обратная матрица и афинные преобразования. Библиотека для работы с матрицами под js нашлась, но ее тоже пришлось править, т.к. там нашлись ошибки. Далее - для расчета моделей опционов нужны базовые знания статистики (к ней естественно идет диф. исчисление), так пригодилась математика для того, что бы сделать рассчеты оптимального портфеля Марковица.
"Бесполезные алгоритмы" - нужно в реальном времени просчитывать кучу статистики и внезапно потребовались и деревья и хеш-таблицы. Все пришлось рассчитывать в несколько потоков для скорости - а там нужны и примитивы синхронизации вроде спинлока.
Для ускорения отдельный расчётов пришлось делать автогенерацию и компиляцию кода на лету. Источник поставляет данные в древнем DDE - посему пришлось доставать с полки пыльный winapi. Для сбора других данных пришлось написать windows service.
Далее - часть запросов обрабатывалась в памяти, но большая часть на БД. Скорость тут очень важна. А поэтому куча оптимизаций - нужно понимать почему Distinct работает медленней group by, merge - быстрее insert & update, что такое триггеры, секционирование, изоляция транзакций, какие нужны индексы и как оптимизировать хранимые функции.
С другой стороны, для сервисных функций нужно знание ORM и миграций.
Архитектура микросервисная, так что тут понятное дело надо поднять Кафку, но тут все как у всех. Там так же нужен биллинг, взаимодействие с сервисами юмани.
На стороне фронта все по большей части рутинно - кастомные чарты, управление жестами, роутинг, кеширование, мобильная и десктопная версия, в общем стандартный арсенал ангуляра, единственно что - ангуляр не знал и никогда не писал на нем. А надо было фронтэнд переписать с asp.net pages быстро - за пару месяцев. По итогу вышло где то 600 килобайт кода. Т.е. за это время и Ангуляр выучить и код портировать.
Прошу заметить - я никогда не позиционировал себя как крутого программиста. Я — средний, которого не отрывают с руками и который ищет работу на $3000 неделями, пройдя пару десятков собеседований.
Тем не менее, я вообще не уверен, что средний «менеджер по продажам за 30» способен получить тот набор знаний и навыков, что и я. И что работа юриста или экономиста сложнее.
Комментарии (61)
MasterMentor
13.11.2024 17:08Во-первых на счет "ненужной математики" - для визуализации применяется линейная алгебра, а именно все те же кватернионы, матрицы, вектора.
С учётом того, что "пет-проект" выглядит где-то так, "кватернионы", на мой взгляд, там излишни. :))))
Да и "матрицам, векторам" тоже можно было бы найти более достойное применение.
PS Очень нестандартный подход в рамках решаемой задачи. Здесь вполне хватило бы функции "лайн ту" на знаменитом Канвасе. :)
Однако, исходя и Ваших предыдуших статей, складывается впечатление, что умение решать даже, казалось бы, банальные задачи нестандартным путём - это дар настоящего программиста.
artemmoscow Автор
13.11.2024 17:08Не очень понял что вы хотели сказать.. Вы открыли трейдовый график, который даже хваленый трейдинг вью за миллиард не смог сделать.
На нижнем уровне там естественно canvase и lineto. Только перевод из системы координат дата - цена в экранные и наоборот - как по вашему происходит? Как сделаны анимации? Как сделать без матриц управление жестами? Вы обратили внимание, что если на кластерном графике сделать масштабирование колесиком, то приближается именно то место, на котором курсор?
playermet
13.11.2024 17:08Только перевод из системы координат дата - цена в экранные и наоборот - как по вашему происходит?
Парой арифметических операций? График вроде не нужно вращать.
Как сделаны анимации?
Не знаю точно как сделано в продукте выше, но что насчет дергать функции примитивов в tween'ах с easyng'ом?
Как сделать без матриц управление жестами?
В упор не понимаю зачем нужны аж матрицы для жестов. В прошлом был опыт написания игр-квестов для мобильных платформ, где были все жесты которые только можно себе представить, и ни один из них никто не делал матрицами.
Вы обратили внимание, что если на кластерном графике сделать масштабирование колесиком, то приближается именно то место, на котором курсор?
local mousex, mousey = love.mouse.getPosition() local cx = (mousex - view.x) / view.scale local cy = (mousex - view.y) / view.scale -- update scale view.x = mousex - cx * view.scale view.y = mousex - cy * view.scaleartemmoscow Автор
13.11.2024 17:08Если у вас геймдев в бэкграунде, то не понимаю суть вопросов вообще. Вам же известны такие понятия как экранные координаты, мировые координаты, как происходит переход между ними? Это же и есть работа с матрицами. График изначально рисуется в системе координат время - дата. А все манипуляции с графиком - это исключительно изменение системы экранных координат - надо пересчитать матрицу. Соответственно когда вы подводите мышку и хотите узнать информацию по кластеру - вы умножаете вектор мышки на обратную матрицу и получаете из координат мышки дату и цену в одну операцию.
playermet
13.11.2024 17:08Вам же известны такие понятия как экранные координаты, мировые координаты, как происходит переход между ними?
Они известны мне, как писавшему на С++ наш двухмерный игровой движок. Скриптер который делал анимации, жесты, и т.д. даже слова такого как матрица не знал. И это кстати был единственный раз за 15 лет моей жизни с программированием, когда мне нужно было написать умножение матриц в реальной задаче.
А все манипуляции с графиком - это исключительно изменение системы экранных координат - надо пересчитать матрицу.
Не нужны никакие матрицы чтобы график по экрану ворочать, потому что у него из трансформаций только смещений и масштабирование.
вы умножаете вектор мышки на обратную матрицу и получаете из координат мышки дату и цену в одну операцию.
Можете пожалуйста показать ссылой на гитхаб хоть один пример, где в UI без поворота уножают вектор мышки на обратную матрицу? Я такого никогда еще не видел.
artemmoscow Автор
13.11.2024 17:08Это просто говорит о том, что вы не понимаете ни что такое матрицы, ни их физический смысл. Матрица - это система координат. Уножение на матрицу - перевод из одной системы в другую. Вращение, или например отражение - это просто частный случай. То что ваш скриптер не пересчитывал матрицу из жестов - просто значит что это делал кто то другой в команде, или что это было уже зашито в библиотеку.
playermet
13.11.2024 17:08Уножение на матрицу - перевод из одной системы в другую.
Спасибо, кеп. Еще раз, всю математику в нашем движке писал я. А на стороне скриптов были видны только готовые setPosition, setScale, setRotation, и setParent/setChild для иерархии узлов.
То что ваш скриптер не пересчитывал матрицу из жестов - просто значит что это делал кто то другой в команде, или что это было уже зашито в библиотеку.
Никто не пересчитывал матрицу из жестов, потому что код жестов ее не требует. Ниже я привел описание того, как работают жесты, а выше пример кода, который делает масштабирование стабильным к изображению.
artemmoscow Автор
13.11.2024 17:08По жестам - задача сводится к следующему - вы взяли пальцем точку и потянули. По сути вам нужно определить какая матрица нужна что бы умножив вектор на нее получить другой вектор (на самом деле нужно 3 пары векторов, конечно). Не бог весть что, но есть сомнения что понимания как работают матрицы и вектора знает любой слушатель курсов/птушник.
playermet
13.11.2024 17:08По жестам - задача сводится к следующему - вы взяли пальцем точку и потянули. По сути вам нужно определить какая матрица нужна что бы умножив вектор на нее получить другой вектор
Зачем? Я взял одну точку, потянул, а код посмотрел на сколько пикселей сдвинулась координата и ровно на столько же сдвинул объект на экране. Так работает panning. Проверяя область нажатия и скорость точки мы можем делать swipe.
Возьмем пример сложнее. Пользователь использует тачскрин и создает пару нажатий, соответственно мы получаем две точки. По среднешкольной программе используем теорему Пифагора, чтобы понять как изменяется расстояние между точками относительно позиции в начале жеста, и если оно достаточно отличается от порога - делаем scale. За центр масштабирования возьмем геометрическое среднее двух точек, а дальше как в участке кода что я скинул выше. Если этот центр движется по экрану, можем делать альтернативное panning действие, например скроллинг. По среднешкольной же программе мы можем определить и изменение угла отрезка образованного точками по отношению к экрану, и таким образом сделать жест поворот.
Не бог весть что, но есть сомнения что понимания как работают матрицы и вектора знает любой слушатель курсов/птушник.
Линейная алгебра это один из самый лайтовых математических предметов после школьной программы, у нас векторы вообще дали в рамках подготовки к вступительным экзаменам в техникум после 9-го класса, хотя они там были вообще не нужны. Но что важнее, фактически мы наблюдаем что на движке Unity каждый день появляются сотни проектов от школьников (буквально) и любителей, в которых активно применяются и матричные трансформации, и кватернионы, и что-то я сомневаюсь что они во всем этом разбираются. Для них прокинуты готовые функции создающие примитивы трансформаций с человекочитаемым названием, им не нужно знать как это работает под капотом чтобы решать практические задачи.
artemmoscow Автор
13.11.2024 17:08Если бы по отображениям надо было сделать чисто deltaX и deltaY - может быть проще сделать и так. Но нужен был так же scaleX и scaleY. По - конченному было бы в коде везде писать lineto(scalex*x + deletax, scaley*y + deletay), отдельно так же продумывать кейсы с переводом экранных координат в ценовые (что бы показывать хинты и взиамодействовать с графиком), отдельно продумывать код для анимаций и далее возможные кейсы. Зачем, если можно нагуглить готовую библиотеку с матрицами и работать в коде с фактическими координатами, а не экранными, просто переопределив стандартные функции рисования на функции, которые учитывают матрицы?
playermet
13.11.2024 17:08везде писать lineto(scalex*x + deletax, scaley*y + deletay)
А зачем вообще так писать? Зачем вообще использовать голые lineto, без оберток для иерархий виджетов? Код жестов работает так, как я описал выше. После чего готовые параметры смещения, поворота(?) и масштабирования меняются у корневого узла. Дальше зависит от того, что конкретно у нас за окружение. Если это UI в котором поворот невозможен, позиции дочерних элементов обновляются простой арифметикой от родительских на стадии обновления Layout. Если что-то более навороченное или встроенное в игру, то тоже же самое делается уже матрицами. Но ни человек который пишет жесты, ни человек который дергает примитивы и анимации ничего из этого не видит.
отдельно так же продумывать кейсы с переводом экранных координат в ценовые
А как использование матриц от этого освобождает? У нас фактически есть две разные системы координат, необходимость перевода неизбежна. И в обоих случаях он скрыт за вызовом функций.
artemmoscow Автор
13.11.2024 17:08Ну т.е. вы предлагаете сделать тоже самое, но вместо матриц придумывать какую-то на коленке сделанную кривую хрень, просто с целью обойти матрицы? Если матрицы предназначены к переходу между системами координат, зачем придумывать что-то еще?
playermet
13.11.2024 17:08Ну т.е. вы предлагаете сделать тоже самое, но вместо матриц придумывать какую-то на коленке сделанную кривую хрень, просто с целью обойти матрицы?
Во-первых, разговор начался с того что матрицы якобы обязательно нужны человеку который пишет интерфейс, жесты и анимации, когда в действительности матрицы скрыты от него за слоем абстракций, даже когда они действительно есть под капотом.
Во-вторых, вы предлагаете тащить целую библиотеку с тяжеловесными операциями над матрицами только ради масштабирования? Что вы имеете ввиду под "придумывать какую-то на коленке сделанную кривую хрень"? Что там нужно придумывать и что там может быть сделано криво, если там всего пара арифметических операций с тривиальным геометрическим смыслом? Это что, должно быть сложным для понимания программистом, который работает на уровне ниже чем другой программист, от которого вы требуете знать линейную алгебру?
Аналогичный код переписанный под матрицы будет в три раза длиннее, ничуть не более легким для понимания, и работать в десятки раз медленней. Так какие у него преимущества если не требуются другие виды трансформаций? Только галочка что мы используем матрицы?
artemmoscow Автор
13.11.2024 17:08Вы мелете что попало, совршенно очевидно, что то что вы работали в геймдеве - ложь. Библиотека с матрицами не тяжеловесна, там пару сотен строк кода. Я за день сам бы написал. По производительности будет так же. Херь которую вы пишите - дескать надо в ручную обрабатывать каждый кейс, вместо того что бы использовать простую, понятную и широкоиспользуемую концепцию системы координат вообще не ясно как комментировать. Например, если нужно добавить анимацию, то я просто вызываю функцию интерполяции матриц, если не использовать абстракцию с системами координат это нужно лопатить весь код. И для чего? Якобы что бы ПТУшник разобрался? Может проще ПТУшнику открыть учебник по линейке и за вечер все выучить?
playermet
13.11.2024 17:08Библиотека с матрицами не тяжеловесна, там пару сотен строк кода
Речь не о тяжеловесности библиотеки (хотя в реальной библиотеке, той же glm далеко не 200 строк кода). Речь о тяжеловестности умножения матриц в сравнении с парой арифметических операций. Которая может быть и не заметна на конкретном числе элементом, но зачем лишний раз греть воздух?
Херь которую вы пишите - дескать надо в ручную обрабатывать каждый кейс, вместо того что бы использовать
В который раз спрашиваю. Какой конкретно кейс нужно обрабатывать, который не придется обрабатывать в случае с матрицами?
Например, если нужно добавить анимацию, то я просто вызываю функцию интерполяции матриц
Я просто вызываю функцию интерполяции координат.
если не использовать абстракцию с системами координат это нужно лопатить весь код
Что конкретно нужно лопатить и зачем? Почему мы ничего не лопатили?
Якобы что бы ПТУшник разобрался?
Во-первых, ПТУшники которые не забивали на пары прекрасно понимают ЛА, это одна из первых тем проходимых после школьной математики. Во-вторых, почему я не вижу в CSS повсеместного использования матриц для смещений и масштабирований? Почему я не вижу их повсеместного использования в клиентском интерфейсе в популярных и не очень фреймворках UI? Еще раз прошу, покажите ссылкой на гитхаб где оно так сделано.
artemmoscow Автор
13.11.2024 17:08Вы реально знаете линейку? Что там тяжеловесного в умножении координат на матрицу? В любом случае в коде будет уножение и сдвиг. Вообще, что может быть проще формулы x' = sx*x+ dx , что тут вообще можно оптимизировать? Интерполяция координат, что это вообще за хрень?
Если вы работали в геймдеве, для вас должно было быть логичным наличие 3 систем координат - локальная, мировая, камера. Это используется повсеместно, я не буду лопатить гитхаб, это в любом учебнике.
Почему не сделано в css? понятия не имею, возможно там и матрицы есть. но в целом он на дизайнеров рассчитан, которые слабо дружат с линейкой.
playermet
13.11.2024 17:08что там тяжеловесного в умножении координат на матрицу?
Сначала вы создаете матрицу, в некоторых языках это гарантированно объект в куче. Затем вы инициализируете эту матрицу, устанавливая в нее координаты. Затем вы берете матрицу трансформации (в худшем случае ее вы тоже создаете). А затем в функции умножения матриц вызывается в сумме за сотню умножений и сложений (в С/С++ либе там скорее всего будут вызовы SSE). И только затем примитив получает конкретные координаты в которых его нужно рисовать. И это противопоставляется нескольким арифметическим операциям и присваиванию, вообще не трогая кучу.
Вообще, что может быть проще формулы x' = sx*x+ dx
А кто сказал что нам нужно что-то проще этой формулы?
Если вы работали в геймдеве, для вас должно было быть логичным наличие 3 систем координат - локальная, мировая, камера
Какое это все имеет отношение к человеку который пишет жесты/анимации в двухмерном UI где из трансформаций смещение да масштаб?
это в любом учебнике
В каком конкретно учебнике советуют в продакшен коде использовать матрицы для жестов в тривиальном UI? Я открою, посмотрю, и скажу что вы были правы, только назовите.
Интерполяция координат, что это вообще за хрень?
Интерполяцию можно хоть между двумя числами провести, в чем претензия конкретно?
но в целом он на дизайнеров рассчитан, которые слабо дружат с линейкой
А на кого должна быть расчитана верстка интерфейсов, и зачем там нужны матрицы на клиентской стороне если все типичные случаи прекрасно выполняются без них? Назовите хотя бы одно конкретно преимущество, если вместо координат и высоты с шириной заставить всех верстальщиков явно работать с матрицами. Хотя бы одно.
artemmoscow Автор
13.11.2024 17:08Ну смотрите. Я присобачил к canvas матрицу и написал несколько примитивов, которые с ним работают, которые внутри выглядят как x' = sx*x+ dx y' = sy*y+ dy . Верно было написано что лучше бы использовать матриц самого canvas, но к моей задаче это не подошло, по сути слегка продублировал код. Вы пишите что это оверкил и слишком сложно. И что вместо реализации одной операции умножения матрицу на вектор надо было "просто отдельно сделать скейлинг, жесты, перемещение, растяжение по обоим осям, анимацию и так же отдельно написать функции просчета экранных координат в логические". Так что интересно посмотрить что может быть проще нескольких десятков строк кода и отображение в разных позициях без изменения самих координат.
playermet
13.11.2024 17:08Я присобачил к canvas матрицу и написал несколько примитивов, которые с ним работают, которые внутри выглядят как x' = sx*x+ dx y' = sy*y+ dy
У меня есть реализация UI на Lua, в которой я не собачил матрицу, но у меня есть несколько примитивов, которые внутри выглядят точно так же. Так зачем мне там матрица?
Вы пишите что это оверкил и слишком сложно.
Процитируете конкретный абзац? Особенно интересует словосочетание "слишком сложно".
И что вместо реализации одной операции умножения матрицу на вектор надо было "просто отдельно сделать скейлинг, жесты, перемещение, растяжение по обоим осям, анимацию и так же отдельно написать функции просчета экранных координат в логические"
Хотел бы я посмотреть как одна операция умножения матриц выполняет вам все вышеперечисленное. И от системы вам координаты тачей уже конвертированными приходят?
У вас объективно в UI существует система координат отмасштабированного виджета и экранная. Везде где проходит между ними граница требуется преобразование. Везде это будет вызовом какой-то функций, явно или неявно с клиентской стороны. Под капотом у этой могут быть матрицы, а могут и не быть.
artemmoscow Автор
13.11.2024 17:08У меня есть реализация UI на Lua, в которой я не собачил матрицу, но у меня есть несколько примитивов, которые внутри выглядят точно так же. Так зачем мне там матрица?Ну вообще то эти коэффициенты abc/def x' = ax+bx+c y'=dx+ex+f по сути и есть та самая матрица. Вместо того, что бы применять простую и понятную (для тех кто понимает линейку) матричную арифметику для рассчета abc/def вы изобретали свой велосипед что по сути есть говнокод
playermet
13.11.2024 17:08Т.е вы утверждаете, что даже для знающего ЛА программисту две арифметические операции будут менее понятны, читаемы и надежны чем постоянное создание матриц трансформации с последующим умножением? А вы когда два числа складываете, пишете
a+bилиimport sum = package.trash.sum ... sum(a, b)?
playermet
13.11.2024 17:08Этот код менее читабельный чем
root:move(dx, dy);, илиroot.x += dx; root.y += dy;, ну или еще какой-нибудь вариации аналогичной записи.Встречный вопрос. Почему передача дельт в матрицу трансформации смещения с последующей передачей в функцию умножения это стильно-модно-моложежно, а то же самое выполненное для вектора или пары чисел парой арифметических операторов это "придуманная какая-то на коленке сделанная кривая хрень".
artemmoscow Автор
13.11.2024 17:08Про матрицу в куче - отдельный лулз. Т.е. это пипец какая нагрузка на систему, хранить в памяти 9 даблов?
playermet
13.11.2024 17:08Т.е. это пипец какая нагрузка на систему, хранить в памяти 9 даблов?
Во-первых, не 9 а 16, т.к. на 9 не везде есть (хотя чего я, вместо " придуманная какая-то на коленке сделанная кривая хрень" тут возникнет "божественная 100% coverage state-of-art высокопроизводительная hand-made библиотека матриц 3х3 на 200 строчек". Во-вторых вопрос не в том, чтобы ее хранить. Вопрос в том что на UI с большим числом элементов может срать десятками тысяч объектов ежесекундно, а потом GC должен все это собирать.
artemmoscow Автор
13.11.2024 17:0816 это для 3д, для 2д нужно 9
вы уверены что хоть что то понимаете в графике? Матрица не нужна для каждого элемента. Она одна на весь канвас.
playermet
13.11.2024 17:0816 это для 3д
Я выше расписал подробней.
Матрица не нужна для каждого элемента.
Ну, если у вас масштабировать можно либо весь канвас - либо вообще ничего, тогда да. И тогда втройне не понятно зачем вам вообще нужна матрица.
artemmoscow Автор
13.11.2024 17:08Если не понятно зачем нужны матрицы в компьютерной графике, откройте учебник
playermet
13.11.2024 17:08откройте учебник
В учебнике будет сказано что матрицы удобны потому что они позволяют объединять множество разных трансформаций (и не будет сказано, что на практике это может применяться для целой иерархии объектов). В описанном вами случае иерархии нет вообще, а из трансформаций доступны только две самые тривиальные, ровно по одному разу каждая, и выполняемые одним сложением и одним умножением. Никакого преимущества от свойств матриц вы не получили.
artemmoscow Автор
13.11.2024 17:08матрицы удобны тем, что это арифметика над проекциями систем координат. Манипуляции с отображением - это как раз и есть матричная арифметика. Вы двигаете не объекты, а само отображение, например вам нужно сделать отображение за январь так, что бы была центровка по высоте, а по экране занимало ровно ширину. В логике матриц это одно действие - вы высчитваете проекционную матрицу одного треугольника на другой и делаете ее отображаемой. Не говоря о том, что скроллирование, масштабирование и анимация - это и есть та самая "иерархия". Но я вижу что вы вообще в принципе не понимаете что я пишу. В свое библиотеке вы просто скопипастили код и для вас матрицы - это то, что нужно для того что бы "вращать", вы выше писали дичь, что матрца нужна для каждого элемента
playermet
13.11.2024 17:08матрицы удобны тем, что это арифметика над проекциями систем координат
Это не преимущество, это описание того чем оно является. Программисту интерфейса не нужна арифметика над проекциями систем координат, ему нужно решать практическую бизнес-задачу.
Вы двигаете не объекты, а само отображение
А по задаче нужно двигать объекты. Один раз отмасштабировать и один раз сместить.
В логике матриц это одно действие
А в реальном коде это не одно действие, потому что этому предшествует "вы высчитваете проекционную матрицу". Причем т.к. матрица вида у вас ровно одна, вы делаете это ровно один раз. Так же как сделали бы это ровно один раз без матриц, только вместо каждого создания матрицы трансформации и матричного умножения у вас был бы один оператор над парой чисел. В вашем случае нет ни единого реального преимущества применения матриц. Ну, кроме того что вы самоутвердились поплевав в воображаемого ПТУшника который это якобы не способен осилить.
Не говоря о том, что скроллирование, масштабирование и анимация - это и есть та самая "иерархия"
Это лишь последовательность трансформаций для одного объекта. А речь идет о иерархии узлов. Которая есть почти в любом игровом движке, которая есть в любом UI фреймворке, которая представлена DOM-омом в браузере, и которая само собой была в нашем движке. Потому что двигая панель нужно чтобы дочерние виждеты двигались с ней, а двигая танк за ним следовала и башня, зачастую с глубокой вложенностью и кастомно заданными осями трансформаций. Вот здесь как раз и возникают все преимущества применения матриц.
вы выше писали дичь, что матрца нужна для каждого элемента
Если она не нужна в вашем проекте, это не значит что она не нужна остальным. В данном случае я бы даже сказал что вы в меньшинстве.
для вас матрицы - это то, что нужно для того что бы "вращать"
Опять лжете.
artemmoscow Автор
13.11.2024 17:08В первую очередь лжете вы, что у вас есть хотя бы элементарное понимание предмета. Ну давайте, посчитайте коэффициенты в формуле отображения x' = sx*x+ dx y' = sy*y+ dy в одно действие. экранные координаты - x,y,w,h, и соотвественно логические - {column1,price1,colum2,price2} . При этом конечно же логические координаты направленны вверх, а экранные, как известно вниз. Покажите то простое арифметическое действие, которое посчитает, заодно узнаем кто лжец. В матрицах для этого достаточно вызывать одну библиотечную функцию
playermet
13.11.2024 17:08Ну давайте, посчитайте коэффициенты в формуле отображения x' = sx*x+ dx y' = sy*y+ dy в одно действие
Попробуйте внимательней читать что вам пишут. Применению каждой отдельной трансформации будет соответствовать одна арифметическая операция, а не одна арифметическая операция вообще на все.
Вам нужно отражение по оси? С матрицами это создание матрицы с последующим умножением, без матриц это смена знака. Вам нужно смещение? С матрицами это создание матрицы с последующим умножением, без матриц это сложение. Вам нужно масштабирование? С матрицами это создание матрицы с последующим умножением, без матриц это умножение. А никаких других трансформаций в нашем случае быть не может, только последователность перечисленных. Мы можем работать с координатами по отдельности, и тогда у нас будет две строки, где каждая операция выполнена и для x и для y, а можем с векторами, и тогда строка будет всего одна.
Причем так же как любую последовательность трансформаций смещений и масштабирований можно представить одной матрицей трансформации, эту же последовательность трансформаций можно свести в один набор (dx, dy, sx, sy). И то и другое в итоге придется применить к паре координат, чтобы перевести их из одной системы в другую.
При этом конечно же логические координаты направленны вверх, а экранные, как известно вниз
В разных движках и графических API координаты могут иметь разную направленность. В OpenGL ось y направлена вверх, в DirectX она направлена вниз.
В матрицах для этого достаточно вызывать одну библиотечную функцию
Даже в строке которую вы привели выше больше одного вызова функции, а она только применяет одно смещение. А программисту интерфейсов и жестов в любом случае нужно будет вызывать готовые библиотечные функции, что с матрицами под капотом, что без. Хотя у вас и это видимо не так.
artemmoscow Автор
13.11.2024 17:08
Вылядит просто и естественно, но для того, что бы масштабировать график из любой точки экрана нужно знание линейной алгебры.
Fedorkov
13.11.2024 17:08Я в одном пет-проекте сделал это
не приходя в сознаниене вспоминая про линейную алгебру.artemmoscow Автор
13.11.2024 17:08Посмотрел ваш код, там ожидаемо чепуха. Есть какая-то левая сущность - центр экрана и масштаб. Зачем это, зачем кому то лезть в ваш полет фантазии? Кода есть абстракция - система координат экранная и смысловая. Хочешь переместить - умножил на матрицу перемещения. Хочешь отскейлить - на матрицу скейлинга. Просто, понятно и прозрачно. Поддерживаемый код - это не код, который может понять ПТУшник, а код, который легко расширять и править.
MasterMentor
13.11.2024 17:08По-моему Вы привели пример классического overhead. Для указанных задач достаточно одной функции setTransform() знаменитого Канваса. А вместе с save()/restore() она вообще может творить чудеса. :)
Как известно талантливый человек - талантлив во всём. Здесь Вы совершили маленькое открытие в математике:
Матрица - это система координат. (с)
и далее там идут не менее смелые рассуждения.
PS
Вы открыли трейдовый график, который даже хваленый трейдинг вью за миллиард не смог сделать.
Он то не смог. Но хорошо, что оупенсор есть, и что не смог TW - смогли опэнэнтузиасты.
Открытых UI библиотек для трейдинга - туча+. И готовые трейдинговые платформы есть - с мегаграфиками и тучей прибумбасов. :)
Проект из 2016-го https://github.com/MKwenhua/real-time-charts
artemmoscow Автор
13.11.2024 17:08какой вы молодец. А ничего что setTransform и ширину линий и шрифт скейлит, а мне это не нужно.
По поводу критики моего проекта. Не пойму, это что, классовая ненависть? Откуда любовь к работягам и ненавись к мелким предпринемателям, людям которые пытаются куда-то двигаться? Лучше сидеть на попе и завидовать зарплате в 3 штуки, чем пытаться получить больше?
Как бы то ни было порядка 10000 подиписок у меня купили. Можете дальше бегать по интернету и кричать что пытаться запустить свой проект не стоит, надо идти на стройку.
MasterMentor
13.11.2024 17:08А что это Вы на личности переходите? И к чему сверху упортеблять слово gopa?! Не комильфо это.
Я не критикую, я - предлагаю. Как к примеру, я бы реализовывал такой проект следующим образом: для начала поискал бы готовые решения в оупенсоре, чем не альтернатива?!
artemmoscow Автор
13.11.2024 17:08Мы уже с вами обсуждали, проект стартовал в 11 году, вы приводите примеры из 16 года, к тому же сомневаюсь что релевантные задачи
oracle_schwerpunkte
13.11.2024 17:08Тем не менее, я вообще не уверен, что средний «менеджер по продажам за 30» способен получить тот >набор знаний и навыков, что и я. И что работа юриста или экономиста сложнее.
Судя по тому, что автор пытается заработать на программе (продает лопаты), а не сконцентрирован исключительно на фондовом рынке, работу трейдера - экономиста он осилить не смог, несмотря на матрицы, матан и зашкаливающее самомнение.artemmoscow Автор
13.11.2024 17:08Трейдинг не имеет отношения к экономике.
MasterMentor
13.11.2024 17:08Но имеет отношение к умениям и сообразительности. N'est-ce-pas?
...мы же вроде не экономику здесь обсуждаем.
MasterMentor
13.11.2024 17:08Друг, мой, глядя на то как в процессе общения с Вами тает Моя карма, я было влепил и Вам минус. Но взвесив всё, великодушно вернул плюс обратно. Будет жалко если Вас выпилят с Хабра. Вы хоть и своеобразный, но не плохой человек, а разнообразие - это хорошо.
artemmoscow Автор
13.11.2024 17:08Боже мой, какой подарок с вашей стороны! В начале вы в друзья набиваетесь, потом когда я попросил конерктики, начали как отвергнутая женщина бегать за мной и потихоньку гадить в коментах. И проекты у меня говно, и программист я никакущий и вообще талантливый человек талантлив во всем. Ставьте уже свой минус, я уверен что вы давно его поставили.
MasterMentor
13.11.2024 17:08Друг мой, в друзья не "набиваются", но (!) дружбу предлагают. :)
Как говорят у нас в Одессе: это две большие разницы. :)
artemmoscow Автор
13.11.2024 17:08Во первых "дружбу не объявляют". Во вторых ваши действия явно враждебные, с таким человеком нет желания общаться. Вы обвиняете меня в негативе, но я просто лапочка по сравнению с вами.
MasterMentor
13.11.2024 17:08Что до Ваших проектов и Ваших программистских умений - ни разу не писал того, что Вы говорите (перечитайте внимательно все комментарии). Просто указывал, что, на мой взгляд, есть разумные альтернативы.
К примеру, для задачи масштабирования таблиц и графиков, как Вы указываете в статье, Вы применили аппарат кватернионов. Можно ли так делать? Конечно. Никто ж не запрещает.
Мало того, это можно и в тензорной алгебре сделать.
А уж если размахнуться - то и через Биангулярные, и Биполярные, и Конические координаты или даже через Координаты Риндлера (см https://ru.wikipedia.org/wiki/Система_координат#Другие_распространённые_системы_координат )
Просто по моему скромному мнению, для данной задачи это overhead.
А биполярные координаты выглядят заманчиво и эстетично. :)
artemmoscow Автор
13.11.2024 17:08Кватерионы в данном случае для красного словца, непосредственно в этом коде они не использовались, но понимание сути кватернионов помогает пониманию сути матриц, скорее это я имел в виду.
Что прям оверкил в абстракции системы координат - ума не приложу. Это вообще вещь по умолчанию, как вы сами написали она непосредственно в canvas встроена, но мне пришлось написать свою, т.к. она масштабировала ширину линий, а мне это не нужно.
В данном случае код максимально тривиальный, важнее было понимание самой линейной алгебры.
MasterMentor
13.11.2024 17:08Вы иногда пишете дельные мыли, но не всегда точно.
С Вашего разрешения, слегка уточню это Ваше высказываение:
В данном случае код максимально тривиальный, важнее было понимание самой линейной алгебры.
В данном случае вы получили полезный опыт работы и понимание векторной алгебры, но не линейной. "Линейная алгебра" - это немного другое:
попробуйте в "линейной алгебе" сложить вектора либо числа. Это невозможно: хоть есть много книг по "линейной алгебре", самой "линейной алгебры" нет. И вектор, и число - складывают в собственной алгебре, а "линейная алгебра" - это надстройка над множеством алгебр; конструкция, в которой операции объявлены, но не определены (на этом строится данное обобщение). Суть - охарактеризовать свойства операций алгебраических систем, попадающих в категорию "линейных". То есть установить их некоторое общее поведение (аналог в программировании: базовый класс со списком функций, которые не определены, но заданы некоторые их свойства, например арность, и классы-реализаторы (наследники) каждый по-своему реализующий эти функции).
MasterMentor, О математической строгости https://habr.com/ru/articles/821319/comments/#comment_26940975
Согласитесь, приятней читать текст, в чуть более строгих терминах.
artemmoscow Автор
13.11.2024 17:08Посмотрите по ссылке ниже Vectors | Chapter 1, Essence of linear algebra
Линейка - это устоявшийся термин
Вообще, если бы вам так хотелось меня уесть и показать класс, вы бы могли упомянуть, к примеру, к какой группе симметрии относятся кватернионы.
А так пока что выглядит слабенько. В теме трейдинга и бизнеса вы валите в кучу сам трейдинг, брокерские и консультационные услуги. В плане возможностей трейдерского ПО - вы просто не знаете и не понимаете его функционал. В плане практического программирования - пытаетесь умничать по поводу возможностей canvas - но тоже выглядит слабо.
MasterMentor
13.11.2024 17:08Кватерионы в данном случае для красного словца, непосредственно в этом коде они не использовались
...а тогда всё понятно.
Но здесь мы поднимаем вопрос где уместно использовтаь "красное словцо", а где - нет.
К примеру, скажи Вы такое на техническом собеседовании в условый Яндекс... Согласитесь, случится конфуз! Там очень удивятся и врядли будут рады такому решению.
В повседневной жизни "красным словцом" тоже не следует злоупортеблять: можно прослыть "краснобаем". А вот в художественном творчестве - это только пожалуйста. :)
artemmoscow Автор
13.11.2024 17:08Мне кватернионы и комплексные числа помогли понять суть матриц. На счет краснобая - ну не уверен. Чуть выше отписался персонаж, который не мало не стесняясь написал что он эксперт в матрицах, при ближайшем рассмотрении начал писать дичь, что дескать матрицы нужны только для вращения и не понятно зачем умножать матрицы друг на друга перед преобразованием.
playermet
13.11.2024 17:08не стесняясь написал что он эксперт в матрицах
Процитируете?
дескать матрицы нужны только для вращения
Вы уже откровенно лжете.
не понятно зачем умножать матрицы друг на друга перед преобразованием
И тут тоже лжете.
artemmoscow Автор
13.11.2024 17:08Вы писали что вы сами писали матричные библиотеки, и что не понимаете зачем использовать матрицы в проекте, где нет вращения. Это цитата.
playermet
13.11.2024 17:08Вы писали что вы сами писали матричные библиотеки
Да, писал. А вы писали какой-то интерфейсный код. Это значит что вы писали что позиционируете себя как эксперт в написании интерфейсов?
не понимаете зачем использовать матрицы в проекте, где нет вращения
Это утверждение не совпадает по смыслу с утверждением которое вы приписываете мне выше. И даже не полностью совпадает по смыслу с моим реальным утверждением. Чтобы вы не утруждались, я даже скомпилирую свою предыдущие утверждения в одно прямо здесь: матрицы не нужно использовать в проекте, в котором есть ровно одно линейное смещение и ровно одно линейное масштабирование, если только это не продиктовано ограничением инструмента разработки.
Это цитата.
Нет, это не цитата.
artemmoscow Автор
13.11.2024 17:08Если что, мне в свое время этот курс помог здорово упорядочить в голове понимание линейки
HEXFFFFFFFF
Безусловно знаний библиотек абсолютно недостаточно, то что под вашу задачу есть уже кем то написанная библиотека я бы оценил в 50%, а то что она будет кореектно работать без правок в 10%. При чем правка чужой библиотеки под себя требует больше знаний чем написание своей.
Программистов знания которых ограничиваются подключением библиотек уже в ближайшее время заменит ИИ, и они останутся без работы. А вот нормальных программистов ИИ не заменит ни когда, хотя очень ускорит и упростит им работу.
anonymous
НЛО прилетело и опубликовало эту надпись здесь