Эта статья рассчитана на подготовленного читателя, который уже знает (в университете это изучается), что такое метод наименьших квадратов, и умеет его применять (обычно с помощью компьютера — есть соответствующие программные пакеты и библиотеки).
В описаниях численных методов в литературе и научной периодике обычно приводится только теория и формулы. Опять же, подготовленному читателю именно это и нужно. Он сам потом сможет реализовать всё это в виде программы для компьютера.
Я тоже думал применить к данной задаче метод множителей Лагранжа, но есть подозрение, что это приведет к нелинейным уравнениям, которые потом будет трудно решать. Детально не проверял.
Это другая задача. Я решал не задачу интерполяции, а задачу аппроксимации. Интерполяция проходит через все точки, аппроксимация — нет. В том и в другом есть преимущества. Каждому инструменту — свое применение.
Иногда прохождение через все точки нежелательно. Данные могут содержать ошибки измерений. Невыгодно подгонять модель под случайные погрешности. Это приводит к проблемам, известным под названием "Overfitting".
За ссылку спасибо. Тоже интересный метод. Может пригодиться в подходящих обстоятельствах.
Из некоторых «других» состояний обратный переход в «одни» состояния невозможен. В природе есть необратимые процессы. Например, это передача тепла от горячего тела к холодному: в обратную сторону тепло не пойдёт без компенсирующих изменений в окружающей среде. Поэтому то, что энергия, вроде бы, «не расходуется» — это слабое утешение. Ведь провести необратимый процесс можно только один раз. См. также "Второе начало термодинамики". Есть также понятия «Свободная энергия Гельмгольца» и «Свободная энергия Гиббса» — это та часть полной энергии системы, которую можно из неё извлечь в виде механической работы. В ходе необратимых процессов свободная энергия уменьшается. Когда она достигает минимума, энергию извлечь из системы невозможно, и толку от того, что она там есть — никакого. Пример: мировой океан имеет температуру выше абсолютного нуля. Ввиду огромной теплоёмкости воды, охлаждение океана даже на 1°С решило бы все энергетические проблемы человечества. Но эта энергия не свободная, и извлечь её из океана в виде механической работы имеющимися технологиями невозможно (хотя в принципе возможно, так как температура реликтового излучения составляет 4K). Поэтому толку от энергии океана никакого.
В самом деле, перевод из двоичной в десятичную систему — это весьма дорогая операция. И, если расчёт числа очков (или любой другой величины) по затратам процессорного времени сопоставим с преобразованием двоичного числа в десятичное — то тут сам доктор прописал использовать двоично-десятичное представление. Возьму на вооружение, спасибо!
Вы серьёзно? Вы никогда не встречали людей, которые судятся с работодателями и выигрывают, получая от работодателя компенсации за вынужденный прогул, возмещение морального вреда и т.д., и продолжают после этого работать на прежнем месте?
Во-первых, память размещена на одном кристалле с микроконтроллером, то есть лезть придётся внутрь чипа. Отсоединить от шины данных не получится; но, может быть, с помощью микрощупов можно подключиться и перебить сигналы. Ничто не мешает, конечно, но порог вхождения гораздо выше. Нужно иметь оснащение, как завод или институт микротехнологии.
И даже, если считать свойства конкретного блока памяти — то их нельзя повторить на другом кристалле. Из-за технологического разброса даже разные чипы с одной пластины будут иметь различное начальное содержимое при включении.
Интересно, а насколько сильно влияет на состояние памяти динамика процесса подачи питания?
Скажем, питание нарастает от нуля до номинала быстро, или не очень быстро, или по заданной кривой. Если эта зависимость сильна — то надо ещё учитывать старение источника питания. Сюда входит изменение ёмкости конденсаторов, особенно электролитов, которые сильно подвержены старению.
К старению, думаю, можно как-то подстроиться. Скажем, если данные медленно дрейфуют — то производить замену секретных ключей время от времени, опираясь на пока ещё действующий старый ключ.
Если в системе есть аналоговая часть — то на её основе тоже можно делать защиту. Например, нелинейность АЦП или ЦАП; напряжение смещения операционных усилителей, время задержки прохождения сигнала и т.д. — все те эффекты, против которых инженеры обычно борются.
Гипотеза симуляции принципиально неопровержима и уже потому не подходит по критерию Поппера в качестве научной. В качестве научной может быть взята обратная гипотеза, что мы не находимся в симуляции. Её уже опровергнуть можно — например, если существа из внешнего мира свяжутся с нами и непосредственно покажут/докажут нам обратное.
Также, по принципу бритвы Оккама, нам следует пытаться объяснять Вселенную наиболее простыми возможными способами. Симуляция не упрощает, а усложняет познание мира. Ведь к задачам познания нашей Вселенной, которые и без того трудны, добавятся задачи познания деталей нашей симуляции, а также той вселенной, в которой находится симулятор. Поэтому следует предполагать, что мы не находимся в симуляции, пока не будет доказано обратное.
Но ведь уже есть законы, которые регулируют этот вопрос. Есть понятие рабочего времени, в течение которого работник обязан быть на рабочем месте и выполнять работу. Всё остальное время работника является свободным, и он не обязан ни присутствовать, ни быть на связи. Просто игнорировать звонки. За это наказать по закону нельзя.
А если работник позволяет противозаконно вешать на себя обязанности — то и дополнительный закон о «праве на оффлайн» не поможет, так как он будет нарушаться точно так же.
Защита работника подразумевает с его стороны какую-то инициативу (жалобу написать и т.п.). Но, если работник боится вызвать гнев начачльства — то не будет он жалобу писать.
Закон поможет разве что хитрым сутяжникам, которые не боятся конфликта с начальством и потому могли бы и без новых законов защитить своё право на свободное время. Такие хитрые сотрудники будут ловить работодателей на нарушениях, а потом вытряхивать из них компенсацию.
Процессоры без инструкций умножения появились раньше тех, что с умножением. Например, это i8080, 6502, Z80 и прочие 8-битки, на основе которых делались домашние и школьные компьютеры 80х гг.
А потом появились микроконтроллеры. Большинство 8-битных МК не имело инструкций умножения.
Поэтому вашим изобретением люди пользовались с незапамятных времён вплоть до середены-конца 2000х, когда массовые микроконтроллеры обзавелись аппаратными умножителями.
Помимо отсутствия инструкции умножения, отсутствовал также сдвиг на произвольное количество бит за один машинный цикл. Аппаратно такой сдвиг реализовать почти так же сложно, как и умножитель. Сдвигать можно было только на один бит. Можно было сдвигать несколько раз на один бит, но за каждый сдвиг надо было тратить машинный цикл.
Ещё отсутствовала команда поиска первого установленного бита.
С использованием только команд сдвига на один разряд и команд проверки одного бита алгоритмы умножения программировались немного по-другому, хотя суть была такой же — умножение в столбик.
А ещё были хитрые трюки для ускорения умножения. Например, используя тождество (a+b)^2=a^2+2*a*b+b^2, можно было, имея способ быстрого возведения в квадрат (обычно с помощью таблицы квадратов) реализовать умножение.
Безусловно, вы правы. Здесь важно направление движения: по возможности избавляться от написанного человеком кода. Представлять исходные данные в предельно компактной и наглядной форме. Так, чтобы их было легко проверить и так, чтобы любая ошибка в них имела явные и легко воспроизводимые последствия. Тогда она будет быстро обнаружена при испытаниях.
по опыту, в красоте и лаконичности код таки потеряет
Такие вещи лучше на примерах обсуждать, чтобы была предметная дискуссия.
Возможно, в некоторых задачах потеряет. Не спорю. Например, реализация FFT на C++ выглядит гораздо красивее и понятнее за счёт перегрузки операторов при работе с комплексными числами. В C для этого приходится использовать функции или макросы, что делает формулы с комплексными числами нечитаемыми.
Но в тех задачах, где я выбрал C, я сначала окинул взглядом ситуацию и понял, что большой пользы там от плюсов не будет. Так и вышло.
Особенно если вам нужна производительность, и в плюсах вам можно было бы использовать темплейты
Темплейты и производительность, как мне кажется — это несвязанные между собой вещи. Никакой темплейт не может работать быстрее ручной специализированной реализации алгоритма.
Кодогенерация — это хорошо, но, как и любой инструмент, она решает специфические задачи. Вы не знаете, какие конкретно задачи я решаю, и какие при этом требуются инструменты, а я не знаю, какие решаете вы. Думаю, что лучше вести дискуссию с конкретными примерами, чтобы было понятнее, о чём речь.
А ООП можно и на C. Структуры вместо классов, вместо виртуальных функций — явная реализация Vtable (хотя мне не приходилось пока прибегать к этому приёму).
Да я ничего не изобрёл, просто освоил приёмы, десятилетиями применявшиеся до этого в C-проектах. Многое почерпнул, изучая исходники ядра ReactOS, ещё LwIP. Это другая философия, другой мир, отличный от «плюсов».
Статью писать… Спасибо за предолжение, можно попробовать. Подумаю, что можно в такую статью включить.
Не всякая задача в системе реального времени является критичной. В примере с чайником, при посадке на Луну критичным является включение/выключение маневровых двигателей. А сообщения из ЦУПа могут подождать, а то и вовсе быть выброшенными.
Ха-ха, у меня тоже было такое чувство, когда переходил на C после долгой работы на C++.
Ничего, привык за пару месяцев. Более того, мне понравилось! Оказалось, без контейнеров и умных указателей прекрасно можно жить; более того, нет расхода ресурсов контроллера на все эти модные вещи! Сейчас работаю с довольно большими проектами на сотни тысяч строк C-кода. Ни одного malloc! Вся память выделяется или статически, или на стеке, или из пулов большими блоками.
А когда пришлось снова писать код для PC, и была возможность опять взять C++ с его умными указателями и контейнерами — я отказался от этого. Прикинул и понял, что все задачи можно решить теми же приёмами, которые используются в микроконтроллерах. И код вовсе не потеряет от этого в красоте и лаконичности.
Мне один чел рассказывал, какие в аэрокосмической отрасли на Западе нынче используются подходы к программированию. Главная установка: «не писать код».
В самом деле, любой код, написанный человеком, содержит ошибки и потому ненадёжен. Повсеместно используются инструменты автоматической генерации кода на базе исходных данных, которые имеют предельно краткое и наглядное представление.
Например: если в системе обрабатывается сигнал — то в графическом виде задаётся путь прохождения этого сигнала и совершаемые над ним действия.
Кроме того, используется тестирование вида «Hardware in the loop». Для каждого блока управления создаётся испытательный стенд, который подаёт ему на вход тест-сигналы и сравнивает выходные сигналы с эталонными.
В описаниях численных методов в литературе и научной периодике обычно приводится только теория и формулы. Опять же, подготовленному читателю именно это и нужно. Он сам потом сможет реализовать всё это в виде программы для компьютера.
Иногда прохождение через все точки нежелательно. Данные могут содержать ошибки измерений. Невыгодно подгонять модель под случайные погрешности. Это приводит к проблемам, известным под названием "Overfitting".
За ссылку спасибо. Тоже интересный метод. Может пригодиться в подходящих обстоятельствах.
В самом деле, перевод из двоичной в десятичную систему — это весьма дорогая операция. И, если расчёт числа очков (или любой другой величины) по затратам процессорного времени сопоставим с преобразованием двоичного числа в десятичное — то тут сам доктор прописал использовать двоично-десятичное представление. Возьму на вооружение, спасибо!
Вот пара ссылок на судебные решения:
sudact.ru/regular/doc/8yqeyELkJ15Y
sudact.ru/regular/doc/spOIIYjzHb11
В интернете легко найти много подобных.
И даже, если считать свойства конкретного блока памяти — то их нельзя повторить на другом кристалле. Из-за технологического разброса даже разные чипы с одной пластины будут иметь различное начальное содержимое при включении.
Интересно, а насколько сильно влияет на состояние памяти динамика процесса подачи питания?
Скажем, питание нарастает от нуля до номинала быстро, или не очень быстро, или по заданной кривой. Если эта зависимость сильна — то надо ещё учитывать старение источника питания. Сюда входит изменение ёмкости конденсаторов, особенно электролитов, которые сильно подвержены старению.
К старению, думаю, можно как-то подстроиться. Скажем, если данные медленно дрейфуют — то производить замену секретных ключей время от времени, опираясь на пока ещё действующий старый ключ.
Если в системе есть аналоговая часть — то на её основе тоже можно делать защиту. Например, нелинейность АЦП или ЦАП; напряжение смещения операционных усилителей, время задержки прохождения сигнала и т.д. — все те эффекты, против которых инженеры обычно борются.
Также, по принципу бритвы Оккама, нам следует пытаться объяснять Вселенную наиболее простыми возможными способами. Симуляция не упрощает, а усложняет познание мира. Ведь к задачам познания нашей Вселенной, которые и без того трудны, добавятся задачи познания деталей нашей симуляции, а также той вселенной, в которой находится симулятор. Поэтому следует предполагать, что мы не находимся в симуляции, пока не будет доказано обратное.
А если работник позволяет противозаконно вешать на себя обязанности — то и дополнительный закон о «праве на оффлайн» не поможет, так как он будет нарушаться точно так же.
Защита работника подразумевает с его стороны какую-то инициативу (жалобу написать и т.п.). Но, если работник боится вызвать гнев начачльства — то не будет он жалобу писать.
Закон поможет разве что хитрым сутяжникам, которые не боятся конфликта с начальством и потому могли бы и без новых законов защитить своё право на свободное время. Такие хитрые сотрудники будут ловить работодателей на нарушениях, а потом вытряхивать из них компенсацию.
А потом появились микроконтроллеры. Большинство 8-битных МК не имело инструкций умножения.
Поэтому вашим изобретением люди пользовались с незапамятных времён вплоть до середены-конца 2000х, когда массовые микроконтроллеры обзавелись аппаратными умножителями.
Помимо отсутствия инструкции умножения, отсутствовал также сдвиг на произвольное количество бит за один машинный цикл. Аппаратно такой сдвиг реализовать почти так же сложно, как и умножитель. Сдвигать можно было только на один бит. Можно было сдвигать несколько раз на один бит, но за каждый сдвиг надо было тратить машинный цикл.
Ещё отсутствовала команда поиска первого установленного бита.
С использованием только команд сдвига на один разряд и команд проверки одного бита алгоритмы умножения программировались немного по-другому, хотя суть была такой же — умножение в столбик.
А ещё были хитрые трюки для ускорения умножения. Например, используя тождество (a+b)^2=a^2+2*a*b+b^2, можно было, имея способ быстрого возведения в квадрат (обычно с помощью таблицы квадратов) реализовать умножение.
Такие вещи лучше на примерах обсуждать, чтобы была предметная дискуссия.
Возможно, в некоторых задачах потеряет. Не спорю. Например, реализация FFT на C++ выглядит гораздо красивее и понятнее за счёт перегрузки операторов при работе с комплексными числами. В C для этого приходится использовать функции или макросы, что делает формулы с комплексными числами нечитаемыми.
Но в тех задачах, где я выбрал C, я сначала окинул взглядом ситуацию и понял, что большой пользы там от плюсов не будет. Так и вышло.
Темплейты и производительность, как мне кажется — это несвязанные между собой вещи. Никакой темплейт не может работать быстрее ручной специализированной реализации алгоритма.
Кодогенерация — это хорошо, но, как и любой инструмент, она решает специфические задачи. Вы не знаете, какие конкретно задачи я решаю, и какие при этом требуются инструменты, а я не знаю, какие решаете вы. Думаю, что лучше вести дискуссию с конкретными примерами, чтобы было понятнее, о чём речь.
Статью писать… Спасибо за предолжение, можно попробовать. Подумаю, что можно в такую статью включить.
Ничего, привык за пару месяцев. Более того, мне понравилось! Оказалось, без контейнеров и умных указателей прекрасно можно жить; более того, нет расхода ресурсов контроллера на все эти модные вещи! Сейчас работаю с довольно большими проектами на сотни тысяч строк C-кода. Ни одного malloc! Вся память выделяется или статически, или на стеке, или из пулов большими блоками.
А когда пришлось снова писать код для PC, и была возможность опять взять C++ с его умными указателями и контейнерами — я отказался от этого. Прикинул и понял, что все задачи можно решить теми же приёмами, которые используются в микроконтроллерах. И код вовсе не потеряет от этого в красоте и лаконичности.
В самом деле, любой код, написанный человеком, содержит ошибки и потому ненадёжен. Повсеместно используются инструменты автоматической генерации кода на базе исходных данных, которые имеют предельно краткое и наглядное представление.
Например: если в системе обрабатывается сигнал — то в графическом виде задаётся путь прохождения этого сигнала и совершаемые над ним действия.
Кроме того, используется тестирование вида «Hardware in the loop». Для каждого блока управления создаётся испытательный стенд, который подаёт ему на вход тест-сигналы и сравнивает выходные сигналы с эталонными.