mayton2019

Если ты - программист на С++ то можешь сделать свою собственную библиотеку с таким-же интерфейсом
и со своей реализацией. Чтоб работала как прокси. Вызывала нужные функции из оригинальной библиотеки
а для функции a2 - возвращала true.

Если - бы я был бизнесом и автор пришел бы ко мне с таким вопросом - я б спросил : как сильно
влияет этот код на наш бизнес. И как много времени и сил мы хотим потратить на investigation
этой проблемы.

Я языках программирования и компилляторах всегда есть много забавных побочных эффектов. Но
не все из них являются performance issue. Чтоб быть в фокусе. Обычно performance issues изучают
в
- циклах
- векторизированных операциях
- параллелизм и конкуренция в многопоточке
- I/O

Отдельно можно рассмотреть его величество алгоритм. Это тоже важно.

Что мы имеем в данном примере? Ровно ничего. Совершенно софистический код, который не делает
полезной работы и мы не можем никак оценить пользу или вред от оптимизаций. К слову если-бы
инициализация Point стояла бы в теле цикла, то мне не составило-бы труда развалить ее на атомы
(две переменных int) выполнить над ними все калькуляции и после выхода из цикла собрать снова
эту-же структуру.

Оценю в 1 story point вместе с тестами. И это будет дешевле по усилиям даже чем обсуждать этот
вопрос в хабре. Грубо говоря вопрос будет закрыт даже не появившись.

Автору еще посоветую посмотреть на GCC. И посмотрет на промежуточный LLVM код, который создает
clang еще до ассемблера. Возможно это поведение там зафиксировано. Как особенность clang.

Для хранения секретов есть специальные Wallet-приложения. Типа Kee-Pass.
Они шифруют информацию и после log-out или ребута системы потенциальный
злоумышленник не может ничего взять с wallet без мастер пароля.

Вопрос удобства мы оставим за кадром. Мне кажется что если во главе угла стоит безопасность
то все плюшки Excel не имеют значения. Потому что здесь самое важное - сберечь логины пароли
от кражи. Надеюсь все это понимают и не будут обсуждать "почему Excel". Security - first!

Еще я-бы посоветовал хранить этот файл на отдельном ноутбуке который не включается в сеть
вообще. И убирать его в сейф когда не нужно.

Задача : сделать так, чтоб при принудительном обновлении в первую очередь обновлялись объекты, которые не обновлялись дольше всего.

Мне не очень понятно, что мешает их обновить сразу?

Стоимость операций с HashMap, TreeMap достаточно дешевая чтобы этим вопросом вообще не
беспокоиться.

Если бы у тебя было очень много объектов и они не влазали бы в heap, то тогда я-бы предложил
LRU Cache (Last Recently Used). Но у тебя 5000 объектов. Это мало для БД и кеша горячих объектов.

Вообще не факт что дело в Питоне. Вместе с ботом запускается SQLite. Как часть процесса.
База сложным образом кешируется и обладает свойством забирать столько сколько надо
с учетом настроек. Я-бы посмотрел настройки SQLite.

Если под капотом "телетхона" работает http-протокол то можно качать в несколько сеансов.
Только для каждого задать свой уникальный range. На выходе будет несколько кусочков
файла которые можно склеить в один файл.

Тут пример https://developer.mozilla.org/en-US/docs/Web/HTTP/...

Суммировать - просто.

А умножение и деление базируется на работе с логарифмической линейкой. Чтобы умножить
два напряжения a и b такая формула.

def mul(a:Double,b:Double) = math.exp( math.log(a) + math.log(b))

Деление - аналогично. Операционные усилители при этом делают нелинейные преобразования.
Логарифмируют и вычисляют экспоненту от напряжения.

Странно что все тепловизоры под Андроид имели какое-то жлобское разрешение. Я специально
искал получше и не находил. Дальше просто шла военная техника. Подумалось что сознательно
запрещают ставить на мобилы все что более сильное.

Очень похоже на средства самозащиты. Какой-то жлобский балолнчик который только собак отпугивает
или фонарик-шокер - можно. А чуть только дальше - низя.

В данной задаче не хватает информации. А именно - как представлена дорога.

Без этой информции мы не сможем привязать координаты и азимут машины.

Если просто есть плоскость, по которой ездит материальная точка, то ее координаты
в промежутках можно интерполировать. Но при этом разворот на дорожной развязке
тоже не будет точно попадать в дорогу хотя и будет выглядеть красиво.

Мне вспоминается как я играл в StarCraft (первая часть) или Brodwar уже не помню.
Там была техника на колесах которая ездила достаточно плавно и с поворотами
но останавливалась всегда в координатах какой-то крупной сетки. Я предположил
что так работает игровой алгоритм интерполяции траектории. Вот нечто
подобное надо повторить для координат грузовика с GPS.

