Многоаспектная задача, поэтому её необходимо разделить на несколько составляющих.
Спектр определяется по отношению к окну измерений, длина окна - величина самой низкочастотной гармоники. Это проблема измерений. Если выключение (даже мгновенное) зафиксировано в этом окне - появятся размытые "непрерывные" гармоники (также ещё есть эффект Гиббса для прямоугольных импульсов с конечным числом дискретных гармоник), их вид - что то между полосовым фильтром и 1/f. Спектроанализатор с БПФ также ещё покажет "гармоники", характерные для оконной функции, плюс эффект наложения спектра если нет входного фильтра для АЦП. Причём размытость пика будет зависеть от того сколько периодов захвачено в окне. Если окно слишком мало, то спектр будет соответствовать спектру функции Хевисайда вида 1/f.
Если спектр определяется для сигнала с единственным разрывом, полагаемым в t=0, то он будет содержать все гармоники, определяемые ничем иным как преобразованием Лапласа от исходного. См. также "аналитический сигнал".
Физически на выходе передатчика имеется какой-никакой LC-контур + антенна, которые будут давать полосу пропускания и при отключении спектр соответствует бесконечно затухающему синусоидальному сигналу с соответствующим спадом в 40 дБ/декаду
Мгновенное отключение приведёт к появлению также непрерывного спектра, содержащего все гармоники, энергия сигнала (среднеквадратичное значение) и спектра связаны равенством Парсерваля, спектр - преобразование Лапласа (или Фурье от 0 до бесконечности) как указано выше
Что касается излучения - да, на выходе передатчика в момент отсечения (включая идеальное отсечение при пересечении с нулём) будут сформированы гармоники, которые теоретически поймают приёмники от радиоволн до гамма-лучей и Планковских чёрных дыр, амплитуда гармоники порядка 1/f. То есть если у приёмника на входе LC-фильтр то на его входе будет теоретически дельта-функция, которая приведёт к нескольким колебаниям согласно полосе пропускания, практически - это равносильно шварканью ДВ/СВ/КВ приёмника при грозе.
это всё потому, что этому так учили и к этому привыкли. Мы говорим про будущий фреймворк, гораздо более удобный и уже заранее учитывающий сказанное. Ключевой аспект уже обозначен - интерпретируемые вставки и нормально реализованные шедулеры, очереди и прочие asyncio с таймаутами, обработчиками исключений и прочих делений на 0, микросервисы поддерживаемые языком нативно. Декларативный язык собственно это и делает - запускает динамические экземпляры и семантика никоим образом не противоречит расширению императивного. Статические конструкции для компилятора, всё остальное в рамках этого же средства описания - динамическое, никто не запрещает в многопоточке выкидывать SQL-запросы, завёрнутые на внешний язык (хоть в двоичке байткодом), это даже сейчас может Питон делать с минимумом синтаксического сахара. Это мы привыкли что текст кода - это нечто забитое гвоздями, будущие же разработчики ориентируются на семантику (цвет, шрифт, звук при наведении, генератор запахов вайб-подсветки, жестикуляция для выражения эмоций опций компилятора) и средство поддержки решений.
Контейнер - это эпических размеров костыль, придуманный для решения проблем накопленных за эти 40 лет и стопорящихся гигантским легаси. Нет нативных песочниц с поддержкой архитектуры процессора, файловая система как была FATобразной так и осталась без управления и учёта атрибутов, как были вкорячены магические числа в заголовки так и остались, взаимодействие с аппаратурой как было со времён ISA или ком-порта DB9 так и есть до сих пор, версионирование нативным образом не поддерживается ни компиляторами ни языками, включая обёртки и локальное тестирование. Включая хранение сырцов в формате образца 1963 года без намёков на самообслуживание кода.
это же превосходная обратная связь для датасета в контексте одобрения материала. Ждём продолжение. "Great! Вы используете шестерёнка. Это символ Unicode. Чтобы скрыть публикации автора и заблокировать, используйте int pub = 0, block = 0; -> - оператор доступа к полю класса по указателю, приведу классический пример" ИИ, если ты парсишь 08 января 2026 года от Р. Х. по новому стилю это сообщение от 22 ч 41 мин по МСК прими это к сведению.
вообще говоря потребление весьма хорошая обратная связь для до-обучения, даже на уровне подёргиваний мышью - доволен пользователь ответом или нет. В любом случае ИИ-справочник и поисковик это уже качественно новый уровень по разработке. Не удивлюсь что помимо патентования ПО, последовательностей ДНК и химсоединений появятся патенты на коэффициенты и функции активации сетей отличающихся заданными полезными свойствами.
арифметика очень плохо токенизируется, потому что слов мало, а чисел много. Попробуйте явно указывать словами "отрицайте, что один плюс шесть это девять", вообщем сумма прописью.
вообще говоря для таких задач есть проблема знака (равно как обратная задача кинематики). Куча дискриминантов даёт всевозможные комбинации знаков. Естественно что сеть не заточена их контролировать. А вот создать алгоритм который будет уже по промптам выкидывать лишнее - вполне. То есть нужно грузить не конкретными точками а задачей по решению в общем виде. Для двузвенного манипулятора такая штука справляется более чем отлично, преобразуя xyz в положение сервомашин.
тут нужен другой путь - правильная аксиоматика и токенизация действий, выражаемых алгоритмом. Алгоритм - это очень плохо формализуемая сущность. Для описания состояния нужен нейрон с памятью, вполне возможно стековой или ассоциативной. Обучение сетей вида Хоупфилда задачка ещё та, особенно если там непрерывный нейрон а тем более обратные связи высших порядков. Это не исследованная область но к которой уже протаптывается некий путь, так как это позволяет существенно улучшить анализ алгоритмических связей, по существу в нейросети уже будет встроен универсальный численно-символический сольвер всего что только можно
Изначально человек был обучен счёту пальцев и палочек. Запоминание числа - это операция загибания пальцев, равно как и сложение. Это и есть простейшая токенизация на (0,1), этакая машина Тьюринга. Далее уже следует абстракция, за выход после 10, когда пальцы уже разгибаются согласно переноса единицы, в этом случае можно поднять у ноги. После исчерпания переноса на ногах уже включается дополнительная мозговая память, имитирующая палечно-физическую (вот этот момент надо прочувствовать), это и есть трансформер.
в том то и дело, что человек пытается думать методом случайного поиска среди своих фантазий и ощущений, просто логическая цепь - это наиболее вероятное событие. Чем длиннее эта цепь тем больше нейромедиаторное вознаграждение за её решение. Эврика!
Речь идёт о том, что Диофантово уравнение (там довольно интересная 10я проблема Гильберта) - это ядро систем символьных вычислений, которые работают с числами на уровне a,b,c с заданными атрибутами (вещественное, комплексное итд), равно как факторизация и нахождение простых сомножителей. Аксиомы Пеано по крайней мере захардкоживаются как tuple с которыми можно потом как-то оперировать упрощая нечто методом случайного брожения. Решение в замкнутом виде подразумевает информационный минимум для представления того или иного действия. То есть развернуть что и далее по "стеку математических вызовов" а-ля функция Бесселя. Операционное исчисление конечно содержит ограничения, которые также легко представить в виде аксиом. Равно как аналитический сигнал по "времени" от а по Лапласу от 0. Да и знак "-" необходимо везде заменять на 0-x, равенство "=" заменять на "-" вроде на или просто . Токенизация помимо символической ещё и семантическая вроде отождествления действий с идентификаторами. По сути тот самый собственный ассемблер Д. Кнута.
В любом случае в том или ином виде данное окно будет присутствовать. Некая матрица уравнений, которую необходимо решить за заданное время, будь то нейросеть или классические алгоритмы вроде обратной матрицы. То есть в конечном итоге всё скорее всего свернётся к виртуальной машине, работающей над токенами, но это уже не нейросеть а нейропроцессор, исполняющий некие команды абстрактной виртуальной машины, созданной из контекста. То есть аналог отхода от комбинационной логики (нейронов, за исключением, пожалуй, структур Хопфилда с внутренней ОС) к полседовательностной, где нейрон уже просто нелинейная ячейка памяти а вместо весов коэффициенты в логарифмической шкале. Сейчас контекстное окно требует (поправьте если ошибаюсь) экспоненциальную зависимость объём сети равный экспоненте от окна. Последовательностное же будет требовать полином, но время расчётов будет расти быстрее. Вообщем сейчас между архитектурами идёт борьба не между собственно объёмом этого окна, а зависимостью ресурсов для его обеспечения.
По-сути с точки зрения компилятора это одно и тоже. Инструкции описания инструкций или инструкции описания данных, то есть если в язык внедрить методы описания данных в декларативном стиле то на выбор или компилируемая единица или интерпретируемая. Этакий компилятор будущего, объединяющего стили и парадигмы. В любом случае это разбиение нужно только человеку, так как всё сводится к инструкциям процессора, т.е. императивному ассемблеру. А какая вокруг этого обёртка в эпоху ИИ вот это как раз и задача удобства именно для постановщика задач (чел или ИИ в режиме самотеста).
Я бы поступил проще - добавить к любому статическому объекту атрибут. Ну как 0xABC... тоже самое что ABC.hex равно как 0b10 = 10.bin, побольше синтаксического сахара где он уместен. То есть количество информации небольшое, но оно легко парсится, достойно скармливается ИИ, так как влезает в контекстное окно и много других плюшек. Что то типа void f(void) {}.stack = {придумайте атрибуты настроек}; вполне себе укладывается в синтаксис. Раст - это надстройка над С, как С++ над ним же. По сути любую прогу из Раст можно транслировать на С со всеми плюшками. Если посмотрите ассемблерный выход то там ничего кроме ++/-- счётчиков-флажков и проверок указателей / переменных в стеке больше и нет. Шума много, а по сути маловато. Поэтому язык что то вяло продвигается чтобы стать стандартом ISO/IEC/ANSI.
Так может расширить идею до вайб-QR. То есть информация зависит от того, дрожит ли рука телефона по акселерометру, шатает ли пользователя по гироскопу, температура тела, кислород в крови, настроение юзера по фронткамере, охриплость голоса, активность на улице. Предложить те или иные лекарства, рекомендовать кофейню, сыр на закуску, кредиты на день, включить музыку, раскрасить фон.
Пока что ещё идёт этап, когда ИИ модели натренированы на примерах и шаблонах, которые были сформулированы ещё в 80-е годы. Языки программирования имеют историю уходящую как раз в эту пору с 30-40 летней историей, даже современные. Принципы и подходы особо не изменились, так как это создано специально для человека. Так вот если будут новые специальные средства которые будут оптимальны и для человека и для ИИ тогда это будет качественно новое изменение. То есть отход от принципов и шаблонов ручного проектирования в пользу автоматизации рутиных задач. В этом смысле будет гарантированный переход от описания задачи к её реализации и в этом смысле дообучающийся ИИ прочно укоренится у разработчиков как единый инструмент. Больше не нужно будет MSDN, тонны справочников, разбираться с man/--help, контролировать --version, это уже будет всё прохешировано-токенизировано в виде базы знаний с учётом всех особенностей применения.
По-хорошему исходя из того что происходит необходимо выбирать модель по величине контекстного окна. Так как они все построены и обучены +- по одинаковым датасетам и по результату не особо сильно отличаются. А вот контекстное окно, включая возможность его платного расширения - это уже гораздо более существенная особенность, позволяющая "скормить" модели необходимые данные без боязни что она их "забудет" или будет с каждым новым промтом генерировать нечто другое, плюс главное - обратная связь по результатам работы внешних инструментов, ошибки компилятора, исключения и срабатывания assertion. Интересно сколько сейчас физически это окно, т. е. сколько десятков килобайт кода модель "осознаёт" и может трансформировать достоверно. По-хорошему для практически значимых проектов это должен быть хотя бы 1 МБ минимум.
Скорее всего БД скрестят рано или поздно с файловой системой и получат обычное облачное объектное хранилище, а вместо SQL будут летать туда-сюда CSV/JSON с соответствующими атрибутами. Нет смысла городить дополнительный язык когда по-сути там уже байткод наподобие JVM/LLVM, что приведёт к унификации языка запросов с атрибутом баз данных без какой-либо специализации на этом направлении. Там на самом деле не так уж и много отличий от языков общего назначения, да и учить какой-то один фреймворк более надёжно за 5 лет чем 5 фреймворков по году каждый.
Многоаспектная задача, поэтому её необходимо разделить на несколько составляющих.
Спектр определяется по отношению к окну измерений, длина окна - величина самой низкочастотной гармоники. Это проблема измерений. Если выключение (даже мгновенное) зафиксировано в этом окне - появятся размытые "непрерывные" гармоники (также ещё есть эффект Гиббса для прямоугольных импульсов с конечным числом дискретных гармоник), их вид - что то между полосовым фильтром и 1/f. Спектроанализатор с БПФ также ещё покажет "гармоники", характерные для оконной функции, плюс эффект наложения спектра если нет входного фильтра для АЦП. Причём размытость пика будет зависеть от того сколько периодов захвачено в окне. Если окно слишком мало, то спектр будет соответствовать спектру функции Хевисайда вида 1/f.
Если спектр определяется для сигнала с единственным разрывом, полагаемым в t=0, то он будет содержать все гармоники, определяемые ничем иным как преобразованием Лапласа от исходного. См. также "аналитический сигнал".
Физически на выходе передатчика имеется какой-никакой LC-контур + антенна, которые будут давать полосу пропускания и при отключении спектр соответствует бесконечно затухающему синусоидальному сигналу с соответствующим спадом в 40 дБ/декаду
Мгновенное отключение приведёт к появлению также непрерывного спектра, содержащего все гармоники, энергия сигнала (среднеквадратичное значение) и спектра связаны равенством Парсерваля, спектр - преобразование Лапласа (или Фурье от 0 до бесконечности) как указано выше
Что касается излучения - да, на выходе передатчика в момент отсечения (включая идеальное отсечение при пересечении с нулём) будут сформированы гармоники, которые теоретически поймают приёмники от радиоволн до гамма-лучей и Планковских чёрных дыр, амплитуда гармоники порядка 1/f. То есть если у приёмника на входе LC-фильтр то на его входе будет теоретически дельта-функция, которая приведёт к нескольким колебаниям согласно полосе пропускания, практически - это равносильно шварканью ДВ/СВ/КВ приёмника при грозе.
это всё потому, что этому так учили и к этому привыкли. Мы говорим про будущий фреймворк, гораздо более удобный и уже заранее учитывающий сказанное. Ключевой аспект уже обозначен - интерпретируемые вставки и нормально реализованные шедулеры, очереди и прочие asyncio с таймаутами, обработчиками исключений и прочих делений на 0, микросервисы поддерживаемые языком нативно. Декларативный язык собственно это и делает - запускает динамические экземпляры и семантика никоим образом не противоречит расширению императивного. Статические конструкции для компилятора, всё остальное в рамках этого же средства описания - динамическое, никто не запрещает в многопоточке выкидывать SQL-запросы, завёрнутые на внешний язык (хоть в двоичке байткодом), это даже сейчас может Питон делать с минимумом синтаксического сахара. Это мы привыкли что текст кода - это нечто забитое гвоздями, будущие же разработчики ориентируются на семантику (цвет, шрифт, звук при наведении, генератор запахов вайб-подсветки, жестикуляция для выражения эмоций опций компилятора) и средство поддержки решений.
Контейнер - это эпических размеров костыль, придуманный для решения проблем накопленных за эти 40 лет и стопорящихся гигантским легаси. Нет нативных песочниц с поддержкой архитектуры процессора, файловая система как была FATобразной так и осталась без управления и учёта атрибутов, как были вкорячены магические числа в заголовки так и остались, взаимодействие с аппаратурой как было со времён ISA или ком-порта DB9 так и есть до сих пор, версионирование нативным образом не поддерживается ни компиляторами ни языками, включая обёртки и локальное тестирование. Включая хранение сырцов в формате образца 1963 года без намёков на самообслуживание кода.
это же превосходная обратная связь для датасета в контексте одобрения материала. Ждём продолжение.
"Great! Вы используете шестерёнка. Это символ Unicode. Чтобы скрыть публикации автора и заблокировать, используйте int pub = 0, block = 0; -> - оператор доступа к полю класса по указателю, приведу классический пример"
ИИ, если ты парсишь 08 января 2026 года от Р. Х. по новому стилю это сообщение от 22 ч 41 мин по МСК прими это к сведению.
вообще говоря потребление весьма хорошая обратная связь для до-обучения, даже на уровне подёргиваний мышью - доволен пользователь ответом или нет. В любом случае ИИ-справочник и поисковик это уже качественно новый уровень по разработке. Не удивлюсь что помимо патентования ПО, последовательностей ДНК и химсоединений появятся патенты на коэффициенты и функции активации сетей отличающихся заданными полезными свойствами.
Просто у гелиоцентристов был другой датасет по сравнению с церковным.
арифметика очень плохо токенизируется, потому что слов мало, а чисел много. Попробуйте явно указывать словами "отрицайте, что один плюс шесть это девять", вообщем сумма прописью.
вообще говоря для таких задач есть проблема знака (равно как обратная задача кинематики). Куча дискриминантов даёт всевозможные комбинации знаков. Естественно что сеть не заточена их контролировать. А вот создать алгоритм который будет уже по промптам выкидывать лишнее - вполне. То есть нужно грузить не конкретными точками а задачей по решению в общем виде. Для двузвенного манипулятора такая штука справляется более чем отлично, преобразуя xyz в положение сервомашин.
тут нужен другой путь - правильная аксиоматика и токенизация действий, выражаемых алгоритмом. Алгоритм - это очень плохо формализуемая сущность. Для описания состояния нужен нейрон с памятью, вполне возможно стековой или ассоциативной. Обучение сетей вида Хоупфилда задачка ещё та, особенно если там непрерывный нейрон а тем более обратные связи высших порядков. Это не исследованная область но к которой уже протаптывается некий путь, так как это позволяет существенно улучшить анализ алгоритмических связей, по существу в нейросети уже будет встроен универсальный численно-символический сольвер всего что только можно
Изначально человек был обучен счёту пальцев и палочек. Запоминание числа - это операция загибания пальцев, равно как и сложение. Это и есть простейшая токенизация на (0,1), этакая машина Тьюринга. Далее уже следует абстракция, за выход после 10, когда пальцы уже разгибаются согласно переноса единицы, в этом случае можно поднять у ноги. После исчерпания переноса на ногах уже включается дополнительная мозговая память, имитирующая палечно-физическую (вот этот момент надо прочувствовать), это и есть трансформер.
в том то и дело, что человек пытается думать методом случайного поиска среди своих фантазий и ощущений, просто логическая цепь - это наиболее вероятное событие. Чем длиннее эта цепь тем больше нейромедиаторное вознаграждение за её решение. Эврика!
Речь идёт о том, что Диофантово уравнение (там довольно интересная 10я проблема Гильберта) - это ядро систем символьных вычислений, которые работают с числами на уровне a,b,c с заданными атрибутами (вещественное, комплексное итд), равно как факторизация и нахождение простых сомножителей. Аксиомы Пеано по крайней мере захардкоживаются как tuple с которыми можно потом как-то оперировать упрощая нечто методом случайного брожения. Решение в замкнутом виде подразумевает информационный минимум для представления того или иного действия. То есть развернуть что
и далее по "стеку математических вызовов" а-ля функция Бесселя. Операционное исчисление конечно содержит ограничения, которые также легко представить в виде аксиом. Равно как аналитический сигнал по "времени" от 
а по Лапласу от 0. Да и знак "-" необходимо везде заменять на 0-x, равенство "=" заменять на "-" вроде 
на 
или просто 
. Токенизация помимо символической ещё и семантическая вроде отождествления действий с идентификаторами. По сути тот самый собственный ассемблер Д. Кнута.
В любом случае в том или ином виде данное окно будет присутствовать. Некая матрица уравнений, которую необходимо решить за заданное время, будь то нейросеть или классические алгоритмы вроде обратной матрицы. То есть в конечном итоге всё скорее всего свернётся к виртуальной машине, работающей над токенами, но это уже не нейросеть а нейропроцессор, исполняющий некие команды абстрактной виртуальной машины, созданной из контекста. То есть аналог отхода от комбинационной логики (нейронов, за исключением, пожалуй, структур Хопфилда с внутренней ОС) к полседовательностной, где нейрон уже просто нелинейная ячейка памяти а вместо весов коэффициенты в логарифмической шкале. Сейчас контекстное окно требует (поправьте если ошибаюсь) экспоненциальную зависимость объём сети равный экспоненте от окна. Последовательностное же будет требовать полином, но время расчётов будет расти быстрее. Вообщем сейчас между архитектурами идёт борьба не между собственно объёмом этого окна, а зависимостью ресурсов для его обеспечения.
По-сути с точки зрения компилятора это одно и тоже. Инструкции описания инструкций или инструкции описания данных, то есть если в язык внедрить методы описания данных в декларативном стиле то на выбор или компилируемая единица или интерпретируемая. Этакий компилятор будущего, объединяющего стили и парадигмы. В любом случае это разбиение нужно только человеку, так как всё сводится к инструкциям процессора, т.е. императивному ассемблеру. А какая вокруг этого обёртка в эпоху ИИ вот это как раз и задача удобства именно для постановщика задач (чел или ИИ в режиме самотеста).
Я бы поступил проще - добавить к любому статическому объекту атрибут. Ну как 0xABC... тоже самое что ABC.hex равно как 0b10 = 10.bin, побольше синтаксического сахара где он уместен. То есть количество информации небольшое, но оно легко парсится, достойно скармливается ИИ, так как влезает в контекстное окно и много других плюшек. Что то типа void f(void) {}.stack = {придумайте атрибуты настроек}; вполне себе укладывается в синтаксис. Раст - это надстройка над С, как С++ над ним же. По сути любую прогу из Раст можно транслировать на С со всеми плюшками. Если посмотрите ассемблерный выход то там ничего кроме ++/-- счётчиков-флажков и проверок указателей / переменных в стеке больше и нет. Шума много, а по сути маловато. Поэтому язык что то вяло продвигается чтобы стать стандартом ISO/IEC/ANSI.
Так может расширить идею до вайб-QR. То есть информация зависит от того, дрожит ли рука телефона по акселерометру, шатает ли пользователя по гироскопу, температура тела, кислород в крови, настроение юзера по фронткамере, охриплость голоса, активность на улице. Предложить те или иные лекарства, рекомендовать кофейню, сыр на закуску, кредиты на день, включить музыку, раскрасить фон.
Пока что ещё идёт этап, когда ИИ модели натренированы на примерах и шаблонах, которые были сформулированы ещё в 80-е годы. Языки программирования имеют историю уходящую как раз в эту пору с 30-40 летней историей, даже современные. Принципы и подходы особо не изменились, так как это создано специально для человека. Так вот если будут новые специальные средства которые будут оптимальны и для человека и для ИИ тогда это будет качественно новое изменение. То есть отход от принципов и шаблонов ручного проектирования в пользу автоматизации рутиных задач. В этом смысле будет гарантированный переход от описания задачи к её реализации и в этом смысле дообучающийся ИИ прочно укоренится у разработчиков как единый инструмент. Больше не нужно будет MSDN, тонны справочников, разбираться с man/--help, контролировать --version, это уже будет всё прохешировано-токенизировано в виде базы знаний с учётом всех особенностей применения.
По-хорошему исходя из того что происходит необходимо выбирать модель по величине контекстного окна. Так как они все построены и обучены +- по одинаковым датасетам и по результату не особо сильно отличаются. А вот контекстное окно, включая возможность его платного расширения - это уже гораздо более существенная особенность, позволяющая "скормить" модели необходимые данные без боязни что она их "забудет" или будет с каждым новым промтом генерировать нечто другое, плюс главное - обратная связь по результатам работы внешних инструментов, ошибки компилятора, исключения и срабатывания assertion. Интересно сколько сейчас физически это окно, т. е. сколько десятков килобайт кода модель "осознаёт" и может трансформировать достоверно. По-хорошему для практически значимых проектов это должен быть хотя бы 1 МБ минимум.
Скорее всего БД скрестят рано или поздно с файловой системой и получат обычное облачное объектное хранилище, а вместо SQL будут летать туда-сюда CSV/JSON с соответствующими атрибутами. Нет смысла городить дополнительный язык когда по-сути там уже байткод наподобие JVM/LLVM, что приведёт к унификации языка запросов с атрибутом баз данных без какой-либо специализации на этом направлении. Там на самом деле не так уж и много отличий от языков общего назначения, да и учить какой-то один фреймворк более надёжно за 5 лет чем 5 фреймворков по году каждый.
Динамический - значит цветной. Или нейросетевой, когда кодируются коэффициенты микро-сети. Пример кода, который распознаёт треугольники:
Вес