mayton2019

Блин. Распечатай их на экране и в среде разработки сравни через 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 где можно макросами расширить функционал
и просто делать ссылки на формулы. И может быть это автору будет достаточно.

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

Более интересный вопрос - как работают меж-банковские переводы. Как SWIFT работает? Как у него
баланс выглядит. И есть ли он там вообще? Как можно жить в условиях CQRS и eventual consistency?

Вот это мне кажется более интересные вопросы чем просто транзакции внутри банка.

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

Вобщем 2 фазы. В первой фазе - объявить структуру TS1 в каком-то обобщенном формате.
Например в JSON.

{
  "struct" : {
    "name" : "TS1",
    "fields" : [
      { "name" : "a", "type" : "int" },
      { "name" : "b", "type" : "int" }
    ]
  }
}

И сгенерировать из этой структуры код для декларации ее в языке C и для форматной
печати через printf.

Жесткий диск на 4 Тб под хранение файлов планирую отформатировать в exfat.

По дизайну, exfat задумывалась как файловая система для флешек и SSD устройств. Там целая совокупность
фич дизайнилась именно для таких юзкейсов. Поэтому ставя exfat на магнитный HDD ты по любому
делаешь как-бы не-целевое использование этой системы.
К каким последствиям это приведет - я не знаю. Не было у меня таких экспериментов.

Но вот у меня есть 2 внешних HDD в резиновом корпусе (для фильмов и сериалов) и они отформатированы
в NTFS тем не менее прекрасно используются в двух ПК на Windows/Ubuntu и на телевизоре Toshiba.

Что ты там еще про MacOS написал - вообще непонятно. Вроде как в заголовке очевидно что тебе нужно 2 операционки. Так две или три?

Плюс, наверное, не надо будет дефрагментацию на этом диске делать, быстрее всё будет работать, да?

Вот реально уже десяток лет я не слышал чтобы кто-то серъезно озадачивался именно процессом дефрагментации.
Это знаешь ... как гомеопатия. Все говорят что полезно. Но никто никогда не мог в деньгах в долларах или в минутах
посчитать пользу от этого мероприятия. Для SSD например это задача почти бесполезная. А для магнитных дисков
роль в последнее время в бытовых ПК отведена именно как хранилище фильмов и файлов с редким доступом.
Ну да лет 10 назад для Oracle DBMS для раздела redo-logs на магнитных блинах еще можно было что-то там
обсудить. Или жарко поспорить. Сегодня - всем плевать. Даже девопсы этим не занимаются уже.

Вобщем дефрагментация - это гомеопатия. Да и современные ФС - тяготеют к автоматическому само-обслуживаю
в этом плане. На эту тему можно посмотреть в Zfs например. Что у них там?

famsssss это ETL с нормализацией. Задача - типичная.
У тебя должен быть примерно такой план действий.

1) Таблицы vak, ring, mdb, cat, spec нужно загрузить в БД как есть. В денормализованном виде. Если они лежат в excel - то сохранить их как CSV формат. Далее дело техники. Можете задать другой вопрос в qna по поводу того как их грузить.

2) Надо нарисовать реляционную модель. Это примерно то что ты рисуешь в картинке но нужно рисовать от сущности-связи а не от того какие файлы даны. Например есть сущность ISNN. У нее есть какие-то атрибуты. Они возможно опциональные. Но они должны быть перечислены. Далее - другие сущности. Потом определяем связи между ними. Например если многим spec соотвествует один ISNN - то тип связи будет многие к одному. Бывает такое что между двумя сущностями связи многие-ко-многим. Как прямоугольная матрица где по горизонтали одна сущность а по вертикали - другая и на пересечении стоит YES когда связь в наличии. Это тоже можно. Это делается через промежуточную таблицу. Связи бывают рекурсивные (таблица может указывать сама на себя). И в РМ могут быть циклы и петли. Это тоже допускается. Просто в этом случае между сущностями будут несколько вариантов как их джойнить и все варианты верны.

3) После того как Реляционная Модель (РМ) определена - в нее можно загружать данные. Можно грузить через INSERT/UPDATE/MERGE. И если возможностей не хватит то можно брать хранимые процедуры на Postgres. Но обычно мне хватало и SQL. В крайнем случае можно брать языки типа Python, Ruby e.t.c. если например доменная модель ооооочень сложная и надо какие-то делать неочевидные поиски по коллекциям или работать с JSON/XML но у тебя вроде все атомарно и лежит просто в ячейках. Должно хватить SQL.

4) Последняя таблица izdanya - по смыслу является отчетом из основной модели. Я настаиваю именно на таком подходе. Физически - это может быть view или таблица неважно. Главное что она - вторична по отношению к модели.

Нужен еще один аргумент. Типа глубина рекурсии чтоб делать отступы. Ну и внутри функции печатать на экран. Чем больше level тем больше отступ от левого края.

int translateNumberSystem(int num, int p, int level)
{
    if (num == 0)
    {
        return 0;
    }
    return (num % p + 10 * translateNumberSystem(num / p, p, level + 1));
}

Нужно проверить все обращения к векторам

vector<vector<int>> matrix;
vector<int>res;

по индексу. Используется больше элементов чем выделено.

Автор и не жди решения на блюдечке. Давай начинай все проверять. Тестирование - это тоже активность разработчика и никто ее за тебя не сделает.

P.S. Странно что за 30 лет С++ std так и не обзавелся типом "матрица". Бедняги разработчики до сих пор используют вложенные вектора. Или зубчатые вектора.

Для недорогих облачных хранилищ обычно используют
AWS/S3, MS-Azure BlobStorage, Google Cloud Storage.