Лето. Жара. Техника перегревается. Посмотри какие кулеры покрыты пылью уже. Или может остановились.

Давным давно, когда еще не было такого огульного использования нейросетей, как сегодня,
я читал про преобразование Радона. Оно позволяет по одной проекции восстановить
больше измерений наблюдаемого объекта. Например как в томографе.

Но для того чтоб восстановление было точным - надо много раз поворачивать камеру и снимать
наблюдаемый объект с разных углов.

В класическом варианте Радон описан как одномерная функция y=f(x) но для твоего варианта
надо просто дать больше измерений на вход (фоток). И камеру крутить тебе надо не
по кругу как в томографе а со всех всевозможных углов по Эйлеру. На выходе будут вещественные
вокселы. (они будут все завсечены но с разной интенсивностью). Какие-то сильнее и какие-то слабее.
И если прогнать их через трешолд то получится вполне себе точная 3Д модель.

Ubuntu 22 уже устарела. Релизнулся 24 LTS поэтому можно переходить.
По поводу archive.ubuntu.com. Есть много причин почему у вас нет доступа
в том числе и политические причины. Но попробуйте найти региональное зеркало
этого репозитария и прописать его хотя-бы в /etc/hosts чтобы доступ шел туда.
Протокол - не секретный. Без https. Тоесть никакой проверки домена не будет.

$ srvctl stop database
...

Мы ищем функцию select_camera следующего вида. (На неком подобии Python/Scala)

case class Range(begin:Double,end:Double)

case class CameraProps(distance_range : Range, luminosity_range : Range) 

def select_camera(distance : Double, luminosity : Double, cams : List[CameraProps]) : List[Int] = {
  ....
}

По смыслу мы можем найти не одну а много камер, удовлетворяющих условию. Тоесть результат
это - список камер.

По реализации - это похоже на поиск точки, которая попадает в прямоугольники.

Быстрые алгоритмы и структура это QuadTree-s, R-Trees (Antonin Guttman).
И те и другие - подходят. Они по сути - вспомогательные структуры для ускорения поиска камер.

При условии что точка будет двигаться а камеры стоят стационарно а искать надо много.

Если двигаются и камеры и точки - то тогда надо искать другие структуры данных.

Скорее всего - специфика Go-задач.

Дело в том что область применения ORM обычно ограничивается CRUD приложениями.
И если мы заходим в область утилит для ETL и BigData то там оказывается что ORM вообще не нужен.
Там работают во первых диалекты SQL, (Spark-SQL, Hive-SQL, MS U-SQL). Во вторых дизайн
entities очень громоздкий (по 500-1000 колонок). И эти колонки еще и двигаются во времени
следуя schema evolution на ходу. Тоесть добавляя новые колонки и расширяя типы от узких к широким.
Представить себе ORM в таких условиях просто невозможно. Кроме того ORM кеширует объекты
в коллекциях языка а это, сами понимаете не вопрос Bigdata и аналитики.

Вообще ORM - это пугало, которым пугают на собеседованиях новичков. Для java-junior знание ORM - уже
приравнивается к знанию сопромата и философии Конфуция. Знаешь ORM - получи должность
в банке и сиди себе с умным видом на митинге.

С моей точки зрения ORM ограничивает сильно в оптимизации запросов. Хинт уже так просто не поставить.

Кроме ORM (Object-Relational-Mapping) есть и другая философия. Не от объектов к реляциям а наоборот.
От базе к объектам. (Фреймворк MyBatis например). В нем причинно-следственная связь перевернута.
Сначала таблицы и хранимые процедуры существовали в БД и уже потом, a posteriori, разработчик
описывает для них мапппинги в обратном направлении.

Существует также миф о том что ORM позволяет лихо прыгать по разным базам. Ни разу я для себя этот
миф не подтвердил. Чем крупнее система - тем плотнее она сидит на лицензии от DBMS, и тем глубже
она использует фичи этой DBMS (язык хранимых процедур особые режимы таблиц и партишенинга)
и совершенно нет никакой надежды что миграция произойдет в один мышко-клик. Скорее наоборот.
Миграция - это боль и слёзы и крупные платежи сектору разработки и облачным провайдерам.
Баги и просадки перформанса в самых неожиданных местах БД.

Хотя для вашего pet-project ORM вполне удобен особенно когда вы тестируете например веб-приложуху
на H2 в перспективе с переходом на Postgres.

Тебе понадобиться функция PIVOT.

Посмотри пример. Там легко https://www.oracletutorial.com/oracle-basics/oracl...