Это было время одноразовых ПЗУ в виде картриджей для Денди. Кстати большинство проблем на Спектруме были те самые динамические ОЗУ 565й серии которые вылетали с любым чихом с завидной регулярностью. Там ещё от производителя зависело вроде несколько заводов их выпускали (корпусировали)
Да, Вы правы! Уже подзабыл схемотехнику, не открывая поиск навскидку - там есть LC фильтр-пробка, который развязывает ГВЧ с входом чтобы не сжечь его. А качество.. с учётом того что это были двухваттные магнитофоны 2 или 3 классов (Вега и ещё какой-то монофонический почти игрушечный), то музыка в ГДШ, который сам по себе ВФЧ, звучала уже без разницы как, хотя если покрутить угол то, конечно, ощущалась. Это уже потом появились монстры 100W PMPO на этих же динамиках, зато как круто читается! Сам Спекки подключался к телевизору Юность с диагональю примерно 15'' с 5-ти пиновым разъёмом как у магнитофона (переделан). Там на разъёме есть язычок который переключает ТВ или приставка, хотя тогда в ходу были ТВ-модуляторы. Вспоминается ещё время PAL-SECAM декодеров из той же оперы. Взял тут лентопротяжник, охота сделать плату с операционниками на новой элементной базе так сказать, беда наверняка будет с моточными элементами, тем самым фильтром. Это явно не кольцо с намоткой челноком а скорее всего чашка с ферритовым подстроечником с каплей красной краски-фиксатором, поправьте если не так, вроде были такие, так как на обычном открытом радиочастотном каркасе, даже с ферритом, всё что в районе ближнего ультразвука мотать проблематично ввиду киловитков.
Вспоминайте - для нормальной загрузки необходимо взять маленькую отвёрточку и подкрутить угол у головки считывания-записи магнитофона, пока звук не становился более ярким и насыщенным. На стирания-подмагничивания вроде такого не было.
Можно попробовать также открытые проекты. В этом случае модель даже может проникнуть в исходники и уловить суть протколов 1. KiCAD - схемы и платы 2. FreeCAD - 3д модельки 3. Python+C/Java+shell - классика на которой тренируются все модели (По опыту Паскаль, bat/powershell и прочие - довольно плохо генерируются ввиду недостатка датасетов и хороших примеров) 4. LayoutEditor имеет в комплекте автороутер (запускается через java jar) он же FreeRouting - можно делать do-файлы Specctra. Роутит качественно, при должном указании атласа цепей ручная корректировка практически минимальна. Также можно попросить залить полигоны под процессорами, источниками питания итд 5. kipart - отличная штука, понимаемая многими моделями вплоть до генерации распиновки по картинке 6. локальный RAG на преобразователе pdftotext -layout input.pdf output.txt - нет ничего проще, формируется файл который можно отправить в qdrant создав векторную БД для модели (например на эмбеддере BAAI/bge-m3), читает даташиты и понимает что там написано для любой микрухи 7. Формат схематика для KiCAD - открытый, не нужно дополнительно пинать доки по API-Delphi для Altium, можно сгенерировать Питон который также нарисует схему или взять готовый например тут. Вплоть до использования локального автороутера который пробрасывает провода на схеме как если бы это была печатная плата. Достаточно расставить компоненты и соединить их по нетлисту (примерно как в Симулинке Матлаба при протаскивании и оптимизации).
Для простых задач сойдёт, но для большой сетки необходимо убрать численный разогрев - обеспечить везде нулевую дивергенцию поля (нет источников и приёмников, в этом методе эквивалентные магнитные монополи), это особенно важно вблизи поверхности магнита. Как раз именно там и считают потом силу, пригодную для моделирования электромотора, где самым главным рабочим элементом является... зазор. Плюс ещё эффективная магнитная проницаемость - сопряжение по поверхности. Ну и интегрирование обычно заменяют системой PDE, там где капризные корни - метод Ньютона-Рафсона с переменной сеткой.
Чем это отличается от q-формата обычной fractional arithmetic. Включая умножение например 8 на 8 = 16, далее умножение с накоплением (чтобы младшие разряды не потерять, особенно для градиентов) и потом снова на 8 бит. Получается формат q7 или q15 (знаковый). Можно также ввести q6 или q5 с "целой" частью, но это требует коррекции сдвигом после умножения. Нативный DSP например q15xq15=q31 преобразует сразу со сдвигом, без использования дополнительной команды. Либо в этой схеме это делается автоматом и это всё для ПЛИС, но там захардкоженные блоки умножения.
Абсолютно верно - только вот недавно тут возился с 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 - синус электрический конденсаторами и синус ему перпендикулярный магнитный катушками
Это было время одноразовых ПЗУ в виде картриджей для Денди. Кстати большинство проблем на Спектруме были те самые динамические ОЗУ 565й серии которые вылетали с любым чихом с завидной регулярностью. Там ещё от производителя зависело вроде несколько заводов их выпускали (корпусировали)
Да, Вы правы! Уже подзабыл схемотехнику, не открывая поиск навскидку - там есть LC фильтр-пробка, который развязывает ГВЧ с входом чтобы не сжечь его. А качество.. с учётом того что это были двухваттные магнитофоны 2 или 3 классов (Вега и ещё какой-то монофонический почти игрушечный), то музыка в ГДШ, который сам по себе ВФЧ, звучала уже без разницы как, хотя если покрутить угол то, конечно, ощущалась. Это уже потом появились монстры 100W PMPO на этих же динамиках, зато как круто читается! Сам Спекки подключался к телевизору Юность с диагональю примерно 15'' с 5-ти пиновым разъёмом как у магнитофона (переделан). Там на разъёме есть язычок который переключает ТВ или приставка, хотя тогда в ходу были ТВ-модуляторы. Вспоминается ещё время PAL-SECAM декодеров из той же оперы. Взял тут лентопротяжник, охота сделать плату с операционниками на новой элементной базе так сказать, беда наверняка будет с моточными элементами, тем самым фильтром. Это явно не кольцо с намоткой челноком а скорее всего чашка с ферритовым подстроечником с каплей красной краски-фиксатором, поправьте если не так, вроде были такие, так как на обычном открытом радиочастотном каркасе, даже с ферритом, всё что в районе ближнего ультразвука мотать проблематично ввиду киловитков.
Вспоминайте - для нормальной загрузки необходимо взять маленькую отвёрточку и подкрутить угол у головки считывания-записи магнитофона, пока звук не становился более ярким и насыщенным. На стирания-подмагничивания вроде такого не было.
Можно попробовать также открытые проекты. В этом случае модель даже может проникнуть в исходники и уловить суть протколов
1. KiCAD - схемы и платы
2. FreeCAD - 3д модельки
3. Python+C/Java+shell - классика на которой тренируются все модели (По опыту Паскаль, bat/powershell и прочие - довольно плохо генерируются ввиду недостатка датасетов и хороших примеров)
4. LayoutEditor имеет в комплекте автороутер (запускается через java jar) он же FreeRouting - можно делать do-файлы Specctra. Роутит качественно, при должном указании атласа цепей ручная корректировка практически минимальна. Также можно попросить залить полигоны под процессорами, источниками питания итд
5. kipart - отличная штука, понимаемая многими моделями вплоть до генерации распиновки по картинке
6. локальный RAG на преобразователе pdftotext -layout input.pdf output.txt - нет ничего проще, формируется файл который можно отправить в qdrant создав векторную БД для модели (например на эмбеддере BAAI/bge-m3), читает даташиты и понимает что там написано для любой микрухи
7. Формат схематика для KiCAD - открытый, не нужно дополнительно пинать доки по API-Delphi для Altium, можно сгенерировать Питон который также нарисует схему или взять готовый например тут. Вплоть до использования локального автороутера который пробрасывает провода на схеме как если бы это была печатная плата. Достаточно расставить компоненты и соединить их по нетлисту (примерно как в Симулинке Матлаба при протаскивании и оптимизации).
Для простых задач сойдёт, но для большой сетки необходимо убрать численный разогрев - обеспечить везде нулевую дивергенцию поля (нет источников и приёмников, в этом методе эквивалентные магнитные монополи), это особенно важно вблизи поверхности магнита. Как раз именно там и считают потом силу, пригодную для моделирования электромотора, где самым главным рабочим элементом является... зазор. Плюс ещё эффективная магнитная проницаемость - сопряжение по поверхности. Ну и интегрирование обычно заменяют системой PDE, там где капризные корни - метод Ньютона-Рафсона с переменной сеткой.
Чем это отличается от q-формата обычной fractional arithmetic. Включая умножение например 8 на 8 = 16, далее умножение с накоплением (чтобы младшие разряды не потерять, особенно для градиентов) и потом снова на 8 бит. Получается формат q7 или q15 (знаковый). Можно также ввести q6 или q5 с "целой" частью, но это требует коррекции сдвигом после умножения. Нативный DSP например q15xq15=q31 преобразует сразу со сдвигом, без использования дополнительной команды. Либо в этой схеме это делается автоматом и это всё для ПЛИС, но там захардкоженные блоки умножения.
Абсолютно верно - только вот недавно тут возился с 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 - синус электрический конденсаторами и синус ему перпендикулярный магнитный катушками