Inajaf, PHP - слой вам здесь не подходит потому-что нужен очень быстрый поиск по таблице. Поэтому вам нужны поисковые функции текста на стороне MySQL. Я не специалист в MySQL и не знаю какие модули или расширения нужно поставить чтобы получить функцию левенштейна. Но на стаковер я находил ее исходники в языках stored procedures для MySQL. Какие брать? Левенштейн. Soundex. Methaphone. Триграммный поиск. Биграммный. И еще бесконечное количество текстовых функций.
Берите их последовательно. Пробуйте. Какая-то подойдет к вашей задаче насктолько что будет достаточно. По Soundex/Metaphone можно строить индекс. Это ускоряет поиск.
Vitsliputsli, в целом вы права. Но мы сейчас с вами заняты придумыванием технического задания.
Реальное задание может быть проще. Оно может иметь зазор погрешности. Оно может быть толерантно
к ложно-положительным срабатываниям. Вообще если речь идет о пользовательской системе подсказок
при поисковых операциях - то пользователь будет толерантен к выводу лже-позитивных срабатываний
при условии что в drop-down он все равно находит нужное.
Скорее всего автор ошибается в техническом задании. Latin-1 не содержит кириллицу.
Кириллица может быть в cp866, win-1251 или каких-то koi8 кодировках если речь
идет об однобайтном источнике.
Вот мне интересно. Автор сам читает свои собственные заголовки?
Тут не надо быть филологом чтобы просто поймать вывих мозга.
Хм.... одного int между собой. Это как хлопок одной ладонью..
freeExec, сборник звуков может не подходить по объему занимаемой памяти например.
В данном случае нейросеть работает как архиватор. Оптимизируя хранение. Можно
сказать что архивация является побочнным эффектом этой задачи. Хотя и явно
не описаной автором.
В данном задании самое сложное - это поиск обучающих датасетов по звукам.
Я предлагаю автору начать с этого. Когда в базе будет хотя-бы по 100 семплов звучания шагов, потом трелей соловья, и прочее, можно начать обсуждать архитектуры сети а самое главное - аксептенс-критерии.
Потому что последние - это самая слабая часть в постановке.
Там не в лень дело. При разработке linux (kernel) насколько я знаю главным аппрувером
изменений является горячий финский парень Торвальдс. Это очень жесткий и вредный
чел. У него есть несколько цитат в группе разработки ядра где он объясняет почему С++
не подходит для разработки. Один раз сказал что-то вроде "Stuped idea". Вобщем
поищи сам я думаю найдешь.
Как по мне есть две вещи которые мешают затащить С++. Первое - это потеря контроля
над размером бинарника. За счет механики шаблонизации бинарь может быть несколько
в раз больше чем ожидался. Это убийственный артифакт для операционки. Нельзя просто
так раздуть ядро в несколько раз и расчитывать что оно будет так-же эффективным как и
раньше. Размер всех составляющих важен с точки зрения кеша инструкций.
И второе (IMHO) - время компилляции. Опять-же встроенные С++ шаблон-матчеры делают время
компилляции непредсказуемым (в одной из конферений говорят о недоказуемом
времени останова компилляции). Тоесть в теории - бесконечным.
Я не знаю сколько собирается ядро. Пускай знающие скажут. Но допустим оно собиралось
3 часа на сях. И после миграции в С++ цикл сборки может затянуться на 3 дня. Это
тоже слишком дорогая плата за просто замену языка.
Хотя может я ошибаюсь.
По поводу Rust в ядре. Ничего пока неясно. Я думаю этот вопрос можно задать отдельно в хабре.
Си - это портабельный ассемблер. Собственно такая задача и ставилась при создании языка. Облегчить написание частей Unix.
По поводу устарел или не устарел. Вот когда его заменят на другой язык при разработке Linux например, вот тогда и можно говорить о старении. А пока он безальтернативен.
