Не дает, но это хотя бы какие-то относительно твердые гарантии. P not NP не доказана, но все разумные люди понимают, что эта гипотеза верна. Возможно еще пройдет несколько столетий прежде чем она будет доказана, как было с Великой Теоремой Ферма.
Так ведь это обычная подготовка обучающего датасета. К примеру для DALL-E/Stable Diffustion это были пары картинка-описание. Конкретно в статье написано "About 60% of the contractors were hired to do what’s called “data labeling”. Остальная история про найм программиста, и какие-то задания которые могли бы использоваться для обучения, помоему просто притянута за уши.
А есть такие с доказанной теоретической стойкостью для ассиметричной крипты? Потому что к примеру даже для факторизации чисел не доказано, что это np-complete задача.
Вы пишите так как будто на этапе планирования вы уже знаете все конкретные алгоритмы и архитектуру. В реальности это возможно если только вы делали очень похожий проект, и новый имеет минимальную новизну. Если так то можно считать, что у вас уже есть рабочий код, который надо немного допилить и можно расходится.
Фундаментальная проблема в том, что "гладко было на бумаге но забыли про овраги". Предпосылки рушатся, алгоритмы взрываются от того что данных встало в 10 раз больше, архитектура не продумана и начинает буквально "сыпаться", ТЗ содержит ошибки и т.д.
Современная математика, огромна и узко специализирована. Всегда есть шанс, что обнаружится какая-то магия связывающая что-то из кажущихся на первый взгляд не взаимосвязанных областей.
Есть разные парсеры - LL и LR, в ручную в основном пишут LL, yacc и сотоварищи в основном генерят LR. Потенциально LR более скоростные и сильные, но там возникают проблемы, что если грамматика не однозначна задана, то появляются не разрешимые проблемы, так же с обработкой ошибок все бывает ни так гладко. К примеру, большинство парсеров C++ (gcc/llvm) написаны в ручную, как нисходящие рекурсивные LL.
Худший O(n), но в реальности это возможно только, если произвести целенаправленную атаку на хэш функцию. Если рассматривать это с вероятностной или практической точки зрения, то она бесконечно мала.
Не очень понял, что значит "раздувание", вам в любом случаи надо где-то хранить ключи и значения, обычно считают что при load factor <= 0.7, коллизий достаточно мало, и в среднем сложность будет O(1).
Так и b-tree тоже не в памяти, c хэш-мапами плохо что они не дают локальность рядом расположенные значений. O(1) это не лучший случай, а средний(амортизированный), и он вполне гарантирован если в таблице поддерживается разумный load factor.
Для хардварных языков и обычных, бэкенд который производит все необходимые оптимизации и превращает в конечный код, очень сильно отличаются. Для компиляции из обычных языков высокого уровня, у вендоров есть решения, я сомневаюсь что что-то принципиально лучшее можно сделать, тем более не обладая существенными ресурсами на разработку.
На самом деле модели надо смотреть, относительно тривиального бэйзлайна, например оптимальной константы. Тогда ясно на сколько улучшается метрика, возможно 30% для начала не так уж и плохо.
Вопрос был не про код, а про пришедший запрос. Да, если происходит какая-то не понятная магия, я тупо сохраняю в файл и смотрю что там, в том числе и в hex.
Коды символов в hex будут разные, можно их глазками посмотреть. И скорее всего кодировка будет utf-8. В частности если вы предполагаете, что должны в качестве идентификаторов быть только младшая часть ASCII, то при конвертации в ASCII, или другую кодировку в которой нет символов в духе русской "С", получится мусор, и это будет заметно.
Мы в данном случаи рассматриваем очень узкую и формализованную область математической логики, и даже там эта проблема не решена, по указанным мною причинам. Обычный человек логикой пользуется, вообще постолько-поскольку.
Явное задание, даже "правил логического вывода" большая иллюзия. Для этого во первых необходима репрезентация "базовых знаний" в рамках мат. логики. Во вторых вывести можно, что угодно. И количество возможных "теорем" растет около экспоненциально от глубины вывода. Человек, который оперирует логикой не думает, как алгоритм-автомат.
Точные, вернее детерминированно алгоритмические методы, достаточно хорошо не работали никогда. До нейросеток с начала 90х state-off-the-art были статистические методы, которые концептуально от нейросеток не сильно отличаются. https://en.m.wikipedia.org/wiki/Statistical_machine_translation
Не дает, но это хотя бы какие-то относительно твердые гарантии. P not NP не доказана, но все разумные люди понимают, что эта гипотеза верна. Возможно еще пройдет несколько столетий прежде чем она будет доказана, как было с Великой Теоремой Ферма.
Хорошие архитектуры "не приходят из космоса", это дитя опыта в конкретной предметной области, часто с первого раза не удачного.
Квантовые компьютеры это отдельная тема, хотя бы гарантии для классических. Ссылаться на P != NP с практической точки зрения не серьезно.
Поискал для интереса, нашел к примеру https://en.wikipedia.org/wiki/Multivariate_cryptography там утверждается, что задача лежащая в основе NP-complete.
Так ведь это обычная подготовка обучающего датасета. К примеру для DALL-E/Stable Diffustion это были пары картинка-описание. Конкретно в статье написано "About 60% of the contractors were hired to do what’s called “data labeling”. Остальная история про найм программиста, и какие-то задания которые могли бы использоваться для обучения, помоему просто притянута за уши.
А есть такие с доказанной теоретической стойкостью для ассиметричной крипты? Потому что к примеру даже для факторизации чисел не доказано, что это np-complete задача.
Вы пишите так как будто на этапе планирования вы уже знаете все конкретные алгоритмы и архитектуру. В реальности это возможно если только вы делали очень похожий проект, и новый имеет минимальную новизну. Если так то можно считать, что у вас уже есть рабочий код, который надо немного допилить и можно расходится.
Фундаментальная проблема в том, что "гладко было на бумаге но забыли про овраги". Предпосылки рушатся, алгоритмы взрываются от того что данных встало в 10 раз больше, архитектура не продумана и начинает буквально "сыпаться", ТЗ содержит ошибки и т.д.
Современная математика, огромна и узко специализирована. Всегда есть шанс, что обнаружится какая-то магия связывающая что-то из кажущихся на первый взгляд не взаимосвязанных областей.
Есть разные парсеры - LL и LR, в ручную в основном пишут LL, yacc и сотоварищи в основном генерят LR. Потенциально LR более скоростные и сильные, но там возникают проблемы, что если грамматика не однозначна задана, то появляются не разрешимые проблемы, так же с обработкой ошибок все бывает ни так гладко. К примеру, большинство парсеров C++ (gcc/llvm) написаны в ручную, как нисходящие рекурсивные LL.
Худший O(n), но в реальности это возможно только, если произвести целенаправленную атаку на хэш функцию. Если рассматривать это с вероятностной или практической точки зрения, то она бесконечно мала.
Не очень понял, что значит "раздувание", вам в любом случаи надо где-то хранить ключи и значения, обычно считают что при load factor <= 0.7, коллизий достаточно мало, и в среднем сложность будет O(1).
Так и b-tree тоже не в памяти, c хэш-мапами плохо что они не дают локальность рядом расположенные значений. O(1) это не лучший случай, а средний(амортизированный), и он вполне гарантирован если в таблице поддерживается разумный load factor.
Амортизированный O(1) на поиск могут дать только хэш мапы, но думаю с подобным подходом другие проблемы.
Для хардварных языков и обычных, бэкенд который производит все необходимые оптимизации и превращает в конечный код, очень сильно отличаются. Для компиляции из обычных языков высокого уровня, у вендоров есть решения, я сомневаюсь что что-то принципиально лучшее можно сделать, тем более не обладая существенными ресурсами на разработку.
На самом деле модели надо смотреть, относительно тривиального бэйзлайна, например оптимальной константы. Тогда ясно на сколько улучшается метрика, возможно 30% для начала не так уж и плохо.
Вопрос был не про код, а про пришедший запрос. Да, если происходит какая-то не понятная магия, я тупо сохраняю в файл и смотрю что там, в том числе и в hex.
Коды символов в hex будут разные, можно их глазками посмотреть. И скорее всего кодировка будет utf-8. В частности если вы предполагаете, что должны в качестве идентификаторов быть только младшая часть ASCII, то при конвертации в ASCII, или другую кодировку в которой нет символов в духе русской "С", получится мусор, и это будет заметно.
Мы в данном случаи рассматриваем очень узкую и формализованную область математической логики, и даже там эта проблема не решена, по указанным мною причинам. Обычный человек логикой пользуется, вообще постолько-поскольку.
Явное задание, даже "правил логического вывода" большая иллюзия. Для этого во первых необходима репрезентация "базовых знаний" в рамках мат. логики. Во вторых вывести можно, что угодно. И количество возможных "теорем" растет около экспоненциально от глубины вывода. Человек, который оперирует логикой не думает, как алгоритм-автомат.
Точные, вернее детерминированно алгоритмические методы, достаточно хорошо не работали никогда. До нейросеток с начала 90х state-off-the-art были статистические методы, которые концептуально от нейросеток не сильно отличаются. https://en.m.wikipedia.org/wiki/Statistical_machine_translation
Ну да, известная забава, я руководитель, а ты дурак