Небольшая ремарка насчёт matplotlib: вы уже указали label при вызове plt.plot(), поэтому достаточно вызвать plt.legend(), чтобы сгенерировать автоматическую легенду. Такое использование гораздо лаконичнее.
Ещё одна ремарка относительно PID: для контроллеров обычно используют целочисленную арифметику. Если уже считаете с плавающей точкой, то для накопительных переменных надо брать число с большей точностью для избежания переполнения, иначе малые приросты просто перестанут менять перменную.
Мне не очень понятно, чем хороши персональные сказки. Мои дети, уже школьники, слушают сказки и длинные повествования почти каждый день, начиная с полутора лет. Таким образом, я знакомлю их с фундаментальными истинами, которые в них заложены. В частности, это центральная тема исследований Карла Юнга, Джозефа Кэмпбэлла и Джордана Питерсона.
А чем хороши для ребёнка надуманные сказки? Я ещё могу представить, что в каких-то случаях с ребёнком занимается психотерапевт и он подбирает ему истории конкретно под его потребности. Но неужели современный человек ("мамкин сказочник") вот так просто создаст историю с фундаментальной истиной, которую будут пересказывать веками? Каждая история должна пройти долгий путь отбора и пересказывания, прежде чем она изменится настолько, чтобы действительно выражать истину.
Во-первых, ваш акселерометр показывает не только динамическое ускорение, но и статическое от притяжения к земле. Для того, чтобы изъять его динамические показания, надо также пользоваться гироскопом. Во-вторых, акселерометр даёт такую точность, что если вы проведёте его по одной из осей, скажем, на метр, то после двойной интеграции окажется, что он проехал на 2/3 метра. В-третьих, для объединения показаний разных приборов надо не усреднять, а строить фильтр Калмана - только в этом случае финальная точность будет выше, чем у каждого из показаний по отдельности.
Причём интересно, что самый лучший из увольняемых сотрудников (по выделенным метрикам) - бездельник и прогульщик работы, а самый худший из оставшихся уже не-бездельник и не-прогульщик. Это каким самоуверенным аналитиком надо быть, чтобы установить этот порог.
Вы говорите про multiprocessing, я говорю про NumPy.
Ну хорошо, допустим — мне лень проверять этот случай для не-NumPy. Но ведь в основе переменных NumPy лежит тот же reference counter, который забирается сборщиком мусора, когда на переменную никто не ссылается. Почему же Python multiprocessing не сохранил ссылку на передаваемый аргумент и позволил сборщику мусора забрать данные, которые нужны другому процессу?
Попробую и тут выкрутиться ) «Ошибок управления памятью всё же не совершают» — так вы хотите сказать, что это утверждение верно только для стандартной библиотеки? Интересно, ведь одно из самых больших преимуществ Пайтона именно в том, что у него полно сторонних библиотек на все случаи жизни. OpenCV, TensorFlow, Panda3d, NumPy, SymPy, Matplotlib etc.
И если убрать эти различия, то преимущества ручного управления памятью либо уменьшаться, либо, в некоторых случаях исчезнут
Возможность ручного управления памятью — это вообще одно из главных преимуществ С++. В частности, в геймдеве и реал-тайм системах. Для бизнес-проектов мне сложно представить зачем использовать С++.
Она идёт в стандартной поставке Python 3. Заходим сюда, замечаем заголовок: «Documentation » The Python Standard Library » Concurrent Execution». Ниже: «multiprocessing — Process-based parallelism»
Во-вторых, данная ошибка вызвана кодом написанным на си
Стандартный интерпретатор (ака cpython) вместе со стандартной библиотекой на треть написан на си (можете зайти на гитхаб и увидеть это в статистике. В частности, когда вы работаете со строками или списками, то вызываются си функции.
Вы говорите так, словно плюсы умеют работать с переменными, под которые не выделена память.
Мой поинт был в том, что в Пайтоне хоть убейся, но не сможешь управлять памятью эффективно. Иногда это приводит к тому, что ты не можешь даже XML распарсить за вменяемое время. С другой стороны, в С/С++ ты можешь создать свой эффективный менеджер памяти (RapidXML++) и даже выделить переменное количество памяти на стэке (alloca()), не дёрнув ни один пайтоновский или системный вызов.
Это будет происходить в любых местах, когда управляют памятью несколько независимых систем
В таком случае заберите свои слова обратно, потому что — вот Пайтон, вот я использую стандартную библиотеку, вот получаю мусор (в переводе на ваш словарь — «ошибку управления памятью»)
RapidXML++ использует свой менеджер памяти? Если строки только сравниваются на равенство, то можно обойтись без копирования, используя смещения.
Действительно, RapidXML++ определяет свой менеджер памяти. Но чтобы доставить эти данные в Пайтон (мы ведь говорим о парсере, правильно?), то для каждого узла, атрибута, имени атрибута и т.д. придётся создать маленькие переменные строки, а Пайтон не умеет создавать переменные, не выделяя под них память. В итоге разница в скорости — стократная, лично замерял для всех доступных библиотек. А всего лишь надо было отказаться от хоботни с памятью.
На Питоне тоже можно получить ошибки управления памятью. Например, попробуйте запустить процесс через multiprocessing, передав ему в качестве аргумента NumPy массив, который освободится сразу после запуска процесса. Второй процесс получит вместо данных случайный мусор.
Но это ещё не всё. Обратная сторона отсутствия возможности управления памятью — это существенное замедление работы в рантайме. Попробуйте распарсить XML, используя любую библиотеку Питона, а потом сделайте то же самое на С++ через библиотеку RapidXML++ — разница в производительности будет отличаться в сотни раз! Почему? Да потому, что в Питоне на каждую маленькую строчечку — имя атрибута, значение атрибута, имя ноды, содержание ноды — будет хоботня с памятью, а RapidXML++ выделяет большие куски памяти и освобождает её только в самом конце и сразу, что даёт самый быстрый в мире парсинг. И даже если обернуть RapidXML++ в Питон, то ничего это не изменит, потому что Питону всё равно для парсинга придётся создавать все эти маленькие строки-переменные, чтобы можно было сравнивать их значения с искомыми.
Судя по фильму, всё заглохло ещё в самом начале, когда изобретателя посадили за якобы намерение использовать своё изобретения для подрыва моста с демонстрантами, а потом всю его жизнь глохло примерно в таком же ключе.
Даже в 4К без сглаживания не обойтись, поскольку в том-то и прикол альясинга, что он маскирует высокие частоты, которые не влезли, под любые низкие частоты. В частности, в 4К вы не увидите эффект альясинга, когда он вписывается в один пиксель, но от муара вы таким образом не спасётесь.
Технически плохо написанная / переведённая статья. Профукана возможность описать этимологию — почему именно такое слово — aliasing — а не другое? Безграмотные высказывания: «Разрешения 10 х 7 пикселей недостаточно для отображения этого треугольника без алиасинга» — правда, что ли? Выходит, тогда вообще никакой непрерывный треугольник невозможно показать без альясинга? А для чего тогда теорема Котельникова и фильтр низких частот? «цвет шейдера» — что вы называете «цветом шейдера»? В общем, не знаю, какие вы там игры делаете с 2009 года.
Немного позанудствую и придерусь к сглаживанию кривой:
В качестве алгоритма усреднения данных, после пары экспериментов, я выбрал расчет скользящего среднего по последним N измерениям. Это дает возможность быстро видеть изменения показаний, сглаживать график и практически исключать влияние выбросов, хотя и не является робастной.
Не очень понятно каким образом вы «практически исключаете влияние выбросов». По крайней мере в самой функции усреднения этого исключения влияния выбросов нет. Если вы суммируете значения вместе с выбросом, то вы как раз этот самый выброс и включили в вашу точечную статистику, и он повлиял на получаемый результат самым непосредственным образом.
Нет ничего зазорного, чтобы узким горлышком было чтение с диска, а не парсинг. В конце концов, этот файл может читаться из памяти, из сети, из RAID-массива. Тем более, что векторизация кода — это доступная техническая процедура. Так зачем сдерживать себя и не попробовать?
Не верю, что в данной задаче компилятор это сделает сам. Да и зачем полагаться на компилятор (который это не сделает), если то же самое можно сделать руками с гарантированным результатом?
Я помню статью про их мэра, который жаловался, что миллиард дотаций на решение проблем с бездомными не хватает, надо вкладываться еще больше. Они нанимали на эти деньги обычных работяг, чтобы те мыли улицы, раздавали палатки и чистые шприцы, но количество бездомных за это время только увеличивалось.
Когда-то делал для клиента распознавание надписей с субпиксельным рендерингом — мне хватило три набора символов, сдвинутых относительно друг друга на 1/3 пикселя. Сравнивал я их в оттенках серого.
Это если ещё аудиодорожка настоящая. Показанный клип смонтирован из кусков, что сложного им было дозаписать что угодно.
..диван, деньги, ярлык.. да куча заимствованных слов
Небольшая ремарка насчёт matplotlib: вы уже указали label при вызове
plt.plot(), поэтому достаточно вызватьplt.legend(), чтобы сгенерировать автоматическую легенду. Такое использование гораздо лаконичнее.Ещё одна ремарка относительно PID: для контроллеров обычно используют целочисленную арифметику. Если уже считаете с плавающей точкой, то для накопительных переменных надо брать число с большей точностью для избежания переполнения, иначе малые приросты просто перестанут менять перменную.
Мне не очень понятно, чем хороши персональные сказки. Мои дети, уже школьники, слушают сказки и длинные повествования почти каждый день, начиная с полутора лет. Таким образом, я знакомлю их с фундаментальными истинами, которые в них заложены. В частности, это центральная тема исследований Карла Юнга, Джозефа Кэмпбэлла и Джордана Питерсона.
А чем хороши для ребёнка надуманные сказки? Я ещё могу представить, что в каких-то случаях с ребёнком занимается психотерапевт и он подбирает ему истории конкретно под его потребности. Но неужели современный человек ("мамкин сказочник") вот так просто создаст историю с фундаментальной истиной, которую будут пересказывать веками? Каждая история должна пройти долгий путь отбора и пересказывания, прежде чем она изменится настолько, чтобы действительно выражать истину.
Ну это они же сначала должны начать суд, чтобы в нём что-то доказывать?
Во-первых, ваш акселерометр показывает не только динамическое ускорение, но и статическое от притяжения к земле. Для того, чтобы изъять его динамические показания, надо также пользоваться гироскопом. Во-вторых, акселерометр даёт такую точность, что если вы проведёте его по одной из осей, скажем, на метр, то после двойной интеграции окажется, что он проехал на 2/3 метра. В-третьих, для объединения показаний разных приборов надо не усреднять, а строить фильтр Калмана - только в этом случае финальная точность будет выше, чем у каждого из показаний по отдельности.
Причём интересно, что самый лучший из увольняемых сотрудников (по выделенным метрикам) - бездельник и прогульщик работы, а самый худший из оставшихся уже не-бездельник и не-прогульщик. Это каким самоуверенным аналитиком надо быть, чтобы установить этот порог.
Попробую и тут выкрутиться ) «Ошибок управления памятью всё же не совершают» — так вы хотите сказать, что это утверждение верно только для стандартной библиотеки? Интересно, ведь одно из самых больших преимуществ Пайтона именно в том, что у него полно сторонних библиотек на все случаи жизни. OpenCV, TensorFlow, Panda3d, NumPy, SymPy, Matplotlib etc.
Возможность ручного управления памятью — это вообще одно из главных преимуществ С++. В частности, в геймдеве и реал-тайм системах. Для бизнес-проектов мне сложно представить зачем использовать С++.
Стандартный интерпретатор (ака cpython) вместе со стандартной библиотекой на треть написан на си (можете зайти на гитхаб и увидеть это в статистике. В частности, когда вы работаете со строками или списками, то вызываются си функции.
Мой поинт был в том, что в Пайтоне хоть убейся, но не сможешь управлять памятью эффективно. Иногда это приводит к тому, что ты не можешь даже XML распарсить за вменяемое время. С другой стороны, в С/С++ ты можешь создать свой эффективный менеджер памяти (RapidXML++) и даже выделить переменное количество памяти на стэке (alloca()), не дёрнув ни один пайтоновский или системный вызов.
Действительно, RapidXML++ определяет свой менеджер памяти. Но чтобы доставить эти данные в Пайтон (мы ведь говорим о парсере, правильно?), то для каждого узла, атрибута, имени атрибута и т.д. придётся создать маленькие переменные строки, а Пайтон не умеет создавать переменные, не выделяя под них память. В итоге разница в скорости — стократная, лично замерял для всех доступных библиотек. А всего лишь надо было отказаться от хоботни с памятью.
Но это ещё не всё. Обратная сторона отсутствия возможности управления памятью — это существенное замедление работы в рантайме. Попробуйте распарсить XML, используя любую библиотеку Питона, а потом сделайте то же самое на С++ через библиотеку RapidXML++ — разница в производительности будет отличаться в сотни раз! Почему? Да потому, что в Питоне на каждую маленькую строчечку — имя атрибута, значение атрибута, имя ноды, содержание ноды — будет хоботня с памятью, а RapidXML++ выделяет большие куски памяти и освобождает её только в самом конце и сразу, что даёт самый быстрый в мире парсинг. И даже если обернуть RapidXML++ в Питон, то ничего это не изменит, потому что Питону всё равно для парсинга придётся создавать все эти маленькие строки-переменные, чтобы можно было сравнивать их значения с искомыми.
Не очень понятно каким образом вы «практически исключаете влияние выбросов». По крайней мере в самой функции усреднения этого исключения влияния выбросов нет. Если вы суммируете значения вместе с выбросом, то вы как раз этот самый выброс и включили в вашу точечную статистику, и он повлиял на получаемый результат самым непосредственным образом.