Самый простой пример - колесо. И кто сказал, что только люфт является источником вибраций?
Вы правы, но в моём комментарии нет утверждения, что вибрации вызывает только люфт. Отсутствие баланса подвижных деталей - это ошибка проектирования и/или производства в любом механизме.
Из какой практики вы это почерпнули?
Допускаю, что могу ошибаться, но мы с Вами знаем, что успешное проектирование и производство надёжных и долговечных механизмов требует осилить "слоёный пирог", приблизительно, из 15-и технических дисциплин, плюс "вишенка" = "Допуски и Посадки".
ДиП - дисциплина о сочленении деталей. Посадки с натягом применяются для неподвижных соединений, для подвижных - посадки с зазором, в просторечии - с люфтом.
Величина люфта (зазора в посадке) подбирается индивидуально для каждой подвижной пары деталей. Дефицит люфта грозит заклиниванием механизма. Профицит люфта - ускоряет износ и снижает КПД в силу паразитных вибраций в подвижной паре во время работы.
Люфт подвижных пар может находится за границами органов чувств человека. Но, если механические детали подвижны, то значит люфт там есть.
Это если, как говорится, грубо, "крупными мазками", на грани с глупостью. В реальности есть куча нюансов, например, переходные посадки, однако, мы и так уже слишком далеко отклонились от темы.
Справедливо только в помещениях и то не во всех.
В интернете много роликов, где механики запускают старый механизм через проведение регламентных работ без замены основных частей. Например, есть видео о "возвращение к жизни" паровоза, трактора на паровой тяге, простоявших на задворках под открытым небом много десятков лет.
К сожалению, Ваша статья оставляет за скобками вопрос "Как быстро посчитать синус на бюджетном микроконтроллере".
Допускаю, что программирование MCU - это частный, скучный случай. Но, это тот самый случай, где цель оправдывает средства: "Назвался груздём - полезай в кузов!".
сплайн — это инструмент
Цитируя Ваш комментарий, выражаю согласие Вашим подходом в целом. А в частности, вижу ключевое слово - "инструмент". Это как топор. Можно рубить, колоть, тесать, гвозди забивать. Можно гвозди выдёргивать топором. Слухами земля полнится, что умельцы из топора могут кашу варить. :-)
уровень гармоник и постоянной составляющей, которые вы через сплайны Безье минимизировать никак не сможете
Практика показывает, что прежде, чем совершить какое-либо действие, надо ответить всего на один вопрос: А оно нам надо?
- Расскажите о взятии интеграла на практике. - обратились первокурсники к бывалому инженеру-технологу. - Ну-у-у... - задумался инженер, - Намедни гайка в цеху в направляющий паз закатилась. Взяли интеграл. Согнули из тонкого профиля. Гайку достали.
Правдивая история, имевшая место быть.
Считаю бесперспективными споры между теоретиками и практиками, которые подобны альпинистам, восходящими на одну и ту же гору с разных сторон.
Первые видят общее. Вторые видят частное. Первые видят правила. Вторые видят исключения. И все забывают в споре, что стремятся к одной и той же вершине.
"Теория - это когда все известно, но ничего не работает. Практика - это когда все работает, но никто не знает почему." А. Энштейн.
а вы сравнивали производительность кода на разных компиляторах
Могу, конечно, заблуждаться, но прикладной программист и тестировщик чужих программ - это несколько разные специальности. Это как слесарь-инструментальщик и слесарь-механик. Вроде как в одном цеху, а задачи разные. Заниматься чужим делом - сомнительный путь. (imho)
Языки программирования высокого уровня, такие как "C/C++", их стандарты созданы для снижения зависимости программиста от поставщика оборудования и средств разработки.
Соблюдение стандарта программистом - это просто установка в строчке запуска компилятора значения, определённого в технических требованиях. Например, регламент по сборке ядра линукс требует 11-й стандарт, если память не изменяет.
С другой стороны, стандарты и компиляторы делают люди, а не боги.
Людям свойственно ошибаться.
не заметил, написали ли вы в статье, чем компилировали
Согласен. Вы правы применительно к задаче управления электромотором, характеризующейся регулярностью и периодичностью вычислений по принципу от достигнутого.
Представим задачу, где периодичность вырождена. Потребность вычислений возникает спонтанно, время от времени, как импульсная функция от состояния внешней среды.
Но, если такая потребность возникла, то время реакции критично.
И ещё важные вводные. Погрешность измерителя, погрешность исполнителя на три порядка хуже ~|1.0|, чем погрешность вычислителя | =>0,0003 |.
В чём смысл "борьбы" за симметрию ошибки вычислителя в четвёртом порядке, если с "высот" измерителя и исполнителя таких малых порядков нет.
Компилятор сделал то, о чём его не просили: 1. Зарезервировал (своровал) лишнюю память для вычисленных им констант; 2. Исключил вызов функции, которая теоретически может выполнять параллельную, другую работу по факту вызова; 3. Внёс искажения во временные характеристики кода в 2500(!) раз.
Как Вы думаете, программисты настолько тупы, что не знают как представить известную до выполнения программы последовательность в виде массива констант? Если им это надо.
Что ещё может генерировать компилятор в обход директив программиста?
Погоня за сомнительным повышением производительности через оптимизацию двоичного кода компилятором уже приводит к тому, что программы, собранные с запретом оптимизации работаю эффективнее, чем при её наличии. К сожалению ныне надо всегда помнить об этом.
Задача технического прогресса - повышать доступность для ширнармас передовых достижений науки и техники.
Задача технического прогресса решается через продвижение передовых достижений в массовое производство, как следствие, снижению их себестоимости и цены.
В частности, на практических задачах существуют иные ситуации, где исключается влияние накопленной ошибки уже на алгоритмическом уровне: "сигнал получен" -> "сигнал обработан" -> "полёт продолжается".
Более того, ошибка слабо влияет на решение задачи, если скорость вычисления выше инертности системы.
В качестве наглядного примера представим процесс парковки длинного фургона к разгрузочному пандусу: 1) Исполнитель сидит за рулём и слабо различает пространственные границы заднего бампера и разгрузочного пандуса в кривые зеркала заднего вида.
2) Руководитель находится сзади фургона, хорошо различает границы, быстро оценивает допустимые пределы, но лишён возможности управления фургоном и точной оценки ситуации "в цифре".
3) Заметим, эта "парочка" легко решает задачу безаварийной паковки к пандусу без измерений и расчётов на калькуляторе.
4) "Назад","Стоп", "Вперёд", "Право", "Правее", "Лево", "Левее" - необходимый и достаточный набор команд Руководителя, понятных Исполнителю, чтобы совершить парковку без аварии за конечное число "шагов" или тактов управления. Ибо погрешность "вычислений" выше инертности системы, а жизненный цикл ошибки "вычислений" ограничен одним шагом.
Вероятно, существует возможность оценивать численную ошибку на каждом шаге управления, оценивать степень её накопления. Но, ускорится ли решение практической задачи парковки, если Руководитель и Исполнитель начнут общаться формально, точно и без ошибок? - Поверни рулевое колесо на -15 градусов 34 минуты 12 секунд. - Подай импульс (надави) на педаль акселератора с усилием 2 ньютона в течение 3-х секунд. - Стоп! Пауза! Оцениваем пространственное положение. А подайте-ка лазерные дальномер и угломер. И калькулятор принесите. Программируемый.
:-)
Статистические методы оценки ошибок интересны и увлекательны, как и вся математика в целом. Практика диктует иные подходы. Например, в алгоритме Брезенхема оценка ошибки редуцируется до проверки только знака ошибки. И, это работает.
Согласно требованиям, указанным в статье, ожидаемая ошибка алгоритма +/- 0,005.
В свою очередь, требование к ошибке +/- 0,005 сформировано на основании точности вероятных исполнительных устройств. Например, у большинства доступных шаговых двигателей паспортная точность 1.8 ° с допуском +/- 0,9 °, т.е. на два порядка хуже алгоритмической.
Таким образом, демонстрация расчётной ошибки с меньшим модулем и разрядом, чем в требованиях [ +/- 0,0003 .vs. +/- 0,005 ], гарантирует удовлетворительную точность для вероятных исполнительных устройств, Гарантирует точность, достижимую простым отбрасыванием младших разрядов без издержек на округление.
В условиях многократного резервирования по точности "борьба" за симметрию расчётной ошибки просто теряет смысл.
Странно что не модифицировали через Чебышева для 45 градусного блока, ограничение в 3-5 членов
Думал об этом методе. Но, в последний момент появились сомнения в его эффективности в данном конкретном случае. Проверять не стал, применив похожий, но несколько иной способ.
чем вас не устраивали циклы с отбрасыванием периода
Тем, что любой цикл увеличивает расходы, как минимум, на условный переход. А "погоня" за производительностью стала мотиватором для данной работы.
забавные моменты, когда поворот от 1 градуса до 360 идет путем
Согласен.
Но в данном алгоритме подобная ситуация исключена.
Буду признателен, если подскажите тест, который позволит проверить утверждение выше на опубликованном исходном коде.
Но, здесь суть в том, что точность требуется не повышенная, а гарантированная. И не в точках, а непрерывно с шагом 0,01 ° на всей области определения аргумента [ -5400 °.. +5400° ], применительно к бюджетным MSU с дефицитом памяти и производительности.
Где выигрыш в статических таблицах, если задача решается алгоритмически за несколько десятков слов бинарного кода?
Вы правы, но в моём комментарии нет утверждения, что вибрации вызывает только люфт.
Отсутствие баланса подвижных деталей - это ошибка проектирования и/или производства в любом механизме.
Допускаю, что могу ошибаться, но мы с Вами знаем, что успешное проектирование и производство надёжных и долговечных механизмов требует осилить "слоёный пирог", приблизительно, из 15-и технических дисциплин, плюс "вишенка" = "Допуски и Посадки".
ДиП - дисциплина о сочленении деталей. Посадки с натягом применяются для неподвижных соединений, для подвижных - посадки с зазором, в просторечии - с люфтом.
Величина люфта (зазора в посадке) подбирается индивидуально для каждой подвижной пары деталей. Дефицит люфта грозит заклиниванием механизма. Профицит люфта - ускоряет износ и снижает КПД в силу паразитных вибраций в подвижной паре во время работы.
Люфт подвижных пар может находится за границами органов чувств человека. Но, если механические детали подвижны, то значит люфт там есть.
Это если, как говорится, грубо, "крупными мазками", на грани с глупостью.
В реальности есть куча нюансов, например, переходные посадки, однако, мы и так уже слишком далеко отклонились от темы.
В интернете много роликов, где механики запускают старый механизм через проведение регламентных работ без замены основных частей. Например, есть видео о "возвращение к жизни" паровоза, трактора на паровой тяге, простоявших на задворках под открытым небом много десятков лет.
--
Извиняюсь за отклонение от темы.
Согласен с Вами по каждому замечанию в целом.
:-)
С интересом прочёл Вашу статью "Как посчитать синус быстрее всех на хабре". Спасибо за статью. Поставил плюс.
К сожалению, Ваша статья оставляет за скобками вопрос "Как быстро посчитать синус на бюджетном микроконтроллере".
Допускаю, что программирование MCU - это частный, скучный случай. Но, это тот самый случай, где цель оправдывает средства: "Назвался груздём - полезай в кузов!".
Цитируя Ваш комментарий, выражаю согласие Вашим подходом в целом.
А в частности, вижу ключевое слово - "инструмент".
Это как топор. Можно рубить, колоть, тесать, гвозди забивать. Можно гвозди выдёргивать топором. Слухами земля полнится, что умельцы из топора могут кашу варить. :-)
Практика показывает, что прежде, чем совершить какое-либо действие, надо ответить всего на один вопрос: А оно нам надо?
- Расскажите о взятии интеграла на практике. - обратились первокурсники к бывалому инженеру-технологу.
- Ну-у-у... - задумался инженер, - Намедни гайка в цеху в направляющий паз закатилась. Взяли интеграл. Согнули из тонкого профиля. Гайку достали.
Правдивая история, имевшая место быть.
Считаю бесперспективными споры между теоретиками и практиками, которые подобны альпинистам, восходящими на одну и ту же гору с разных сторон.
Первые видят общее. Вторые видят частное. Первые видят правила. Вторые видят исключения. И все забывают в споре, что стремятся к одной и той же вершине.
Могу, конечно, заблуждаться, но прикладной программист и тестировщик чужих программ - это несколько разные специальности. Это как слесарь-инструментальщик и слесарь-механик. Вроде как в одном цеху, а задачи разные. Заниматься чужим делом - сомнительный путь. (imho)
Языки программирования высокого уровня, такие как "C/C++", их стандарты созданы для снижения зависимости программиста от поставщика оборудования и средств разработки.
Соблюдение стандарта программистом - это просто установка в строчке запуска компилятора значения, определённого в технических требованиях. Например, регламент по сборке ядра линукс требует 11-й стандарт, если память не изменяет.
С другой стороны, стандарты и компиляторы делают люди, а не боги.
Людям свойственно ошибаться.
А внимательно-ли Вы читали статью? :-)
Согласен. Вы правы применительно к задаче управления электромотором, характеризующейся регулярностью и периодичностью вычислений по принципу от достигнутого.
Представим задачу, где периодичность вырождена. Потребность вычислений возникает спонтанно, время от времени, как импульсная функция от состояния внешней среды.
Но, если такая потребность возникла, то время реакции критично.
И ещё важные вводные. Погрешность измерителя, погрешность исполнителя на три порядка хуже ~|1.0|, чем погрешность вычислителя | =>0,0003 |.
В чём смысл "борьбы" за симметрию ошибки вычислителя в четвёртом порядке, если с "высот" измерителя и исполнителя таких малых порядков нет.
Согласен. В общем и целом Вы правы.
Прошу пояснить. О каких частотах "со всеми вытекаюшими" Вы предупреждаете?
Если рассуждать в общем и целом с точки зрения механики, то асимметрия - это источник люфта.
Механизм теряет способность к движению, если из него убрать люфт.
Механический люфт - источник вибрации. Вибрация - разрушает механизм, если попадает в его резонанс.
Механизмы служат надёжно и долго, если собственная частота резонанса отличается от рабочей частоты.
Дополнительное страхование рисков преждевременного разрушения механизмов обеспечивают виброгасители и виброопоры.
(imho)
Есть сомнения, что CORDIC даст какие-либо преимущества на бюджетных MCU.
Согласен. Вы правы.
И в этом как раз засада.
Компилятор сделал то, о чём его не просили:
1. Зарезервировал (своровал) лишнюю память для вычисленных им констант;
2. Исключил вызов функции, которая теоретически может выполнять параллельную, другую работу по факту вызова;
3. Внёс искажения во временные характеристики кода в 2500(!) раз.
Как Вы думаете, программисты настолько тупы, что не знают как представить известную до выполнения программы последовательность в виде массива констант? Если им это надо.
Что ещё может генерировать компилятор в обход директив программиста?
Погоня за сомнительным повышением производительности через оптимизацию двоичного кода компилятором уже приводит к тому, что программы, собранные с запретом оптимизации работаю эффективнее, чем при её наличии. К сожалению ныне надо всегда помнить об этом.
Выше условный код, для понимания. В реальности код слегка отличается:
Результат выполнения кода в зависимости от директивы NOISE_ON.
Проведите эксперимент! Его результат будет интересен, как минимум, всем участникам этой дискуссии.
Просто обнулите четвёртый и далее разряды, и снова сравните.
Этот алгоритм про результат с заданной степенью точности.
Согласен.
Задача технического прогресса - повышать доступность для ширнармас передовых достижений науки и техники.
Задача технического прогресса решается через продвижение передовых достижений в массовое производство, как следствие, снижению их себестоимости и цены.
:-)
Согласен. Вы правы в общем и целом.
В частности, на практических задачах существуют иные ситуации, где исключается влияние накопленной ошибки уже на алгоритмическом уровне: "сигнал получен" -> "сигнал обработан" -> "полёт продолжается".
Более того, ошибка слабо влияет на решение задачи, если скорость вычисления выше инертности системы.
В качестве наглядного примера представим процесс парковки длинного фургона к разгрузочному пандусу:
1) Исполнитель сидит за рулём и слабо различает пространственные границы заднего бампера и разгрузочного пандуса в кривые зеркала заднего вида.
2) Руководитель находится сзади фургона, хорошо различает границы, быстро оценивает допустимые пределы, но лишён возможности управления фургоном и точной оценки ситуации "в цифре".
3) Заметим, эта "парочка" легко решает задачу безаварийной паковки к пандусу без измерений и расчётов на калькуляторе.
4) "Назад","Стоп", "Вперёд", "Право", "Правее", "Лево", "Левее" - необходимый и достаточный набор команд Руководителя, понятных Исполнителю, чтобы совершить парковку без аварии за конечное число "шагов" или тактов управления. Ибо погрешность "вычислений" выше инертности системы, а жизненный цикл ошибки "вычислений" ограничен одним шагом.
Вероятно, существует возможность оценивать численную ошибку на каждом шаге управления, оценивать степень её накопления. Но, ускорится ли решение практической задачи парковки, если Руководитель и Исполнитель начнут общаться формально, точно и без ошибок?
- Поверни рулевое колесо на -15 градусов 34 минуты 12 секунд.
- Подай импульс (надави) на педаль акселератора с усилием 2 ньютона в течение 3-х секунд.
- Стоп! Пауза! Оцениваем пространственное положение. А подайте-ка лазерные дальномер и угломер. И калькулятор принесите. Программируемый.
:-)
Статистические методы оценки ошибок интересны и увлекательны, как и вся математика в целом. Практика диктует иные подходы. Например, в алгоритме Брезенхема оценка ошибки редуцируется до проверки только знака ошибки. И, это работает.
(imho)
В сообщении данные, подтверждённые многократным экспериментом.
Согласен. Вы правы.
Сплайн - это просто форма. Это форма представления многочлена, оптимизированная для компьютера.
(imho)
0,0003 - это относительная ошибка, разность ( sint() - sinf() ).
Согласно требованиям, указанным в статье, ожидаемая ошибка алгоритма +/- 0,005.
В свою очередь, требование к ошибке +/- 0,005 сформировано на основании точности вероятных исполнительных устройств. Например, у большинства доступных шаговых двигателей паспортная точность 1.8 ° с допуском +/- 0,9 °, т.е. на два порядка хуже алгоритмической.
Таким образом, демонстрация расчётной ошибки с меньшим модулем и разрядом, чем в требованиях [ +/- 0,0003 .vs. +/- 0,005 ], гарантирует удовлетворительную точность для вероятных исполнительных устройств, Гарантирует точность, достижимую простым отбрасыванием младших разрядов без издержек на округление.
В условиях многократного резервирования по точности "борьба" за симметрию расчётной ошибки просто теряет смысл.
Думал об этом методе. Но, в последний момент появились сомнения в его эффективности в данном конкретном случае. Проверять не стал, применив похожий, но несколько иной способ.
Тем, что любой цикл увеличивает расходы, как минимум, на условный переход. А "погоня" за производительностью стала мотиватором для данной работы.
Согласен.
Но в данном алгоритме подобная ситуация исключена.
Буду признателен, если подскажите тест, который позволит проверить утверждение выше на опубликованном исходном коде.
Разделяю драмматизм ситуации.
Более того, тестирование библиотечных функций показывает фантастическую производительность на регулярных данных.
И картина драмматически меняется, когда регулярность нарушается слабым шумом.
Согласен, это известный, проверенный подход.
Но, здесь суть в том, что точность требуется не повышенная, а гарантированная. И не в точках, а непрерывно с шагом 0,01 ° на всей области определения аргумента [ -5400 °.. +5400° ], применительно к бюджетным MSU с дефицитом памяти и производительности.
Где выигрыш в статических таблицах, если задача решается алгоритмически за несколько десятков слов бинарного кода?