mayton2019

Насколько я понимаю TensorFlow - это коробочное решение от Гугла которое также поддерживает специальное железо TPU (Tensor Processing Unig) которое работает лучше чем вычисления на видеокартах.

А персептрон - это просто математическая абстракция. Причем самого начального уровня. Для многих алгоритмов обучения пороговая функция не годится (там есть требования дифференцируемости) и поэтому нейрон с гладкой функцией активации обычно используется как следующий шаг от персептрона. Хотя у теоретиков НС там были большие теоретические споры про скрытые слои и про учет слоев (как считать).

Дружище Корень

Я вместо ответа дам тебе несколько советов.

Первое. Тема Ферма является толстым троллингом для всех кто знает математику. И эксперты qna мне кажется ощущают от тебя усталость. Ты достаточно много продуцируешь потока сознания и это не идет на пользу. Лучше напиши 1 вопрос в неделю но обдумай. Второе Есть разница между операцией деления "/" в Python и в языках C++/Scala. Результат разный. Можно получить 5/2 = 2.5 или можно получить целое 2. Это очень важно для тех кто читает код. И это кардинально меняет взгляд на твою формулу которую ты пишешь в самом начале. Поэтому всегда обозначай язык разработки. Это поможет читающим понять формулу. Иначе будут обиды и непонимания. И если ты тегируешь топик Математикой то не стоит писать всякие исходники с inserts. Это раздражает. Раздели свои проблемы на части. Так будет лучше. Третье. Если ты выступаешь медиатором между Microsoft Bing и прочими чатами то - обозначь это. Пускай это будет джентльменское соглашение. Я всегда пишу если мой ответ был получен с GPT. Тоесть я разделяю за что я лично отвечаю и за что всякие AI.

Скорее всего неверно написанное приложение. По хорошему надо использовать пул коннектов и тогда БД не будет видеть такие ошибки. Но возможно другая ситуация когда сессии будут долго ждать освобождения нового объекта connection из пула. А почему он долго не освобождается - это еще один вопрос. Видимо у вас - длинные транзакции. Этого надо избегать. Короче проблема комплексная и надо смотреть "как было раньше" и "что изменялось". Хорошая идея откатить версию комплекса на 1 шаг назад чтобы просто посмотреть что действительно проблемы на было и в новой версии она возникла. Не думаю что хостинг тут сильно виноват.

В более крупном масштабе это не работает. В географических справочниках и классификаторах есть одна
проблема. Адресная строка - неформализуема.

В разных странах и государствах после уровня страны например не всегда идут города или области. Там могут
быть более сложные объекты (федеральные земли, периферии). И хуже того они могут стоять на разных уровнях. Улицы одного города могут внезапно иметь двойников (после слияния поселков к примеру). Могут быть улица Ленина, проспект и бульвар и переулок того-же имени.

Вобщем если вы хотите иерархию - то можно делать иерархию. Но нельзя гарантировать жесткую типизацию для какого-то уровня. И с уникальностью - косяки.

Можно попробовать создать texture atlas. Разместить 1000 картинок на одной большой и скачивать за 1 реквест.
Ну а потом средствами канваса резать их как колбасу для публикации.

Если честно я впервые слышу именно про такую олимпиаду. Обычно идут Математика или Информатика. Совершенно не представляю какие задачи могут там (в криптографии) быть.

Вообще. Есть только один способ готовиться к олимпиаде. Брать задачники и
прорешивать задачи каждый день. По несколько часов. По программированию
у меня был один такой задачник образца 2000х годов. Там почти все решения
задач на Pascal.

Звездочка * означает что все найденные документы будут физически переданы по сети на клиента.
Поэтому твои два эксперимента надо расширить. Проверить чем отличались условия с точки зрения
сети. Куда (как далеко) пердавались эти 1000 документов.

При чем здесь Flux и Mono к JSON? Это разные уровни смыслов. А если-бы ты c XML работал? Ты явно указываешь getObjectsAsFlux зачит и будел флюкс. А если тебя смущает массив внутри респонса то оберни его объектом и будет тебе всегда объект.

Я просто оставлю это здесь. Пусть полежит.

$ paste --help
Usage: paste [OPTION]... [FILE]...
Write lines consisting of the sequentially corresponding lines from
each FILE, separated by TABs, to standard output.

With no FILE, or when FILE is -, read standard input.

Mandatory arguments to long options are mandatory for short options too.
  -d, --delimiters=LIST   reuse characters from LIST instead of TABs
  -s, --serial            paste one file at a time instead of in parallel
  -z, --zero-terminated    line delimiter is NUL, not newline
      --help     display this help and exit
      --version  output version information and exit

