Так собственно расчёты в полной мере оправдались. Тактовая частота вычислителя и атомарных операций не растёт с начала нулевых и остаётся на полке 2-3 ГГц. Транзисторы GAA и прочие FinFet в экспериментальном варианте с субмикронными нормами это конец 90-х. Тогда собственно и было предсказано насыщение. Всё остальное - тонкая доводка. Как были редакторы образца Turbo C так и остались, как вводили программы перфолентой так и сейчас построчно набивать экран шрифтами. Концептуально мало что изменилось за эти 20 лет, проблема выросла вширь за счёт бо́льшего количества элементарных операций на кристалле. Параллелизм это уже финишняя черта развития. Вверх пластины не пойдут даже с интерпозерами, так как тепло отвести невозможно с плотностью под сотню Вт на кв. см., это преимущество только накопители-флешки. То есть всё что можно выжать уже практически выжато на классической технологии. Остаются квантовые и потенциально криогенные многослойные системы а также аналоговые предварительно обученные нейропроцессоры, но это уже отдельная не перфокартовая история.
Вы описали в некоторой мере метод формирования кода по данным, некий аналог синтеза по таблице истинности или конечного автомата по его диаграмме переходов. Если ИИ научится по индукции проверять код на заданные ограничения (исключение глюков), проводить локальное тестирование, выбирать между производительностью и объёмом памяти (ресурс-ориентированный подход), синтезировать алгоритм по промптам из разряда n, n log n, n^2, то тогда уже "проще самому" отойдёт на второй план. В этом случае почти не важна база на которой он это пишет, будь хоть Лисп, Бейсик или Верилог. Главным будет результат теста, бенчмарки и соответствия выходным данным (по сути ТЗ) в виде формального описания и того что обычно кладут в assertion или debug-обёртки, включая различные исключения.
Всё верно, зависит конечно от количества пользователей и на них можно переложить бремя затрат на электричество. И пока что пользователь готов за это платить, даже если будет миллион юзеров и с каждого по 100 руб месячной подписки получается 1e8 ₽, берём 5 руб/квтч получается 2e7 квтч или 2e10 втч или 2 ГВтч. Вообщем такой сбор покроет выпуск новой модели (только по электричеству без учёта серверных затрат, подготовку датасетов и команды). Но тут другой момент более существенный. Относительная скорость обучения падает с разрастанием серверной, так как длинный провод между стойками вносит свою задержку в десятки и сотни нс (это к тому что быстро и качественно обучать "распределённо" не получается). Плюс датацентр на 100 МВт это уже капитальное сооружение которое должно на 100% нагрузку отработать 20 часов только под задачу ИИ. Датацентр на 1 ГВт это уже что-то из разряда планов (кластер Prometheus, Lancium) с градирнями, ЛЭП под 500 кВ и кабельным хозяйством от Земли до Луны. И вот получается что потенциально имеется теоретическая предельная точка по объёму модели, потребляемой мощности и производительности, которая, как может оказаться, не привнесёт покрывающий эти затраты эффект. То есть просто хороший справочник и поисковик уже не актуален и требуется от сети качественно новый эффект синтеза нового нежели "понимания" имеющегося.
Всё гораздо проще - произошло смещение вектора задач для IT из области "сделай это" к "что бы сделать ещё". Когда был экспоненциальный рост первый принцип работал. Как появилась полка, началось растекание в плоскости, выбрать скруглённый прямоугольник или обточенный круг. Как ни парадоксально, "масштабирование Мура пятилетку за 2 года" застряло в начале нулевых для алгоритмов, требующих сортировку и поиск, с характерным не последовательным доступом в память. На то есть 2 причины - вместо прямоугольников уже кусочки синусов, определяющие частоту вычислителя порядка 3 ГГц и связанные с тем что под затвором уже несколько атомов примесей и CMOS-структуру уже крайне сложно сделать со стабильным параметром (плюс туннель через диэлектрик и сопротивление канала) а также скорость света, ограничивающая алгоритмы выбора указателя на указатель на указатель, то есть получить следующее значение из памяти можно только на основе предыдущего. В этом случае свет летит от процессора до плашки, например, 10 см туда-обратно, это 3 ГГц, но ещё надо поделить на корень из диэлектрической проницаемости текстолита, итого эффективно 1,5 в лучшем теоретическом случае, на практике это меньше 1 ГГц на уровне параллельной выборки конца 90-х. Таким образом, как бы вы не гоняли программистов, алгоритмистов, многостаночников-многопроцессорщиков, они могут только теперь заполнять последнюю нишу - многозадачные решения и параллелизм. Но и это уже сейчас также упирается в планку скорости света витой пары между серверными стойками на зависимым по данным доступе. Поэтому всё что наблюдается - прямое следствие этого застоя вот уже на протяжении 20 лет, добавить сюда легаси, практически неизменные среды и инструменты, древние стандарты, неповоротливость корпораций, то и получается что переливание из пустого в порожнее - это лучший бизнес-план.
Если смотреть на структуру ИИ то всё в основном определяется датасетами как основой для реализации, а она выражена на человеческом языке с возможностью вариаций. Поэтому, скорее всего, то что имеется сейчас будет крайне сложно масштабировать без изменения подхода к обучению ИИ и внутреннему представлению того что человек называет алгоритмом. Если посмотреть на техотчёт Дипсик [arXiv:2412.19437] - на обучение потрачено 3 млн машино-часов карточки H800, потребляющей, скажем 1 кВт (с учётом инфраструктуры) Итого имеем 3 ГВт*ч электричества для обучения только одной версии. Это конечно не сравнится с битком, но тенденция будет явная и скоро начнут все торговать некий токен-койн как монета для обучения ввиду ограничения ресурсов. Соответственно для более продвинутой потребуются уже сотни гигаватт-часов и сложность скорее всего растёт экспоненциально. Представьте главного админа, нажатие кнопки "learn" которого приведёт к годовой выработке условной Калининской АЭС.
Очень хороший и всесторонний тест для языка общего назначения - это self-hosted language, то есть который может скомпилировать сам себя. Там и работа с деревьями, текстом, числами , оптимизация. Конечно скриптовые делать такими бессмысленно, если это не библейский LISP, а вот новые компилирующие вполне могут поставить для себя такую задачу, включая общий анализ проекта и устранение сборки всего при изменении буквы в /*abc*/ . С и С++ сильны как раз этим, что обросли всевозможными приёмами и костылями проектного уровня а не конкретной программы, включая гиты, докеры, мейкеры, кодогенераторы-матлабы. В этом их уникальная гибкость.
Язык ещё более низкого уровня - это машинные коды непосредственно с переключателями или HEX-редактором и справочником команд. (Панелька для микросхемы - условная)
Лучше действительно такие новаторские эксперименты проводить, используя стандартные библиотеки и файловые системы как более низкоуровневый элемент или находящиеся в соседней песочнице и имитирующие то что нужно. Поэтому различные хранилища BLOB, базы данных и прочие облака фактически уже превратили всё в asyncio, вопрос только почему нет стандарта уровня posix/iso/ieee итд, пока что это не вышло за корпоративные рамки, хотя уже прошло достаточно времени.
Может вопрос немножко не совсем касается нововведения непосредственно, однако видится какая-то глобальная проблема с thread-safe очередями в Python. Первая конечно же по дефолту это multiprocessing.Queue, столкнувшись с удивительным временем в сотни миллисекунд на передачу пакетов данных в десяток килобайт пришлось искать альтернативы вроде faster-fifo, FMQ, рецепты multiprocessing.manager().Queue() и прочие танцы, но радикально проблему они решить не могли. По всей видимости, это связано с механизмами сериализации объектов Pickle или быть может даже особыми средствами ОС (Linux) которые осуществляют переключение. Есть ли какое-либо мнение на этот счёт и возникают ли подобного рода проблемы с субинтерпретаторами. Может действительно в некоторых случаях тогда применять просто shared memory, тогда это будет настоящая каша из двоичных объектов.
Вы совершенно правы, что нужно использовать линейную частоту вместо синонимов круговая-циклическая. Однако, небольшой экскурс даёт повод для сомнений, зачем множить сущности, если достаточно круговой. И тут можно выяснить, что циклическая определяется как заданное количество циклов за определённое время, в частности, по умолчанию, за 2π секунд, если не оговорено особо, но никто не запрещает, по всей видимости, это время задать самостоятельно. На это подтолкнул прямой перевод и ключевая фраза "Cyclic frequency", что даёт "Cyclic frequency refers to the frequency at which a signal's statistical properties repeat themselves, also known as a cyclostationary signal" и даже обозначается как α, однако, имеет отношение скорее к статистике см. "Cyclic Frequency in Signal Processing". Вообщем это не баг а фича для размышлений.
Спасибо, Евгений! Совершенно верно. Пусть ошибка останется в публикации, как тренировка по составлению уравнений. Действительно, для второго узла необходимо было записать уравнение
Ошибка в системе - найдено
Ну и конечно же всё получается как надо.
Тем не менее, метод подходит даже для "ошибочных схем". Для исправленного варианта получается предложенным методом амплитуда в точке 2 кГц 1.1484, фаза (результирующая!) -162°. SPICE модель даёт -121°, так как используется отношение выхода ко входу, при этом теряется фаза исходного сигнала, разница как раз составляет 40°. То есть при наличии параметра фазы во входном сигнале симулятор при анализе ФЧХ даст характеристику, как если бы начальная фаза входного сигнала была нулевой. Поправьте если это не так. Хотя лучше было бы если Probe в конкретной точке показывал полную фазу с учётом фазы входной ЭДС.
Схема нужна была для того чтобы сформировать некоторую передаточную функцию и сравнить это с моделью. По символическому анализу также можно найти SNAP, SymPyCAP, Sapwin, ELABorate, и другие скрипты для вытаскивания схемы из нетлистов.
Угловая - это скорость изменения угла в рад/с, циклическая - частота соответствующая одному циклу (периоду), поэтому в Гц. Ранее в книгах писали "Megacycles per second" MCps или тоже самое что МГц. Может быть circle и cycle в этом случае их сделали синонимами. Поэтому, чтобы не путаться, в данном случае явно было принято разделить круговую как рад/с и циклическую в Гц в пределах области видимости публикации. Кстати в SPICE-моделях m и M - это милли, meg, MEG - это мега, очень часто на этом возникают ошибки.
Вот кстати здесь Вы правы, что код, или текст, который был сгенерирован человеком или инструментом на основе ИИ, надо (а надо ли?) будет уметь различать. Но с точки зрения практической реализации, вполне себе можно использовать, если сформированный код компилируется и выполняет возложенные функции в заданных границах с автоматическим тестированием или имеет ключевые слова для решения задачи. Значимый результат - дообучение как обратная связь. И тут как раз сложные языки, с избыточными с точки зрения диалога с ЭВМ сущностями IMHO начинают проигрывать. Классы-наследование, функциональный подход, HDL-подобные языки, описывающие системы с событиями - это изобретения для человека, удобства проектирования и представления в голове целостной структуры проекта на языке... предметной области. Для машины не важно какие биты она перемалывает, важно то, чтобы она это делала оптимально по выбранному критерию, например, по соотношению время-память. И скорее эволюция сделает очередной виток с Basic-ом, Python-ом, обычным С, Verilog, LISP-Fortran, и даже визуальными языками такими как UML/LabView/Simulink, так как всё остальное будет отдано на растерзание оптимизатору с ИИ, благодаря гораздо более простой внутренней структуре результатов парсера в виде AST и его токенизации и к этому надо основательно готовиться.
Этот пример был приведён для того, что сложность языка дополняется сложностью задач для которых его применяют, включая аппаратуру. То есть курс "С++ за N дней для начинающих" и "С++ Embedded за M часов для юнатов" должны отличаться опытом длиной в X лет. Больше возможностей - относительно расплывчатая формулировка, например, уменьшается время внедрения новых сущностей в проект, удобство документации, командной разработки, меньшие требования к кандидатам на проект, вылавливание ошибок на этапе компиляции, простота отладки, наборы инструментов для профайлинга, визуализация данных. "Пишите программы, которые пишут программы" - (точно не помню где слоган был Керниган-Ричи или Пайк) скорее это и есть тот искомый сбалансированный инструмент для аппаратуры, наподобие GUI-генераторов инициализации контроллеров. Равно как первые плюсовые компиляторы, которые транслировали код на С. А что касается классического примера со статическим UI это скорее MFC/Borland образца 90-х с соответствующей рисовалкой ресурсов. То есть плюсы и этот подход в наибольшей мере сочетаются и не требуют особое обилие скиллов для достижения заданного результата, который даётся даже проще и быстрее чем Win32. Вообщем С++ без полного следования ООП (включая процесс проектирования на "бумаге" а-ля CRC-карточки и прочий UML) это С с классами. А также, С++ - это ещё и практически неотъемлемая инфраструктура в виде стандартной библиотеки. И именно в этом русле раскрывающий все свои преимущества, особенно, если проект дополняется сторонними средствами, без которых действительно потом страшновато разбирать и поддерживать код/данные, и не прибегать постоянно к приложениям из разряда "Understand for C++" и прочим Code Analysis.
Абсолютно верно. Особенно если приправить всё это register, volatile, и другими вроде как не выходящими за границы стандарта сущностями, включая карты линковки или директивы "размести элементы стандартной библиотеки в RAM, так как она быстрее флеша", контроль стека при рекурсии, при работе с оборудованием, периферией, DMA, это превращается в тот ещё квест, особенно когда появились соседние ядра. И вот тут дилемма С или С++. Вообщем С++ лучшим образом подходит скорее для статических UI, заранее заданных жёстких и строгих иерархий, обработки классов функциями требующих хорошее почти фортрановское быстродействие в одном потоке, для обработки пакетов с фиксированной иерархией данных. То есть баланс между временем на поддержание ООП, чтобы можно было что-то вклинить не сильно переписывающее весь код, файловую структуру, систему сборки, и быстродействием. Плюсовые thread-safe очереди-семафоры, мутексы, шедулеры скорее не цель а нечто, что генерируется из более высокого уровня как заведомо проверенное решение.
Вот тут может быть UB с точки зрения реализации. Если bool выполнен как один бит из ячейки в 32 бита, а компилятор вдруг решил что ему достаточно 2 команды по 16 бит, то на прерываниях между этими командами возможна редкая ситуация Read-Modify-Write, при чтениях и записях флажка из асинхронных событий. Тем более этот вектор вряд ли компилятор упаковывает эти булы в битовое поле, но с другой стороны исключается возможность модификации соседнего флажка из-за этой проблемы.
Именно так за небольшим нюансом. Г. Буч (ООП с использованием С++) подвёл некий базис под это и не отделяет наследование от поведения объектов (т. е. виртуальные функции обязательны, хотя бы одна), которые обладают состоянием, поведением и идентичностью. Иначе это просто структура в структуре и в полной мере им не является, хотя и допустимо, но это весьма условно. То есть при отсутствии наследования функций технически компилятор может не вводить неявное поле типа (идентификатор) в класс (ad-hoc полиморфизм и перегрузка также не задействует этот механизм). Кстати в нулевые были ещё пара ключевых книг, которые основательно определяли то что указано автором темы и кристаллизовали те проблемы, которые актуальны до сих пор вот уже на протяжении третьего десятка лет: С. Мейерс "Наиболее эффективное использование C++. 35 новых рекомендаций по улучшению ваших программ и проектов". И ещё одно издание этого же автора "Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ". Вот там как раз взаимосвязь языка с файловой системой, проблемы с компиляцией, то есть то что выходит за рамки языка и отнимает кучу времени в плане организации процесса проектирования.
Было бы неплохо сделать обзор может даже по условным git-проектам где есть примеры решения задач где используются концептуальные преимущества языка или по содержанию "диска прилагаемого к книге". В основном сейчас лучше изучить концепции из разряда "наследование - это неявное дополнительное поле типа, соответствующее номеру класса по желанию компилятора плюс массив указателей на процедуры или switch-case, реализующие виртуальные функции согласно этому полю", "рекурсия - это неявный стек, который располагается не совсем вручную", ну и разумеется механизмы лямбда, различных темплейтов что это не просто синтаксический сахар и форма макросов, и, конечно же, dynamic_cast и как правильно его готовить чтобы не было сегфолтов.
Так собственно расчёты в полной мере оправдались. Тактовая частота вычислителя и атомарных операций не растёт с начала нулевых и остаётся на полке 2-3 ГГц. Транзисторы GAA и прочие FinFet в экспериментальном варианте с субмикронными нормами это конец 90-х. Тогда собственно и было предсказано насыщение. Всё остальное - тонкая доводка. Как были редакторы образца Turbo C так и остались, как вводили программы перфолентой так и сейчас построчно набивать экран шрифтами. Концептуально мало что изменилось за эти 20 лет, проблема выросла вширь за счёт бо́льшего количества элементарных операций на кристалле. Параллелизм это уже финишняя черта развития. Вверх пластины не пойдут даже с интерпозерами, так как тепло отвести невозможно с плотностью под сотню Вт на кв. см., это преимущество только накопители-флешки. То есть всё что можно выжать уже практически выжато на классической технологии. Остаются квантовые и потенциально криогенные многослойные системы а также аналоговые предварительно обученные нейропроцессоры, но это уже отдельная не перфокартовая история.
Вы описали в некоторой мере метод формирования кода по данным, некий аналог синтеза по таблице истинности или конечного автомата по его диаграмме переходов. Если ИИ научится по индукции проверять код на заданные ограничения (исключение глюков), проводить локальное тестирование, выбирать между производительностью и объёмом памяти (ресурс-ориентированный подход), синтезировать алгоритм по промптам из разряда n, n log n, n^2, то тогда уже "проще самому" отойдёт на второй план. В этом случае почти не важна база на которой он это пишет, будь хоть Лисп, Бейсик или Верилог. Главным будет результат теста, бенчмарки и соответствия выходным данным (по сути ТЗ) в виде формального описания и того что обычно кладут в assertion или debug-обёртки, включая различные исключения.
Всё верно, зависит конечно от количества пользователей и на них можно переложить бремя затрат на электричество. И пока что пользователь готов за это платить, даже если будет миллион юзеров и с каждого по 100 руб месячной подписки получается 1e8 ₽, берём 5 руб/квтч получается 2e7 квтч или 2e10 втч или 2 ГВтч. Вообщем такой сбор покроет выпуск новой модели (только по электричеству без учёта серверных затрат, подготовку датасетов и команды). Но тут другой момент более существенный. Относительная скорость обучения падает с разрастанием серверной, так как длинный провод между стойками вносит свою задержку в десятки и сотни нс (это к тому что быстро и качественно обучать "распределённо" не получается). Плюс датацентр на 100 МВт это уже капитальное сооружение которое должно на 100% нагрузку отработать 20 часов только под задачу ИИ. Датацентр на 1 ГВт это уже что-то из разряда планов (кластер Prometheus, Lancium) с градирнями, ЛЭП под 500 кВ и кабельным хозяйством от Земли до Луны. И вот получается что потенциально имеется теоретическая предельная точка по объёму модели, потребляемой мощности и производительности, которая, как может оказаться, не привнесёт покрывающий эти затраты эффект. То есть просто хороший справочник и поисковик уже не актуален и требуется от сети качественно новый эффект синтеза нового нежели "понимания" имеющегося.
Спасибо за совет, иногда лень искать полезные мелочи ). Конечно же есть переменная среды Maxima, которая отвечает за количество выводимых знаков:
Всё гораздо проще - произошло смещение вектора задач для IT из области "сделай это" к "что бы сделать ещё". Когда был экспоненциальный рост первый принцип работал. Как появилась полка, началось растекание в плоскости, выбрать скруглённый прямоугольник или обточенный круг. Как ни парадоксально, "масштабирование Мура
пятилеткуза 2 года" застряло в начале нулевых для алгоритмов, требующих сортировку и поиск, с характерным не последовательным доступом в память. На то есть 2 причины - вместо прямоугольников уже кусочки синусов, определяющие частоту вычислителя порядка 3 ГГц и связанные с тем что под затвором уже несколько атомов примесей и CMOS-структуру уже крайне сложно сделать со стабильным параметром (плюс туннель через диэлектрик и сопротивление канала) а также скорость света, ограничивающая алгоритмы выбора указателя на указатель на указатель, то есть получить следующее значение из памяти можно только на основе предыдущего. В этом случае свет летит от процессора до плашки, например, 10 см туда-обратно, это 3 ГГц, но ещё надо поделить на корень из диэлектрической проницаемости текстолита, итого эффективно 1,5 в лучшем теоретическом случае, на практике это меньше 1 ГГц на уровне параллельной выборки конца 90-х. Таким образом, как бы вы не гоняли программистов, алгоритмистов, многостаночников-многопроцессорщиков, они могут только теперь заполнять последнюю нишу - многозадачные решения и параллелизм. Но и это уже сейчас также упирается в планку скорости света витой пары между серверными стойками на зависимым по данным доступе. Поэтому всё что наблюдается - прямое следствие этого застоя вот уже на протяжении 20 лет, добавить сюда легаси, практически неизменные среды и инструменты, древние стандарты, неповоротливость корпораций, то и получается что переливание из пустого в порожнее - это лучший бизнес-план.Если смотреть на структуру ИИ то всё в основном определяется датасетами как основой для реализации, а она выражена на человеческом языке с возможностью вариаций. Поэтому, скорее всего, то что имеется сейчас будет крайне сложно масштабировать без изменения подхода к обучению ИИ и внутреннему представлению того что человек называет алгоритмом. Если посмотреть на техотчёт Дипсик [arXiv:2412.19437] - на обучение потрачено 3 млн машино-часов карточки H800, потребляющей, скажем 1 кВт (с учётом инфраструктуры) Итого имеем 3 ГВт*ч электричества для обучения только одной версии. Это конечно не сравнится с битком, но тенденция будет явная и скоро начнут все торговать некий токен-койн как монета для обучения ввиду ограничения ресурсов. Соответственно для более продвинутой потребуются уже сотни гигаватт-часов и сложность скорее всего растёт экспоненциально. Представьте главного админа, нажатие кнопки "learn" которого приведёт к годовой выработке условной Калининской АЭС.
Очень хороший и всесторонний тест для языка общего назначения - это self-hosted language, то есть который может скомпилировать сам себя. Там и работа с деревьями, текстом, числами , оптимизация. Конечно скриптовые делать такими бессмысленно, если это не библейский LISP, а вот новые компилирующие вполне могут поставить для себя такую задачу, включая общий анализ проекта и устранение сборки всего при изменении буквы в /*abc*/ . С и С++ сильны как раз этим, что обросли всевозможными приёмами и костылями проектного уровня а не конкретной программы, включая гиты, докеры, мейкеры, кодогенераторы-матлабы. В этом их уникальная гибкость.
Язык ещё более низкого уровня - это машинные коды непосредственно с переключателями или HEX-редактором и справочником команд. (Панелька для микросхемы - условная)
Лучше действительно такие новаторские эксперименты проводить, используя стандартные библиотеки и файловые системы как более низкоуровневый элемент или находящиеся в соседней песочнице и имитирующие то что нужно. Поэтому различные хранилища BLOB, базы данных и прочие облака фактически уже превратили всё в asyncio, вопрос только почему нет стандарта уровня posix/iso/ieee итд, пока что это не вышло за корпоративные рамки, хотя уже прошло достаточно времени.
Может вопрос немножко не совсем касается нововведения непосредственно, однако видится какая-то глобальная проблема с thread-safe очередями в Python. Первая конечно же по дефолту это multiprocessing.Queue, столкнувшись с удивительным временем в сотни миллисекунд на передачу пакетов данных в десяток килобайт пришлось искать альтернативы вроде faster-fifo, FMQ, рецепты multiprocessing.manager().Queue() и прочие танцы, но радикально проблему они решить не могли. По всей видимости, это связано с механизмами сериализации объектов Pickle или быть может даже особыми средствами ОС (Linux) которые осуществляют переключение. Есть ли какое-либо мнение на этот счёт и возникают ли подобного рода проблемы с субинтерпретаторами. Может действительно в некоторых случаях тогда применять просто shared memory, тогда это будет настоящая каша из двоичных объектов.
Вы совершенно правы, что нужно использовать линейную частоту вместо синонимов круговая-циклическая. Однако, небольшой экскурс даёт повод для сомнений, зачем множить сущности, если достаточно круговой. И тут можно выяснить, что циклическая определяется как заданное количество циклов за определённое время, в частности, по умолчанию, за 2π секунд, если не оговорено особо, но никто не запрещает, по всей видимости, это время задать самостоятельно. На это подтолкнул прямой перевод и ключевая фраза "Cyclic frequency", что даёт "Cyclic frequency refers to the frequency at which a signal's statistical properties repeat themselves, also known as a cyclostationary signal" и даже обозначается как α, однако, имеет отношение скорее к статистике см. "Cyclic Frequency in Signal Processing". Вообщем это не баг а фича для размышлений.
Спасибо, Евгений! Совершенно верно. Пусть ошибка останется в публикации, как тренировка по составлению уравнений. Действительно, для второго узла необходимо было записать уравнение
Ну и конечно же всё получается как надо.
Тем не менее, метод подходит даже для "ошибочных схем". Для исправленного варианта получается предложенным методом амплитуда в точке 2 кГц 1.1484, фаза (результирующая!) -162°. SPICE модель даёт -121°, так как используется отношение выхода ко входу, при этом теряется фаза исходного сигнала, разница как раз составляет 40°. То есть при наличии параметра фазы во входном сигнале симулятор при анализе ФЧХ даст характеристику, как если бы начальная фаза входного сигнала была нулевой. Поправьте если это не так. Хотя лучше было бы если Probe в конкретной точке показывал полную фазу с учётом фазы входной ЭДС.
Схема нужна была для того чтобы сформировать некоторую передаточную функцию и сравнить это с моделью.
По символическому анализу также можно найти SNAP, SymPyCAP, Sapwin, ELABorate, и другие скрипты для вытаскивания схемы из нетлистов.
Угловая - это скорость изменения угла в рад/с, циклическая - частота соответствующая одному циклу (периоду), поэтому в Гц. Ранее в книгах писали "Megacycles per second" MCps или тоже самое что МГц. Может быть circle и cycle в этом случае их сделали синонимами. Поэтому, чтобы не путаться, в данном случае явно было принято разделить круговую как рад/с и циклическую в Гц в пределах области видимости публикации. Кстати в SPICE-моделях m и M - это милли, meg, MEG - это мега, очень часто на этом возникают ошибки.
Вот кстати здесь Вы правы, что код, или текст, который был сгенерирован человеком или инструментом на основе ИИ, надо (а надо ли?) будет уметь различать. Но с точки зрения практической реализации, вполне себе можно использовать, если сформированный код компилируется и выполняет возложенные функции в заданных границах с автоматическим тестированием или имеет ключевые слова для решения задачи. Значимый результат - дообучение как обратная связь. И тут как раз сложные языки, с избыточными с точки зрения диалога с ЭВМ сущностями IMHO начинают проигрывать. Классы-наследование, функциональный подход, HDL-подобные языки, описывающие системы с событиями - это изобретения для человека, удобства проектирования и представления в голове целостной структуры проекта на языке... предметной области. Для машины не важно какие биты она перемалывает, важно то, чтобы она это делала оптимально по выбранному критерию, например, по соотношению время-память. И скорее эволюция сделает очередной виток с Basic-ом, Python-ом, обычным С, Verilog, LISP-Fortran, и даже визуальными языками такими как UML/LabView/Simulink, так как всё остальное будет отдано на растерзание оптимизатору с ИИ, благодаря гораздо более простой внутренней структуре результатов парсера в виде AST и его токенизации и к этому надо основательно готовиться.
Этот пример был приведён для того, что сложность языка дополняется сложностью задач для которых его применяют, включая аппаратуру. То есть курс "С++ за N дней для начинающих" и "С++ Embedded за M часов для юнатов" должны отличаться опытом длиной в X лет. Больше возможностей - относительно расплывчатая формулировка, например, уменьшается время внедрения новых сущностей в проект, удобство документации, командной разработки, меньшие требования к кандидатам на проект, вылавливание ошибок на этапе компиляции, простота отладки, наборы инструментов для профайлинга, визуализация данных. "Пишите программы, которые пишут программы" - (точно не помню где слоган был Керниган-Ричи или Пайк) скорее это и есть тот искомый сбалансированный инструмент для аппаратуры, наподобие GUI-генераторов инициализации контроллеров. Равно как первые плюсовые компиляторы, которые транслировали код на С. А что касается классического примера со статическим UI это скорее MFC/Borland образца 90-х с соответствующей рисовалкой ресурсов. То есть плюсы и этот подход в наибольшей мере сочетаются и не требуют особое обилие скиллов для достижения заданного результата, который даётся даже проще и быстрее чем Win32. Вообщем С++ без полного следования ООП (включая процесс проектирования на "бумаге" а-ля CRC-карточки и прочий UML) это С с классами. А также, С++ - это ещё и практически неотъемлемая инфраструктура в виде стандартной библиотеки. И именно в этом русле раскрывающий все свои преимущества, особенно, если проект дополняется сторонними средствами, без которых действительно потом страшновато разбирать и поддерживать код/данные, и не прибегать постоянно к приложениям из разряда "Understand for C++" и прочим Code Analysis.
Абсолютно верно. Особенно если приправить всё это register, volatile, и другими вроде как не выходящими за границы стандарта сущностями, включая карты линковки или директивы "размести элементы стандартной библиотеки в RAM, так как она быстрее флеша", контроль стека при рекурсии, при работе с оборудованием, периферией, DMA, это превращается в тот ещё квест, особенно когда появились соседние ядра. И вот тут дилемма С или С++. Вообщем С++ лучшим образом подходит скорее для статических UI, заранее заданных жёстких и строгих иерархий, обработки классов функциями требующих хорошее почти фортрановское быстродействие в одном потоке, для обработки пакетов с фиксированной иерархией данных. То есть баланс между временем на поддержание ООП, чтобы можно было что-то вклинить не сильно переписывающее весь код, файловую структуру, систему сборки, и быстродействием. Плюсовые thread-safe очереди-семафоры, мутексы, шедулеры скорее не цель а нечто, что генерируется из более высокого уровня как заведомо проверенное решение.
Вот тут может быть UB с точки зрения реализации. Если bool выполнен как один бит из ячейки в 32 бита, а компилятор вдруг решил что ему достаточно 2 команды по 16 бит, то на прерываниях между этими командами возможна редкая ситуация Read-Modify-Write, при чтениях и записях флажка из асинхронных событий. Тем более этот вектор вряд ли компилятор упаковывает эти булы в битовое поле, но с другой стороны исключается возможность модификации соседнего флажка из-за этой проблемы.
Именно так за небольшим нюансом. Г. Буч (ООП с использованием С++) подвёл некий базис под это и не отделяет наследование от поведения объектов (т. е. виртуальные функции обязательны, хотя бы одна), которые обладают состоянием, поведением и идентичностью. Иначе это просто структура в структуре и в полной мере им не является, хотя и допустимо, но это весьма условно. То есть при отсутствии наследования функций технически компилятор может не вводить неявное поле типа (идентификатор) в класс (ad-hoc полиморфизм и перегрузка также не задействует этот механизм). Кстати в нулевые были ещё пара ключевых книг, которые основательно определяли то что указано автором темы и кристаллизовали те проблемы, которые актуальны до сих пор вот уже на протяжении третьего десятка лет: С. Мейерс "Наиболее эффективное использование C++. 35 новых рекомендаций по улучшению ваших программ и проектов". И ещё одно издание этого же автора "Эффективное использование C++. 55 верных способов улучшить структуру и код ваших программ". Вот там как раз взаимосвязь языка с файловой системой, проблемы с компиляцией, то есть то что выходит за рамки языка и отнимает кучу времени в плане организации процесса проектирования.
Было бы неплохо сделать обзор может даже по условным git-проектам где есть примеры решения задач где используются концептуальные преимущества языка или по содержанию "диска прилагаемого к книге". В основном сейчас лучше изучить концепции из разряда "наследование - это неявное дополнительное поле типа, соответствующее номеру класса по желанию компилятора плюс массив указателей на процедуры или switch-case, реализующие виртуальные функции согласно этому полю", "рекурсия - это неявный стек, который располагается не совсем вручную", ну и разумеется механизмы лямбда, различных темплейтов что это не просто синтаксический сахар и форма макросов, и, конечно же, dynamic_cast и как правильно его готовить чтобы не было сегфолтов.
А кто помнит знаменитую надпись "Cracked by Bill Gilbert"