Абсолютно верно - только вот недавно тут возился с JTAG-ом, там аналогичная ситуация - найдите того кто в полной мере понимает что там в OpenOCD творится и в GNU Debugger. Модель с использованием MCP Codex7 и достала всё что нужно из даташитов без ручного перебора флажков/опций/настроек всех этих cfg, yaml, json итд итп, причём из контекста она это делает гооораздо быстрее особенно когда дело касается взаимосвязей между настройками где нужно двигаться по цепочке, и при этом имеется ещё логика и состояние (если не так то там, если не там то сям).
Кстати тут уже другая проблема - это наследственность знаний. Линус вон жалуется что мейнтейнерам ядра уже 60+, а вед именно они были у истоков, но рассказать могут только то что они сами понимают на этот момент, то есть классику которой уже 50 лет, тот же самый С, который преподают везде или даже "современные" Python, Java и др, родом из 90х. То есть чтобы выучить всё, необходимо пройти 30 лет, но за это время необходимо оформить и передать эти знания, методики итд. Вот тут модель как раз и берёт верх, так как может вобрать в себя этот опыт, соответствующим образом представленный в виде датасетов и далее продолжить обучение самостоятельно. Качественный датасет = почти 0 ошибок ну или их количество совпадает с вероятностью их появления у человека.
Ключевой момент - MCP хранит ли состояние сессии, иными словами есть ли там какой-либо конечный автомат который что-либо делает с выводом или вводом в модель. По-идее он должен быть некой параллельной веткой с основным контекстом и явным событием которое триггерит вызов инструмента
Тут дело маленько в другом - что в спектре весов как-то сохраняется информация достаточная для более быстрого дообучения, то есть loss-фнукция почти сразу достигает значения, до которого доходит условно долгое обучение с нуля (или рандомным распределением) в зависимости от номера эпохи. Иными словами, спектр весов (а не сами веса) схлопывается из float32 до int1 (чистая двоичка), обратное восстановление не требует таких же объёмов обучения. Что касается MLP то квадрат-не квадрат вписывается в модель, аппроксимирующую сигнал |1-(x1-x0)/(y1-y0)|-0.4?1:0, тут по сути один вес и две активации - модуль и функция Хевисайда, разлагая их в "ряд" на ReLU или сигмоиды можно получить должную сеть даже без обучения. Дальше - больше, нейросеть которая обучает нейросеть. Собственно ради чего это и сделано. Берём очень скудные int1 и говорим другой нейросети - вот этот шаблон обученных весов соответствует таким-то датасетам и классификации, а теперь давай штампуй заготовки для кругов, квадратов, треугольников. Иными словами, нейросеть-учитель сразу подберёт такой спектр весов, который потом градиентами можно обучить не за условную неделю а за секунду. Затем это прикрутить к YOLO или LLM но это уже другая история ).
Вообще говоря нельзя делать универсальный ID. Их необходимо разделять по рангам. Какой-нибудь реалтайм просто счётчик на 128 бита с момента запуска по клокам, далее ID сессии с довеском в виде строки, потом ID с таймстемпом вроде UUID, далее уже криптографические и более сложные, включая виртуальную машину с таймаутами, битыми пакетами и прочие прелести сети и высоконагруженных систем, идентификатор по сути становится логом.
Начальные условия для вычислений или как коэффициенты для интерполяции. На DSP например тригонометрия считается именно так - таблица синусов/косинусов и ряд Тейлора
Тоже самое - корень квадратный считается методом Ньютона-Рафсона по таблице, которая является затравкой для начальных условий рекуррентного алгоритма по нахождению корня. Есть даже интересная история про это.
Да наподобие того как в микроконтроллере Тесей (боюсь ошибиться - поправьте если это не так),да фактически за один период клока 2 вычисления.
Это фактически определяющее лицо для комбинационной логики и защёлок переноса - именно там и появляются отложенные вычисления на следующий такт, оптимизация между сумматорами, умножителями (макроячейками) и защёлками (регистрами)
Проблема в том что все библиотеки изначально заточены для использования человеком. То есть на доверии, когда Вы уверены, что NO_ENGINE_SUBSTITUTION был кем-то написан и оттестирован. Это же относится вообще ко всему, интерпретатору SQL, агрегатору БД что всё соответствует Datasheet в указанных производителем рамках. Все вот эти документы улетают в претренинг без объяснения причин. Это отдельная работа, изыскания по искусственно созданным элементам, которые, в принципе, на следующем этапе уже будут не нужны. Необходимо не только предоставить сухое описание но и примеры приложений, использования итд. Даже мегакорпорации не тянут такое. Взять тот же MSDN - там до сих пор нечто из MFC образца середины 90-х и времени это шерстить ни у кого нет. Поэтому конечно же необходимо использовать в LLM то, что поддаётся достоверной генерации и использованию по-максимуму, не надо выжимать из неё то, в чём она начинает плавать. Качественные датасеты - это С и Питон, там тератонны токенов, одно ядро Linux чего стоит со всеми примерами использования, appnotes итд.
Осталось что-то туда для QEMU и xPack с контролем версий, плюс то что позволяет в JSON-ы настроек подгружать переменные среды и управлять ими без костылей в виде bash-инъекций, особенно что касается резидентных инструментов и их контроля вроде st-util и прочих которые требуют localhost и своё окружение. Хотя это скорее проблема в большей мере системы а не IDE, которая предоставляет безопасную песочницу. Вообщем что-то уже с этими Path и sys необходимо делать чтобы не городить файловую систему в файловой системе.
всё зависит от реализации команды DIV, для x86 генерирует int 0 и не меняет регистры, ARM возвращает 0, DSP/MIPS иногда (!) дают 0 или 0xFFF... максимум. Для плавающей запятой ещё есть число EPS, которое можно инъецировать в любые сомнительные дроби чтобы можно было досчитать симуляцию с гигавольтами и тераамперами.
Алгоритм довольно известный однако можно ли (навскидку): - использовать комбинацию с рядом Тейлора, которым иногда считают синус в качестве начального условия - симметрию по двоичным операциям, может даже как-то корректировать таблицу в процессе вычислений - доуточнение с двоично-адаптированным методом наподобие Ньютона-Рафсона особенно для квадратного корня - вычисление по фронту нарастания/спада одновременно - некий конвейер с разделением по фазе такта - микроконвейер на счётчиках и компараторах - железобетонная оптимизация вручную исходя из тех LUT/макроячеек которые имеются для заданной ПЛИС-ины с учётом их свойств и разрядности - оптимизация по знаку - прямой, дополнительный и обратный код - может что-то будет более оптимальным, включая кратное "заимствование" знака с запоминанием в триггерах, этакий стек переносов
В школе (тогда ещё были кабинеты) можно было попросить насыпать свёрлышек чтобы отсверливать свои первые печатные платы травя их в соли и медном купоросе. При должной технике они вполне себе не ломались даже в ручной дрели, хоть в коловорот.
"С" сейчас - это самый совершенный аппаратно-независимый ассемблер, включая диалекты OpenMP/CL/CUDA. Вот тебе память вот тебе калькулятор, далее управляй сам, флажками, агентами, счётчиками - это всё явно и более чем работает. Это вы ещё UB в Verilog/VHDL не заглядывали, особенно когда тайминги и прочие аппаратно-зависимые фишки лезут. Так что ручное, псевдоручное и вайб-управление памятью это то что нужно для bare metal проектов. На всё остальное - Питон.
Быстрый перевод в авиарежим и обратно - точка, медленно - тире. Можно кодировать сообщение активностью телефона - тоже радиопередача амплитудной манипуляцией.
Самое интересное - это сверхсветовая волна. Мы её можем имитировать физически. Представьте катушки и перпендикулярные обкладки конденсаторов. Витки катушек малы, например, так чтобы быть сосредоточенными на 2.4 ГГц, например, несколько миллиметров. Конденсаторы также квадратный сантиметр. Но общую картину поля они формируют так, как если бы волна с частотой скажем 430 МГц летела бы со скоростью света эквивалентной 2.4/0.43. Как-то так. Мы искусственно формируем BxH - синус электрический конденсаторами и синус ему перпендикулярный магнитный катушками
Метод Ньютона-Рафсона с квадратичной коррекцией ULP
Там не очень хорошая ситуация со значениями от 0 до 1 и потом далее. Нужна таблица 1/√x насколько помню а сам корень вычисляется как √x = x/√x. Проблема с затравкой для начального условия для больших значений корня. Вполне возможно что "в столбик" его считать будет дольше но надёжней и по памяти не будет затрат таблиц, ну или корень тем же самым кордиком. Ньютон-Рафсон хорош там где нужно посчитать быстро а не точно, например для амплитуды сигнала по квадратурным составляющим, там можно захардкодить количество операций и задать точность. Но для калькулятора это неприемлемо. Либо количество итераций будет уж совсем большим. Можно также корень через таблицы и вычислители логарифмов-экспонент с таблицами. Вообщем гарантия результата свыше 10 десятичных знаков задача ещё та
в плане того что в общем виде должно быть решение по дефолту а также то которое имеется благодаря штангенциркулю по факту. То есть пользователь должен иметь возможность повесить над принтером листок на котором будут наборы чисел. Для усадок, для габаритов, для отрыва от подложки детали и скручивания её "лодочкой", указание сделать терморазрывы да что угодно. Это не должно быть котом в мешке а как-то автоматизируемым. Наличие дополнительных чисел - атрибутов - это и есть дорога к коррекции. Вообщем это вопрос к тем кто пишет слайсеры и разрабатывает CAD, там не должно быть топтание на месте а учёт фаз 380В в розетке образно говоря. Сейчас параметры примитивны - они годятся только для настроек всей детали, но должны быть выборочные. например, какой-то слой сделать более прочным, где то соты, где-то прямые, настраивать шаг сетки рядом с отверстиями итд. То есть как-то уже совместить слайсер и саму модель. Раньше тоже САПР печатных плат даже не знали что такое 3Д детали - сейчас уже без этого превью никто не работает если имеется связь с конструкцией.
Просто видел вроде как разукрашенные есть - а раз там атрибут RGB имеется то и вполне возможно атрибут внедрить. Кстати в OpenGL фишка была с выбором объектов на экране - кодируются цветом и далее по цвету и координатам мыши выбираются. То есть RGB с альфа каналом - это идентификатор. Поискал, нашёл: Binary STL files include a 2-byte unsigned integer at the end of every triangle definition called the attribute byte count. 2 байта - туда можно 16 тыс всяких ID затолкать. Вообщем это не проблема формата а скорее недоработка CAD. Там много всего того что пора ремонтировать и того что не менялось уже лет 30. Замкнутый объём - это уже топологическая проблема слайсера, он сам численным методом должен уметь это делать.
Вот! Поэтому как-то надо прикручивать уже слайсерам в STL стандарт атрибуты которые позволяют задать какой-нибудь словарь параметров изготовления поверхности или даже объёма под ней. Это вообще говоря касается и CNC, которые, например, могут продавливать материал подачей, греть его и должна быть возможность задания отдельных технологических действий для поверхности. Вообщем что-то как-то САПР-ы плохо ещё дружат с технологией при 3Д-моделировании, где можно связать какое либо действие со скетчем с методикой его выдавливания-продавливания, которую можно экспортировать без дополнительных плясок с программой или даже G-кодом. Оплывание также учесть для отдельных поверхностей которые будут встык, остальное пусть делает по умолчанию.
Язык прежде всего должен быть стандартным (чтобы выбрать базу независимую от компиляторов) а также иметь триллионы токенов датасетов со всевозможными примерами. Явный пример С и С++, включая диалекты CUDA/OpenCL и прочие. Особенно синтаксически близкие Java/JS. Стандарт гарантирует нормальный компилятор (включая вайб-версию) в отличие от хотелок коммьюнити. Плюс компилятор может вобрать в себя флажки рефактора и прочие SEARCH/REPLACE так как может быть прикручен к кодовой базе непосредственно, плюс такой же JSON-вывод, адаптированный для модели.
Что касается Питон - indent там исторически на самом деле \t, настоящая ASCII табуляция, а не 4 или 8 \s пробелов. Пробелы - это позор для IDE не знающей табуляции и как с ней работать в окружении Unicode. Вообщем по семантике \t - это 1 байт, и количество индентов позволяет существенно лучше использовать контекст чем слежение за begin-end или {}, потому как каждый токен содержит идентификатор отступа и модель лучше знает что это тело цикла или область видимости. В этом плане Питон просто предвосхитил своё использование в этом русле.
Грамматика - если она LALR/LL(1) и умещается на тетради - добро пожаловать в LLM. Не нужны больше ООП-сущности - они только для человека. Модель может сама прикручивать необходимый полиморфизм "вручную". Perl/Raku - обратный пример, когда грамматика языка не выражается в генераторах грамматик а встроена в язык. Но тут другое преимущество - язык близок к абстрактному синтаксическому дереву, на котором можно научить модель.
Ну и в завершении главное - этот язык и будет Abstract Syntax Tree который далее будет скормлен генератору С,С++, Python и далее по списку как универсальное представление алгоритма и описания аппаратуры, включая Verilog/VHDL. Причём количество дескрипторов не будет превышать 256 - этого более чем достаточно для любой виртуальной машины. Далее можно хоть в LLVM непорседтсвенно или Java-байткод или даже WebASM
Главный вопрос - доколе сами САПР или слайсеры не будут поддерживать функцию +-0.3 мм на сопло. Если взять шток и цилиндр то должна иметься возможность указать что они должны быть подогнаны без молотка с заданной точностью и это должно быть учтено. Обычно слайс делает всё по центральной линии, что проще но не совсем верно, по-хорошему в stl должен уже появиться атрибут поверхности для которой обязателен учёт точного габарита. Не знаю есть ли такие слайсеры но то что есть пока что такое не делает
Абсолютно верно - только вот недавно тут возился с JTAG-ом, там аналогичная ситуация - найдите того кто в полной мере понимает что там в OpenOCD творится и в GNU Debugger. Модель с использованием MCP Codex7 и достала всё что нужно из даташитов без ручного перебора флажков/опций/настроек всех этих cfg, yaml, json итд итп, причём из контекста она это делает гооораздо быстрее особенно когда дело касается взаимосвязей между настройками где нужно двигаться по цепочке, и при этом имеется ещё логика и состояние (если не так то там, если не там то сям).
Кстати тут уже другая проблема - это наследственность знаний. Линус вон жалуется что мейнтейнерам ядра уже 60+, а вед именно они были у истоков, но рассказать могут только то что они сами понимают на этот момент, то есть классику которой уже 50 лет, тот же самый С, который преподают везде или даже "современные" Python, Java и др, родом из 90х. То есть чтобы выучить всё, необходимо пройти 30 лет, но за это время необходимо оформить и передать эти знания, методики итд. Вот тут модель как раз и берёт верх, так как может вобрать в себя этот опыт, соответствующим образом представленный в виде датасетов и далее продолжить обучение самостоятельно. Качественный датасет = почти 0 ошибок ну или их количество совпадает с вероятностью их появления у человека.
Ключевой момент - MCP хранит ли состояние сессии, иными словами есть ли там какой-либо конечный автомат который что-либо делает с выводом или вводом в модель. По-идее он должен быть некой параллельной веткой с основным контекстом и явным событием которое триггерит вызов инструмента
Тут дело маленько в другом - что в спектре весов как-то сохраняется информация достаточная для более быстрого дообучения, то есть loss-фнукция почти сразу достигает значения, до которого доходит условно долгое обучение с нуля (или рандомным распределением) в зависимости от номера эпохи. Иными словами, спектр весов (а не сами веса) схлопывается из float32 до int1 (чистая двоичка), обратное восстановление не требует таких же объёмов обучения.
Что касается MLP то квадрат-не квадрат вписывается в модель, аппроксимирующую сигнал |1-(x1-x0)/(y1-y0)|-0.4?1:0, тут по сути один вес и две активации - модуль и функция Хевисайда, разлагая их в "ряд" на ReLU или сигмоиды можно получить должную сеть даже без обучения.
Дальше - больше, нейросеть которая обучает нейросеть. Собственно ради чего это и сделано. Берём очень скудные int1 и говорим другой нейросети - вот этот шаблон обученных весов соответствует таким-то датасетам и классификации, а теперь давай штампуй заготовки для кругов, квадратов, треугольников. Иными словами, нейросеть-учитель сразу подберёт такой спектр весов, который потом градиентами можно обучить не за условную неделю а за секунду. Затем это прикрутить к YOLO или LLM но это уже другая история ).
Если раньше охотились за битками то теперь будут за API ключами для токенов
Вообще говоря нельзя делать универсальный ID. Их необходимо разделять по рангам. Какой-нибудь реалтайм просто счётчик на 128 бита с момента запуска по клокам, далее ID сессии с довеском в виде строки, потом ID с таймстемпом вроде UUID, далее уже криптографические и более сложные, включая виртуальную машину с таймаутами, битыми пакетами и прочие прелести сети и высоконагруженных систем, идентификатор по сути становится логом.
Начальные условия для вычислений или как коэффициенты для интерполяции. На DSP например тригонометрия считается именно так - таблица синусов/косинусов и ряд Тейлора
Тоже самое - корень квадратный считается методом Ньютона-Рафсона по таблице, которая является затравкой для начальных условий рекуррентного алгоритма по нахождению корня. Есть даже интересная история про это.
Да наподобие того как в микроконтроллере Тесей (боюсь ошибиться - поправьте если это не так),да фактически за один период клока 2 вычисления.
Это фактически определяющее лицо для комбинационной логики и защёлок переноса - именно там и появляются отложенные вычисления на следующий такт, оптимизация между сумматорами, умножителями (макроячейками) и защёлками (регистрами)
Проблема в том что все библиотеки изначально заточены для использования человеком. То есть на доверии, когда Вы уверены, что NO_ENGINE_SUBSTITUTION был кем-то написан и оттестирован. Это же относится вообще ко всему, интерпретатору SQL, агрегатору БД что всё соответствует Datasheet в указанных производителем рамках. Все вот эти документы улетают в претренинг без объяснения причин. Это отдельная работа, изыскания по искусственно созданным элементам, которые, в принципе, на следующем этапе уже будут не нужны. Необходимо не только предоставить сухое описание но и примеры приложений, использования итд. Даже мегакорпорации не тянут такое. Взять тот же MSDN - там до сих пор нечто из MFC образца середины 90-х и времени это шерстить ни у кого нет. Поэтому конечно же необходимо использовать в LLM то, что поддаётся достоверной генерации и использованию по-максимуму, не надо выжимать из неё то, в чём она начинает плавать. Качественные датасеты - это С и Питон, там тератонны токенов, одно ядро Linux чего стоит со всеми примерами использования, appnotes итд.
Осталось что-то туда для QEMU и xPack с контролем версий, плюс то что позволяет в JSON-ы настроек подгружать переменные среды и управлять ими без костылей в виде bash-инъекций, особенно что касается резидентных инструментов и их контроля вроде st-util и прочих которые требуют localhost и своё окружение. Хотя это скорее проблема в большей мере системы а не IDE, которая предоставляет безопасную песочницу. Вообщем что-то уже с этими Path и sys необходимо делать чтобы не городить файловую систему в файловой системе.
всё зависит от реализации команды DIV, для x86 генерирует int 0 и не меняет регистры, ARM возвращает 0, DSP/MIPS иногда (!) дают 0 или 0xFFF... максимум. Для плавающей запятой ещё есть число EPS, которое можно инъецировать в любые сомнительные дроби чтобы можно было досчитать симуляцию с гигавольтами и тераамперами.
Алгоритм довольно известный однако можно ли (навскидку):
- использовать комбинацию с рядом Тейлора, которым иногда считают синус в качестве начального условия
- симметрию по двоичным операциям, может даже как-то корректировать таблицу в процессе вычислений
- доуточнение с двоично-адаптированным методом наподобие Ньютона-Рафсона особенно для квадратного корня
- вычисление по фронту нарастания/спада одновременно - некий конвейер с разделением по фазе такта
- микроконвейер на счётчиках и компараторах
- железобетонная оптимизация вручную исходя из тех LUT/макроячеек которые имеются для заданной ПЛИС-ины с учётом их свойств и разрядности
- оптимизация по знаку - прямой, дополнительный и обратный код - может что-то будет более оптимальным, включая кратное "заимствование" знака с запоминанием в триггерах, этакий стек переносов
В школе (тогда ещё были кабинеты) можно было попросить насыпать свёрлышек чтобы отсверливать свои первые печатные платы травя их в соли и медном купоросе. При должной технике они вполне себе не ломались даже в ручной дрели, хоть в коловорот.
"С" сейчас - это самый совершенный аппаратно-независимый ассемблер, включая диалекты OpenMP/CL/CUDA. Вот тебе память вот тебе калькулятор, далее управляй сам, флажками, агентами, счётчиками - это всё явно и более чем работает. Это вы ещё UB в Verilog/VHDL не заглядывали, особенно когда тайминги и прочие аппаратно-зависимые фишки лезут. Так что ручное, псевдоручное и вайб-управление памятью это то что нужно для bare metal проектов. На всё остальное - Питон.
Быстрый перевод в авиарежим и обратно - точка, медленно - тире. Можно кодировать сообщение активностью телефона - тоже радиопередача амплитудной манипуляцией.
Самое интересное - это сверхсветовая волна. Мы её можем имитировать физически. Представьте катушки и перпендикулярные обкладки конденсаторов. Витки катушек малы, например, так чтобы быть сосредоточенными на 2.4 ГГц, например, несколько миллиметров. Конденсаторы также квадратный сантиметр. Но общую картину поля они формируют так, как если бы волна с частотой скажем 430 МГц летела бы со скоростью света эквивалентной 2.4/0.43. Как-то так. Мы искусственно формируем BxH - синус электрический конденсаторами и синус ему перпендикулярный магнитный катушками
Там не очень хорошая ситуация со значениями от 0 до 1 и потом далее. Нужна таблица 1/√x насколько помню а сам корень вычисляется как √x = x/√x. Проблема с затравкой для начального условия для больших значений корня. Вполне возможно что "в столбик" его считать будет дольше но надёжней и по памяти не будет затрат таблиц, ну или корень тем же самым кордиком. Ньютон-Рафсон хорош там где нужно посчитать быстро а не точно, например для амплитуды сигнала по квадратурным составляющим, там можно захардкодить количество операций и задать точность. Но для калькулятора это неприемлемо. Либо количество итераций будет уж совсем большим. Можно также корень через таблицы и вычислители логарифмов-экспонент с таблицами. Вообщем гарантия результата свыше 10 десятичных знаков задача ещё та
в плане того что в общем виде должно быть решение по дефолту а также то которое имеется благодаря штангенциркулю по факту. То есть пользователь должен иметь возможность повесить над принтером листок на котором будут наборы чисел. Для усадок, для габаритов, для отрыва от подложки детали и скручивания её "лодочкой", указание сделать терморазрывы да что угодно. Это не должно быть котом в мешке а как-то автоматизируемым. Наличие дополнительных чисел - атрибутов - это и есть дорога к коррекции. Вообщем это вопрос к тем кто пишет слайсеры и разрабатывает CAD, там не должно быть топтание на месте а учёт фаз 380В в розетке образно говоря. Сейчас параметры примитивны - они годятся только для настроек всей детали, но должны быть выборочные. например, какой-то слой сделать более прочным, где то соты, где-то прямые, настраивать шаг сетки рядом с отверстиями итд. То есть как-то уже совместить слайсер и саму модель. Раньше тоже САПР печатных плат даже не знали что такое 3Д детали - сейчас уже без этого превью никто не работает если имеется связь с конструкцией.
Просто видел вроде как разукрашенные есть - а раз там атрибут RGB имеется то и вполне возможно атрибут внедрить. Кстати в OpenGL фишка была с выбором объектов на экране - кодируются цветом и далее по цвету и координатам мыши выбираются. То есть RGB с альфа каналом - это идентификатор. Поискал, нашёл: Binary STL files include a 2-byte unsigned integer at the end of every triangle definition called the attribute byte count. 2 байта - туда можно 16 тыс всяких ID затолкать. Вообщем это не проблема формата а скорее недоработка CAD. Там много всего того что пора ремонтировать и того что не менялось уже лет 30. Замкнутый объём - это уже топологическая проблема слайсера, он сам численным методом должен уметь это делать.
Вот! Поэтому как-то надо прикручивать уже слайсерам в STL стандарт атрибуты которые позволяют задать какой-нибудь словарь параметров изготовления поверхности или даже объёма под ней. Это вообще говоря касается и CNC, которые, например, могут продавливать материал подачей, греть его и должна быть возможность задания отдельных технологических действий для поверхности. Вообщем что-то как-то САПР-ы плохо ещё дружат с технологией при 3Д-моделировании, где можно связать какое либо действие со скетчем с методикой его выдавливания-продавливания, которую можно экспортировать без дополнительных плясок с программой или даже G-кодом. Оплывание также учесть для отдельных поверхностей которые будут встык, остальное пусть делает по умолчанию.
Язык прежде всего должен быть стандартным (чтобы выбрать базу независимую от компиляторов) а также иметь триллионы токенов датасетов со всевозможными примерами. Явный пример С и С++, включая диалекты CUDA/OpenCL и прочие. Особенно синтаксически близкие Java/JS. Стандарт гарантирует нормальный компилятор (включая вайб-версию) в отличие от хотелок коммьюнити. Плюс компилятор может вобрать в себя флажки рефактора и прочие SEARCH/REPLACE так как может быть прикручен к кодовой базе непосредственно, плюс такой же JSON-вывод, адаптированный для модели.
Что касается Питон - indent там исторически на самом деле \t, настоящая ASCII табуляция, а не 4 или 8 \s пробелов. Пробелы - это позор для IDE не знающей табуляции и как с ней работать в окружении Unicode. Вообщем по семантике \t - это 1 байт, и количество индентов позволяет существенно лучше использовать контекст чем слежение за begin-end или {}, потому как каждый токен содержит идентификатор отступа и модель лучше знает что это тело цикла или область видимости. В этом плане Питон просто предвосхитил своё использование в этом русле.
Грамматика - если она LALR/LL(1) и умещается на тетради - добро пожаловать в LLM. Не нужны больше ООП-сущности - они только для человека. Модель может сама прикручивать необходимый полиморфизм "вручную". Perl/Raku - обратный пример, когда грамматика языка не выражается в генераторах грамматик а встроена в язык. Но тут другое преимущество - язык близок к абстрактному синтаксическому дереву, на котором можно научить модель.
Ну и в завершении главное - этот язык и будет Abstract Syntax Tree который далее будет скормлен генератору С,С++, Python и далее по списку как универсальное представление алгоритма и описания аппаратуры, включая Verilog/VHDL. Причём количество дескрипторов не будет превышать 256 - этого более чем достаточно для любой виртуальной машины. Далее можно хоть в LLVM непорседтсвенно или Java-байткод или даже WebASM
Главный вопрос - доколе сами САПР или слайсеры не будут поддерживать функцию +-0.3 мм на сопло. Если взять шток и цилиндр то должна иметься возможность указать что они должны быть подогнаны без молотка с заданной точностью и это должно быть учтено. Обычно слайс делает всё по центральной линии, что проще но не совсем верно, по-хорошему в stl должен уже появиться атрибут поверхности для которой обязателен учёт точного габарита. Не знаю есть ли такие слайсеры но то что есть пока что такое не делает