Поскольку автор никак не обозначает синхронизацию между ними - то задача выглядит как запуск двух независимых джобов. Это можно сделать в linux/bash например вот так

$ ./app1 &
$ ./app2 &

И потом через команду jobs наблюдать их статус. Работают или нет.

Эта программа считает определители 3 порядка. Теряется красота С++ и обобщение.

Математически можно считать определители 4 порядка через миноры матрицы понижая размерности до тех
пор пока мы не дойдем до 3 порядка рекурсивно. И тогда сработает формула с хардкодом

a[1][1] * a[2][2] * a[3][3] + a[1][2] * a[2][3] * a[3][1] + a[2][1] * a[3][2] * a[1][3] - a[1][1] * a[2][3] * a[3][2] - a[1][3] * a[2][2] * a[3][1] - a[3][3] * a[1][2] * a[2][1];

Так можно посчитать 5 и 6 порядок и выше.

Очень жаль что автор не фокусируется на сути, называя "код" просто "кодом". А ведь это метод расчета чего-то конкретного.

Представтье что музыкант любое произведение называл бы просто "нотами". Странно правда?

Надо посмотреть в суть вопроса. Откуда вообще он идет. Очень часто программисты оптимизируют не то и не там. Иногда они оптимизируют "от нечего" делать. Или от предубеждений что каждый цикл надо оптимизировать.

Что по поводу этого куска кода думает бизнес? Его это беспокоит? Действительно ли этот кусов влияет на какую-то внешнюю оценку. Может он работает в составе джоба и занимает 1% времени?

Откуда вообще возникает list? Если из базы данных - то возникает вопрос. Можно ли сделать UPDATE прямо в базе данных без пере-сохранения в объекты.

Если надо только в объектах и если накладные расходы идут на объекты - то можно попробовать развернуть объекты на 90 градусов и сделать из них массивы примитивов. По ним поиск пойдет быстрее. Но такой подход
специфичен для bigdata, где есть WORM (Write Once Read Many). И нужно еще доказать что разворачивание объектов даст в итоге полезный эффект ведь накладные на сам процесс разворачивания никто не отменял.

Все современные задачи делятся условно на 2 категории. CPU-bound. IO-bound.

Первые. Это рендеринг графики. Игры. Численные методы. Майнинг. И все такое. Под это делают разбиение задачи на Processes (Windows/Linux), Threads (Posix). Короче бьються на независимые части и запускаются на отдельных процессорах или ядрах или потоках железа. В таком случае загрузка железа максимальна и отдача максимальна. Биг-дата джобы сюда-же можно положить.

И второй тип задачи - это современные бизнес приложения которые большую часть времени (ну допустим 80%)
стоят на паузе и слушают сетевой порт. И как только что-то прилетает они начинают активничать. Практика показала что большую часть таких задач можно запускать в 1 потоке и все будет нормально. Главное чтоб обработчик долго не тупил. Отработал свой реактивный евент. Или там MQ событие или событие актора и перекинулся на следующее.
Вот. Если грамотно делать второй тип то на 10 потоках ОС можно запустить тысячи акторов или веб-хендлеров бизнес приложения и все будет норм. Тоесть мы фокусируемся на том что I/O важнее.

Попытка смешивать эти юзкейсы или менять местами приводила к проблемам. Например если запускать много потоков ОС в рамках одной бизнес задачи то они очень быстро зацепятся за какой-то глобальный объект (mutex, critical section) и большее число времени процессора будет тратиться не на бизнес задачу а обслуживание этой конкуренции. Вобщем конкарренси - это страшная беда. И парадоксально но увеличение числа ядер или процессоров даже не решают проблему конкарренси а усугубляют. Есть доклад по Erlang на эту тему. И вообще самое лучшее конкарренси - это когда его нет.

Есть еще статья Стоунбрейкера (создатель Postgresql) где он рассуждает на тему куда сгорают мегафлопы в современных dbms под нагрузкой и приходит к очень печальным выводам. Почитайте. Это тоже в тему CPU-bound.

Ты должен спрашивать какие алгоритмы игровой графики бывают. Это важное. А константа - это просто реализация.

Почитай Генри Уоррена - Алгоритмические трюки для программистов. Там есть всякое. Деление через умножение на магию. Умножение через сдвиги. Дискретные логарифмы и корни и прочее.

В вопросе нет целеполагания.

Нужно ставить не линукс а нормальную прошивку от производителя. В этом случае на приставке можно
будет смотреть телеканалы.

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