mayton2019

При чем здесь 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.

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

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

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

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

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

Блин. Распечатай их на экране и в среде разработки сравни через diff.

По поводу ПЛР. Тут надо подумать с другой стороны. А потянешь ли ты работу в спринтах в современной корпорации? Это тоже нагрузка. И здоровые иногда психуют.

Знаешь как иногда хочется взять клавиатуру! Подойти к соседу и как уе... короче ударить его по башке. А потом еще. И приговаривать при этом - За-чем-ты-сво-им-ком-ми-том-от-ка-тил-мои-из-ме-не-ния. Вот сколько слогов - столько раз по башке.

Есть массив [1,2,3,3,4].
Нет. Нет. Все не так. Бинарное дерево строится на основе любых произвольных массивов.
Не обязательно сортированных. То что ты привел это какой-то частный случай чтоб облегчить себе
жизнь. И непонятно зачем мы здесь будем обсуждать частный случай.

Вот попробуй построить дерево из
[5,1,3,2,4].

Я вижу это как нейронную сеть, которая через API получит координаты определенного газона (который является графом) и затем сгенерирует возможное расположение дождевателей, основываясь на таких параметрах, как тип дождевателя/размер газона/расход воды и/или будет использовать проекты пользователя в качестве датасета для получения весов или другой оценки производительности.

Мне эта задача напоминает оптимальный раскрой. Решалась она в 90х и 2000х без всяких нейросетей.
Ну я-бы по крайней мере попробовал. Не стал-бы пренебрегать простыми решениями.

Нейросети - это тяжелая артиллерия. И она все равно требует ручной работы. А именно - подготовки данных
ко входу. Эта итерация не автоматизирована и от нее зависит успех.

Очень верный совет вам - нанять разработчика который это один раз сделает. И заплатите ему чтоб он вам
объяснил как это работает.

Дружище @Ratyk_ss

Какая у тебя стоит главная задача? Я вижу разные направления.
Если ты хочешь просто изучить алгоритм обратного распространения ошибки (ОРО)
то тебе нужно взять просто Python и желательно готовую реализацию и просто разобраться
как она работает. И сделать график схождения этой ошибки. График и матрица классификации
будет подтверждением того что код написан правильно.

Ты затащил к себе в код библиотеку numpy и keras. Достаточно сложные. И для себя нужно
проверить что каждое действие например с numpy правильно тобой понято и применено и
выдает правильный результат. Я-бы покрыл модульным тестом все взаимодействия. Вот что такое np.dot?
Произведение. Какое? Скалярное? Векторное? ДА их до чорта много. Проверяй что за произведение.

Твоя ошибка - сложная. Нечеткая. Это не то что NPE, или index out of range. Ты говоришь - один нейрон активен.
Почему он один? Почему другие не корректируют свои веса? Вот этот случай ты должен проверить
и доказать в обратную сторону. Чтоб была коррекция цикл должен их покрывать. Они должны РЕАГИРОВАТЬ
на прямой ход и обратный код.

Логгируй. Вставляй asserts. Ничего другого я пока советовать не могу. Сомнительно что code-review здесь поможет.

Если у тебя стоит другая задача. А именно - просто применение нейросетей - то тебе ничего програмиировать вообще не надо. В наше время все НС - решены в виде коробочных продуктов.
И их надо сконфигурировать и просто подать на вход данные.

Думал решить эту проблему какой-нибудь утилитой по подсчету чексум типа cshatag. Но, она только под линукс. А мне надо и для мака и для винды.

Почитал. Эта утилита - только детектирует повреждения. Восстановить не может.

Я использовал другую par2. Она и коды восстановления добавляет.

выгружаются данные в виде json(csv):

Я вижу 2 стратегии как с этим работать.

1) Как с чистым JSON документом. Можно работать языком запросов JsonPath. И выбирать и трансформировать узлы Json многократно до полного формирования результата.

2) Как с дата-фреймом технологии Pandas, Databricks/Spark. Судя по внешнему виду это Пандас
загрузит успешно. Насчет Датабрикс я не уверент. Тот точно работает с Json-Lines а не с таким деревом где
есть единый корень. У дата-фрейма есть свойства SQL-курсора. Тоесть по нему можно бегать и выбирать
данные. Или другой датафрейм. И датафрейм обычно имеет больший запас прочности по объему данных.

Какую стратегию выбрать - это больше вопрос к автору. Вот что он лучше знает - то пускай и выбирает.

Для С++ разработки вам нужен компиллятор. Это может быть clang, gcc или Microsoft C++.

NetBeans создавался для Java разработчиков. Хотя он возможно и поддерживает С++ синтаксис но
мне разработка на сях в нетбинсе кажется странной.

Посмотрите в сторону Visual Studio Code. Ее все хвалят.

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

Кстати освойте компилляцию в консоли. Это очень важный навык для любого разработчика. И после этого
ваши страхи перед средой станут чуть меньше.

В классический реляционных БД - никак. БД проектировались исключительно как сервер который "отвечает на вопросы". И при этом сам ничего не уведомляет.

Если нужно ловить события в той точке где они возникают - то лучшее место не БД а именно сервер приложений. И для хранения событий использовать топики Kafka или RabbitMQ.

Если этого всего нет - то тогда дергай запросы 1 раз в час. Другого выхода нет.

Попробуй удали сервис

sc delete service_name

Семантические графовые базы данных скорее всего подходят под данную задачу. Типа RDF/Semantic Web.
В качестве языка запросов там могут быть использованы SparQL. В качестве платформы хранения.... а чорт
его знает. Там много форматов. И XML и JSON и есть бинарники и JDBC адаптеры.

Это вообще серебрянная пуля которая везде подходит. Даже реляционки можно также представить. Со своими
накладыми но можно.

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

Вторая. В эпоху умных чятов такие базы знаний умерли очень быстро. Вернее сказать их полезность
сильно девальвировала. В 20м веке в такие базы много вкладывали. Делали ставку на то что системы
со строгими правилами позволят выводить новые правила и факты. Но не сбылось.

Возможно я ошибаюсь и автору нужно на самом деле другое? Что другое? Ну просто какой-то язык
разметки типа markdown language или вообще confluence где можно макросами расширить функционал
и просто делать ссылки на формулы. И может быть это автору будет достаточно.

Вобщем для более глубокого понимания хотелось-бы чтоб автор просто привел парочки примеров. Может
там реально все проще.