mayton2019

Вы правы каждое слово кодируется. Существует огромное количество методов кодирования для NLP (Natural Language Processing). Основной метод кодирования это представления слова в виде вектора где самая важная часть (что делает NLP возможным) при создании такого вектора слова которые используются в схожих контекстах имеют схожее но не одинаковое векторное представление. Векторная схожесть может быть подсчитана разными способами ну например Евклидово расстояние. В таком случае например вы будете иметь уникальный вектор для каждого слова где вектора с близкими Евклидовыми расстояниями будут означать слова которые используются в схожих контекстах. Что касается формата данных которые получит нейронная сеть, то каждый вектор трансформируется где каждое число трансформируется в число 0 до 1. Существует опять таки несколько техник. самая простая формула (x - min(X)) /(max(X) - min(X)), где x это каждый элемент вектора, ну и соответственно min(X) - минимальный элемент вектора max(X) максимальный элемент вектора. подобная трансформация применяется к каждому элементу каждого вектора. Это примитивный пример, для понимания идеи. Данный вопрос глубокий различные техники кодирования могут быть очень сложны и существуют не мало разных подходов для решения подобных задач. Что касается двоичного входа для нейронных сетей то ответ нет. Нейронные сети могут в том числе получать двоичные значения, но не ограничены этим, также они могут получать дискретные (целые) или числа с плавающей запятой.

Слова исходного текста можно представить через "one-hot encoding" – одномерный вектор, где только 1 бит для данного слова – включён. Сколько всего в тексте уникальных слов, такой длины векторы.
Далее возможны преобразования слов в многомерные векторы так, что слова со сходными смыслами оказываются рядом. Или вектор от "кошка" к "котёнок" оказывается параллелен и той же длины, что от "собака" к "щенок". Это называется "word embedding". Один из способов их построения называется "Word2Vec".

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

80Тб это значит несколько дисков. В зависимости от того, как на их основе построен архив, можно попробовать по одному диску от архива отсоединять и на него восстаналивать (так не получится если на всех дисках создан один огромный raid массив)

на время восстановления массив не перезаписывать и вообще ничего с ним не делать, т.е. режим только чтения.

Настучать бы тем кто дает советы дробить ОДИН диск на разделы и раскидывать файловую систему linux по нему, причем используя lvm который тут ну совсем не нужен.

Настоятельно рекомендую избавиться от этой формы разбиения диска, сделать резервную копию всего корня / диска (tar, например сделав отдельно для каждого раздела, добавив ключ --one-file-system) и удалить lvm. Абсолютно все фичи, которые дает lvm можно получить с помощью btrfs или zfs, при этом это будет еще и быстрее (снапшоты у этих cow файловых систем бесплатные, а у lvm за 2х понижение записи)

настоятельно рекомендую следующий конфиг:
gpt таблица разделов
* 1Мб biosboot - раздел нужен если используешь legacy mbr в биосе
* 100Мб EFIboot - раздел нужен если используешь UEFI secure boot в биосе
* 512Мб ext4 /boot - раздел не обязательный, нужен только если используется нестандартная фйловая система или странные конфиги (типа bcache ssd кеш для hdd), так же он нужен для дисков больше 2Тб
* сколько надо btrfs / - раздел куда установишь систему
благодаря btrfs можно точно так же наклепать в нем виртуальных разделов для /var /home /tmp причем можно даже не указывать лимиты (будет использоваться общее место)

btrfs прекрасно умеет grub и не считается экзотикой (/boot раздел не требуется)

p.s. кстати, если загрузчик grub можно установить на другой диск (например карта памяти или другой диск), то системный диск nvme даже не придется разбивать на разделы и использовать буквально весь под файловую систему

p.p.s. btrfs мощная файловая система но настоятельно не рекомендую использовать его raid5, он еще нестабилен, хотя критичных багов, ведущих к потере данных нет, но есть сообщения о потерях свободного места в экзотических ситуациях

для софтварного рейда лучше пользоваться mdadm

Вы правы, рекурсию всегда можно заменить циклом. Более того, рекурсия - это и есть цикл, который за вас выполняет движок языка. Главный вопрос - что для вас будет удобнее: рекурсия или цикл.

Зачем нужна рекурсия в реальных случаях?

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

Свет просто существует. Он как веревка, протянутая сквозь пространство-время из одной 4-мерной точки в другую. Наше 3-мерное пространство движется в 4-мерном пространстве в направлении стрелы времени, и мы, пересекая 4-мерное пространство, видим проекцию 4-мерного луча света на наш 3-мерный мир в виде 3-мерного фотона.
Потому у фотона и нет массы, что он - как тень твоей руки на листе бумаги, которая тоже не имеет массы.
При этом все эффекты от света на наш мир движутся в 4-мерном пространстве вместе с нами и в принципе не могут обогнать мир, они - его часть. Поэтому ничто в нашем мире не может двигаться вдоль времени быстрее нашего мира, так как всё - часть нашего мира.

Начать с математического доказательства (проверки), что для заданной конфигурации решение в принципе существет. А то можно искусственно создать неразрешимую конфигурацию (цветные квадратики отодрали и наклеили в другом порядке). Такое доказательство может в значительной мере определять алгоритм (но это не точно).
Готовые алгоритмы здесь: https://playlab.ru/club/instructions/

Ограничения бывают в софте но только искусственные, созданные к примеру компанией intel для монополизации рынка, отличным примером был sdk (набор инструментов и библиотеки) по работе с камерами-сканерами (3d intel realsense), на старте у них уже в железе были заложены ограничения на usb контроллер через который нужно было подключать камеру плюс проверки в софте (их потом убрали, но как я понял не все)

Повторяю, ограничения искусственные.

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

1. Если в плюсах class и struct фактически одно и тоже (да у класса по умолчанию все приватное, у структуры открытое, в этом разница), в шарпе это разные вещи.
2. в шарпе классы и так по ссылке передаются, ref class в шарпе аналог **class (указатель на указатель) и ref struct - *struct в плюсах.

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

docker logs -f --until=10s container_id

https://geekflare.com/check-docker-logs/

В чем дело? Да в том, что в рабочем проекте я этого не встречал НИ РАЗУ.

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

Ну а вопрос, зачем динамически выполнять то, что ещё на этапе проектирования зафиксировано и статично (я говорю о вызове функций), всегда вводит в ступор адептов каверзных вопросов и ФП.

На Haskell точно используется, т.к. частично применённые функции можно объединять (композиция, функторы, аппликативные функторы...), а как заметил mayton2019, тут и оптимизация возможна.
Посмотрите лекцию Дениса Москвина про оптимизацию.

Каррирование используется в библиотеках. Например, вот этой: https://github.com/substantial/updeep

Предполагаю, что проблема в невозможности сборки TDLib с Musl libc (стандартная библиотека Си, которая используется в Alpine Linux). Попробуйте использовать в качестве основы образа другой дистрибутив Linux.

Как там говорил кто-то из великих "Если вы что-то не можете объяснить 6-летнему ребёнку, вы сами этого не понимаете."
Ну и по вопросу часто понятно уровень спрашивающего.