Замечу что стандарты именно LeetCode на большинстве задач тоже очень мягкие: вы можете написать сильно неоптимальный код и он всё ещё впишется в ограничения
Не знаю, пробовал недавно решать задачи на LeetCode, и алгоритмы с асимптотикой хуже оптимальной почти всегда проваливают тест. Прокатывало только с easy-задачами, где изначально требовалось что-то простое. Ну и еще в конце показываеся рейтиг решений по времени исполнения, что мотивирует переписывать решение по нескольку раз, чтобы попасть в самый топ.
Конкретно жертвы клофелинщиков умирают от неверно подобранной дозы или каких-то индивидуальных особенностей и обстоятельств. Поэтому то и нужен целый анастезиолог, чтобы все это учитывать и высчитывать.
Ну, кэши, предказатели и OoO исполнение появились достаточно давно, так что научиться работать с ними не так сложно
Смысл не в том, что этому сложно учиться. А в том что на старых процессорах об этом вообще не нужно думать как о факторе на что-то влияющем. На современном процессоре легко написать структуру данных или алгоритм, которая ассимптотически (и числом операций) намного лучше, а фактически производительность такая же или медленней (на этом моменте Александреску шутит про выкидывание книг). На старом процессоре код выполняется ровно сколько времени, сколько занимают в сумме его отдельные операции. И о расположении данных в памяти не нужно думать, кроме как чисто в контексте удобства и решении задачи.
Если получилось написать код чтобы было меньше операций или столько же но более дешевых - поздравляем, ваш код стал быстрее. А теперь сравним это с задачами литкода, где в рейтинге времени выполнения вторые места (5ms) отделяет от первого (<1 ms) переписывание одного и того же по смыслу, пока у компилятора не щелкнет озарение. Без бенчмарка понять стал код быстрее или медленней очень сложно.
Я считаю что программисты прошлого было более приспособлены к экстремальным условиям работы
Кроме неудобного инструментария у них были и противоположные факторы. Некоторые я прочувствовал на себе, когда попробовал писать код для Motorola 68000 для Sega Mega Drive. Например, ограниченные возможности машины на корню режут количество и размах хотелок. Или отсутствие гадания как это будет работать на машине - кеша нет, предсказателя ветвлений нет, скорость чтения из ROM равна скорости чтения из RAM. Целый пласт современных метаний с учетом всех этих деталей просто отсутствует как категория. Не нужно думать о сожительстве с ОС и другими приложениями. Не нужно думать о многопоточности (хотя у SMD есть отдельный процессор для управления звуком). И при этом решение многих обыденных современных задач в ограниченных ресурсах становится очень интересным. Мозг полностью занят непосредственно алгоритмами и всякими хардварными уловками.
К слову, вот что про подобную ситуацию думает сам создатель принципов SOLID:
When you really look closely at the practice of programming computers, you realize that very little has changed in 50 years. The languages have gotten a little better. The tools have gotten fantastically better. But the basic building blocks of a computer program have not changed.
If I took a computer programmer from 1966 forward in time to 2016 and put her in front of my MacBook running IntelliJ and showed her Java, she might need 24 hours to recover from the shock. But then she would be able to write the code. Java just isn’t that different from C, or even from Fortran.
And if I transported you back to 1966 and showed you how to write and edit PDP-8 code by punching paper tape on a 10 character per second teletype, you might need 24 hours to recover from the disappointment. But then you would be able to write the code. The code just hasn’t changed that much.
Younger programmers might think this is nonsense. They might insist that everything is new and different nowadays, that the rules of the past are past and gone. If that is what they think, they are sadly mistaken. The rules have not changed. Despite all the new languages, and all the new frameworks, and all the paradigms, the rules are the same now as they were when Alan Turing wrote the first machine code in 1946.
Будет работать, за счет закона квадрата куба. В позапрошлом веке лед кубиками нарезали и прямо так кораблях развозили на пол планеты, а потом до конечного потребителя на деревянной тележке везли, летом. Потери льда при этом довели до всего 20-50%.
Пока эта махина песка со сторонами 10+ метров сама хоть немного остынет, ее уже израсходуют и заново нагреют.
Разница с литий-ионными батареями на единицу объема всего в 2-3 раза примерно. Но для батарей нужны дорогие материалы, сложные производства, плюс нагрев и пожароопасность, плюс деградация емкости со временем, да и сплошняком по объему их не поставишь. А тут набрал песка в любой объем/любую форму и он лежит себе хоть тысячу лет, только ТЭНы с трубами меняй, да за корпусом следи. Причем греть по идее можно и сильнее, чем до 400 градусов (проблема как я понимаю в съеме энергии), а батареи уже близки к пределам возможностей. Тут как не оптимизируй, а теплоаккумуляторы на песке всегда проще и дешевле на единицу энергии будут.
Чтобы протопить городскую квартиру современной дровяной системой с теплоаккумулятором, достаточно раз в день закинуть в топку 1-2 охапки дров.
В нашем подъезде у всех отопление на газовых котлах. Чтобы протопить свою квартиру нужно включить его осенью и выключить весной. Ну и у кого бачок открытый, раз в неделю стакан воды доливать.
Ну давайте, посчитайте коэффициенты в формуле отображения x' = sx*x+ dx y' = sy*y+ dy в одно действие
Попробуйте внимательней читать что вам пишут. Применению каждой отдельной трансформации будет соответствовать одна арифметическая операция, а не одна арифметическая операция вообще на все.
Вам нужно отражение по оси? С матрицами это создание матрицы с последующим умножением, без матриц это смена знака. Вам нужно смещение? С матрицами это создание матрицы с последующим умножением, без матриц это сложение. Вам нужно масштабирование? С матрицами это создание матрицы с последующим умножением, без матриц это умножение. А никаких других трансформаций в нашем случае быть не может, только последователность перечисленных. Мы можем работать с координатами по отдельности, и тогда у нас будет две строки, где каждая операция выполнена и для x и для y, а можем с векторами, и тогда строка будет всего одна.
Причем так же как любую последовательность трансформаций смещений и масштабирований можно представить одной матрицей трансформации, эту же последовательность трансформаций можно свести в один набор (dx, dy, sx, sy). И то и другое в итоге придется применить к паре координат, чтобы перевести их из одной системы в другую.
При этом конечно же логические координаты направленны вверх, а экранные, как известно вниз
В разных движках и графических API координаты могут иметь разную направленность. В OpenGL ось y направлена вверх, в DirectX она направлена вниз.
В матрицах для этого достаточно вызывать одну библиотечную функцию
Даже в строке которую вы привели выше больше одного вызова функции, а она только применяет одно смещение. А программисту интерфейсов и жестов в любом случае нужно будет вызывать готовые библиотечные функции, что с матрицами под капотом, что без. Хотя у вас и это видимо не так.
Да, писал. А вы писали какой-то интерфейсный код. Это значит что вы писали что позиционируете себя как эксперт в написании интерфейсов?
не понимаете зачем использовать матрицы в проекте, где нет вращения
Это утверждение не совпадает по смыслу с утверждением которое вы приписываете мне выше. И даже не полностью совпадает по смыслу с моим реальным утверждением. Чтобы вы не утруждались, я даже скомпилирую свою предыдущие утверждения в одно прямо здесь: матрицы не нужно использовать в проекте, в котором есть ровно одно линейное смещение и ровно одно линейное масштабирование, если только это не продиктовано ограничением инструмента разработки.
матрицы удобны тем, что это арифметика над проекциями систем координат
Это не преимущество, это описание того чем оно является. Программисту интерфейса не нужна арифметика над проекциями систем координат, ему нужно решать практическую бизнес-задачу.
Вы двигаете не объекты, а само отображение
А по задаче нужно двигать объекты. Один раз отмасштабировать и один раз сместить.
В логике матриц это одно действие
А в реальном коде это не одно действие, потому что этому предшествует "вы высчитваете проекционную матрицу". Причем т.к. матрица вида у вас ровно одна, вы делаете это ровно один раз. Так же как сделали бы это ровно один раз без матриц, только вместо каждого создания матрицы трансформации и матричного умножения у вас был бы один оператор над парой чисел. В вашем случае нет ни единого реального преимущества применения матриц. Ну, кроме того что вы самоутвердились поплевав в воображаемого ПТУшника который это якобы не способен осилить.
Не говоря о том, что скроллирование, масштабирование и анимация - это и есть та самая "иерархия"
Это лишь последовательность трансформаций для одного объекта. А речь идет о иерархии узлов. Которая есть почти в любом игровом движке, которая есть в любом UI фреймворке, которая представлена DOM-омом в браузере, и которая само собой была в нашем движке. Потому что двигая панель нужно чтобы дочерние виждеты двигались с ней, а двигая танк за ним следовала и башня, зачастую с глубокой вложенностью и кастомно заданными осями трансформаций. Вот здесь как раз и возникают все преимущества применения матриц.
вы выше писали дичь, что матрца нужна для каждого элемента
Если она не нужна в вашем проекте, это не значит что она не нужна остальным. В данном случае я бы даже сказал что вы в меньшинстве.
для вас матрицы - это то, что нужно для того что бы "вращать"
В учебнике будет сказано что матрицы удобны потому что они позволяют объединять множество разных трансформаций (и не будет сказано, что на практике это может применяться для целой иерархии объектов). В описанном вами случае иерархии нет вообще, а из трансформаций доступны только две самые тривиальные, ровно по одному разу каждая, и выполняемые одним сложением и одним умножением. Никакого преимущества от свойств матриц вы не получили.
Этот код менее читабельный чемroot:move(dx, dy); , или root.x += dx; root.y += dy; , ну или еще какой-нибудь вариации аналогичной записи.
Встречный вопрос. Почему передача дельт в матрицу трансформации смещения с последующей передачей в функцию умножения это стильно-модно-моложежно, а то же самое выполненное для вектора или пары чисел парой арифметических операторов это "придуманная какая-то на коленке сделанная кривая хрень".
Т.е вы утверждаете, что даже для знающего ЛА программисту две арифметические операции будут менее понятны, читаемы и надежны чем постоянное создание матриц трансформации с последующим умножением? А вы когда два числа складываете, пишете a+b или import sum = package.trash.sum ... sum(a, b)?
Отсеяли тех, кто не хочет врать о своих настоящих навыках в принципе, даже в резюме.
Не знаю, пробовал недавно решать задачи на LeetCode, и алгоритмы с асимптотикой хуже оптимальной почти всегда проваливают тест. Прокатывало только с easy-задачами, где изначально требовалось что-то простое. Ну и еще в конце показываеся рейтиг решений по времени исполнения, что мотивирует переписывать решение по нескольку раз, чтобы попасть в самый топ.
Это еще лайтово. Замечательная паста по этому поводу.
Подвох будет, если использовать
NOT IN, потому чтоNOT(NULL)дастNULL. С простоINподвоха не будет.Конкретно жертвы клофелинщиков умирают от неверно подобранной дозы или каких-то индивидуальных особенностей и обстоятельств. Поэтому то и нужен целый анастезиолог, чтобы все это учитывать и высчитывать.
А жертвы клофелинщиков тоже время от времени умирают.
Смысл не в том, что этому сложно учиться. А в том что на старых процессорах об этом вообще не нужно думать как о факторе на что-то влияющем. На современном процессоре легко написать структуру данных или алгоритм, которая ассимптотически (и числом операций) намного лучше, а фактически производительность такая же или медленней (на этом моменте Александреску шутит про выкидывание книг). На старом процессоре код выполняется ровно сколько времени, сколько занимают в сумме его отдельные операции. И о расположении данных в памяти не нужно думать, кроме как чисто в контексте удобства и решении задачи.
Если получилось написать код чтобы было меньше операций или столько же но более дешевых - поздравляем, ваш код стал быстрее. А теперь сравним это с задачами литкода, где в рейтинге времени выполнения вторые места (5ms) отделяет от первого (<1 ms) переписывание одного и того же по смыслу, пока у компилятора не щелкнет озарение. Без бенчмарка понять стал код быстрее или медленней очень сложно.
Кроме неудобного инструментария у них были и противоположные факторы. Некоторые я прочувствовал на себе, когда попробовал писать код для Motorola 68000 для Sega Mega Drive. Например, ограниченные возможности машины на корню режут количество и размах хотелок. Или отсутствие гадания как это будет работать на машине - кеша нет, предсказателя ветвлений нет, скорость чтения из ROM равна скорости чтения из RAM. Целый пласт современных метаний с учетом всех этих деталей просто отсутствует как категория. Не нужно думать о сожительстве с ОС и другими приложениями. Не нужно думать о многопоточности (хотя у SMD есть отдельный процессор для управления звуком). И при этом решение многих обыденных современных задач в ограниченных ресурсах становится очень интересным. Мозг полностью занят непосредственно алгоритмами и всякими хардварными уловками.
К слову, вот что про подобную ситуацию думает сам создатель принципов SOLID:
Будет работать, за счет закона квадрата куба. В позапрошлом веке лед кубиками нарезали и прямо так кораблях развозили на пол планеты, а потом до конечного потребителя на деревянной тележке везли, летом. Потери льда при этом довели до всего 20-50%.
Пока эта махина песка со сторонами 10+ метров сама хоть немного остынет, ее уже израсходуют и заново нагреют.
Разница с литий-ионными батареями на единицу объема всего в 2-3 раза примерно. Но для батарей нужны дорогие материалы, сложные производства, плюс нагрев и пожароопасность, плюс деградация емкости со временем, да и сплошняком по объему их не поставишь. А тут набрал песка в любой объем/любую форму и он лежит себе хоть тысячу лет, только ТЭНы с трубами меняй, да за корпусом следи. Причем греть по идее можно и сильнее, чем до 400 градусов (проблема как я понимаю в съеме энергии), а батареи уже близки к пределам возможностей. Тут как не оптимизируй, а теплоаккумуляторы на песке всегда проще и дешевле на единицу энергии будут.
В нашем подъезде у всех отопление на газовых котлах. Чтобы протопить свою квартиру нужно включить его осенью и выключить весной. Ну и у кого бачок открытый, раз в неделю стакан воды доливать.
Попробуйте внимательней читать что вам пишут. Применению каждой отдельной трансформации будет соответствовать одна арифметическая операция, а не одна арифметическая операция вообще на все.
Вам нужно отражение по оси? С матрицами это создание матрицы с последующим умножением, без матриц это смена знака. Вам нужно смещение? С матрицами это создание матрицы с последующим умножением, без матриц это сложение. Вам нужно масштабирование? С матрицами это создание матрицы с последующим умножением, без матриц это умножение. А никаких других трансформаций в нашем случае быть не может, только последователность перечисленных. Мы можем работать с координатами по отдельности, и тогда у нас будет две строки, где каждая операция выполнена и для x и для y, а можем с векторами, и тогда строка будет всего одна.
Причем так же как любую последовательность трансформаций смещений и масштабирований можно представить одной матрицей трансформации, эту же последовательность трансформаций можно свести в один набор (dx, dy, sx, sy). И то и другое в итоге придется применить к паре координат, чтобы перевести их из одной системы в другую.
В разных движках и графических API координаты могут иметь разную направленность. В OpenGL ось y направлена вверх, в DirectX она направлена вниз.
Даже в строке которую вы привели выше больше одного вызова функции, а она только применяет одно смещение. А программисту интерфейсов и жестов в любом случае нужно будет вызывать готовые библиотечные функции, что с матрицами под капотом, что без. Хотя у вас и это видимо не так.
Да, писал. А вы писали какой-то интерфейсный код. Это значит что вы писали что позиционируете себя как эксперт в написании интерфейсов?
Это утверждение не совпадает по смыслу с утверждением которое вы приписываете мне выше. И даже не полностью совпадает по смыслу с моим реальным утверждением. Чтобы вы не утруждались, я даже скомпилирую свою предыдущие утверждения в одно прямо здесь: матрицы не нужно использовать в проекте, в котором есть ровно одно линейное смещение и ровно одно линейное масштабирование, если только это не продиктовано ограничением инструмента разработки.
Нет, это не цитата.
Это не преимущество, это описание того чем оно является. Программисту интерфейса не нужна арифметика над проекциями систем координат, ему нужно решать практическую бизнес-задачу.
А по задаче нужно двигать объекты. Один раз отмасштабировать и один раз сместить.
А в реальном коде это не одно действие, потому что этому предшествует "вы высчитваете проекционную матрицу". Причем т.к. матрица вида у вас ровно одна, вы делаете это ровно один раз. Так же как сделали бы это ровно один раз без матриц, только вместо каждого создания матрицы трансформации и матричного умножения у вас был бы один оператор над парой чисел. В вашем случае нет ни единого реального преимущества применения матриц. Ну, кроме того что вы самоутвердились поплевав в воображаемого ПТУшника который это якобы не способен осилить.
Это лишь последовательность трансформаций для одного объекта. А речь идет о иерархии узлов. Которая есть почти в любом игровом движке, которая есть в любом UI фреймворке, которая представлена DOM-омом в браузере, и которая само собой была в нашем движке. Потому что двигая панель нужно чтобы дочерние виждеты двигались с ней, а двигая танк за ним следовала и башня, зачастую с глубокой вложенностью и кастомно заданными осями трансформаций. Вот здесь как раз и возникают все преимущества применения матриц.
Если она не нужна в вашем проекте, это не значит что она не нужна остальным. В данном случае я бы даже сказал что вы в меньшинстве.
Опять лжете.
В учебнике будет сказано что матрицы удобны потому что они позволяют объединять множество разных трансформаций (и не будет сказано, что на практике это может применяться для целой иерархии объектов). В описанном вами случае иерархии нет вообще, а из трансформаций доступны только две самые тривиальные, ровно по одному разу каждая, и выполняемые одним сложением и одним умножением. Никакого преимущества от свойств матриц вы не получили.
Процитируете?
Вы уже откровенно лжете.
И тут тоже лжете.
Этот код менее читабельный чем
root:move(dx, dy);, илиroot.x += dx; root.y += dy;, ну или еще какой-нибудь вариации аналогичной записи.Встречный вопрос. Почему передача дельт в матрицу трансформации смещения с последующей передачей в функцию умножения это стильно-модно-моложежно, а то же самое выполненное для вектора или пары чисел парой арифметических операторов это "придуманная какая-то на коленке сделанная кривая хрень".
Я выше расписал подробней.
Ну, если у вас масштабировать можно либо весь канвас - либо вообще ничего, тогда да. И тогда втройне не понятно зачем вам вообще нужна матрица.
Т.е вы утверждаете, что даже для знающего ЛА программисту две арифметические операции будут менее понятны, читаемы и надежны чем постоянное создание матриц трансформации с последующим умножением? А вы когда два числа складываете, пишете
a+bилиimport sum = package.trash.sum ... sum(a, b)?