Если хотите - можете попробовать мои наработки. Мне они вполне подошли. Вроде бы и народ тестировал, отзывы были не ругательные. Входные значения - в радианах, без ограничения.
Если хотите - можете попробовать мои наработки. Мне они вполне подошли. Вроде бы и народ тестировал, отзывы были не ругательные. Входные значения - в радианах, без ограничения.
Давайте я пожалуюсь.Сообщение от Hemann
1) Вычислять "знак числа" через POW(-1, TO_FLOAT(NOT(GT(x, 0)))) это круто.
С extract'ом же правильно поняли.
Т.е. XOR(NOT(GT(x, 0)), TO_INT(fDIV(x, pi))) и потом extract нулевого бита.
2) Подаю на вход sin_x значение 3,14158 (~179.99927 градусов), получаю на выходе -4,3E-04 == -0.00043
Реальное значение sin(3.14158) == 1.26536e-5 == 0.0000126536
Ошибка просто огроменная: целых 3600% == (0.0000126536 + 0.00043)/0.0000126536 == 36
При углах 179.97..180 градусов ошибка превышает 100%
Конечно, считать sin(x) при x порядка pi это неблагодарное занятие, но если перед "записью в Y" ещё сделать преобразование "если Y>pi/2, то записать pi-Y", то точность около pi повысится просто невероятно. Можно и y^11 выкидывать смело будет.
Вот график относительной ошибки для вашего алгоритма около pi
Взываю к разработчикам ОЛ! Появление ПР200 с относительно развитой функцией индикации и редакции энергонезависимых переменных (доступных настроек проекта) настоятельно требует расширения вариантов записи проекта в прибор. Энергонезависимые переменные призваны быть сохраненными не только при выключении питания, но и при перезаливке программы в прибор. Сейчас они при заливке переписываются в значения "по умолчанию", что в реальной эксплуатации ухудшает потребительские свойства прибора, вынуждает вести протоколы настроек и восстанавливать настройки вручную. Просьба рассмотреть возможность появления в ОЛ:
1. Разделение записи проекта отдельно на функцию записи программы и функцию записи в энергонезависимые переменные значений "по умолчанию"+ системные переменные, назначаемые в настройках проекта (границы AI, типы сигналов, параметры RS-485).
2. Дать функцию прочитать из прибора все эти переменные и автоматически внести их значения в проект, или хотя бы прочитать в файл пользователя, который потом можно было бы записать обратно или в другой прибор.
3. Расширить список доступа к системным переменным настроек проекта (только для чтения) чтобы программа их могла видеть и реагировать на неправильно проредактированные.
Поддерживаю, проблема действительно актуальная. Не очень хочется при перезаливке заносить обратно вручную счётчики моточасов и настройки.
, а если другой проект залили с другими сетевыми адресами и часть с теме же,а там сохранилась каша от предыдущено проекта ..Как отличить перезаливку от заливки ...
электронщик до мозга костей и не только
Владимир, как говорится у Шекспира, нет в мире совершенства. На значениях Х, близких к 0 или Pi, здорово сказывается ограничение точности как самой ПР-ки, так и метода. Однако, увеличивать количество членов ряда не имеет смысла именно из-за свойств платформы. В любом случае-писал для себя, мне подошло, может кому будет тоже полезно
Вы меня не поняли.
Количество членов ряда нужно даже уменьшать.
x9 и x11 совершенно не нужны -- они никак не добавляют точности (если добавить if (x>pi/2) { y=pi-x; } else { y=x; } предобработку)
x7 -- нужно, иначе будет некрасиво около 1.57
Вот я поправил ваш макрос sin: sin_improved.zip
Выглядит так: sin_improved.png
Вот вычисление проблемного 3.14158. Видно, что правильный ответ получается с первых же членов ряда: sin_314158.png
К сожалению, отображение float в OwenLogic крайне неудачно сделано (показывает слишком мало цифр и никак не узнать все). Например, если вычислять sin(1.57), то с первых же членов ряда получается 1e0, а реально там чуть больше должно получаться на первых двух членах -- 1.004 (это при том, что синус больше 1 быть не должен %)
Разумеется, около pi всё равно будет колбасить (т.к. pi float'ом не представимо), но после поправки pi-x зона расколбаса гораздо уже. Сравните синий и красный графики. Синий ряд до x5, но с предобработкой. Красный -- до x11, но без.
Последний раз редактировалось Владимир Ситников; 01.02.2016 в 11:58.
Теория хорошо ,а практика лучше ... Часто вспоминаю AI ,умница ,хороший теоретик ,но и знания свои подтверждал примерами (проектами)..Вроде на форуме он ,но что то молчит....
У меня нет ПР и пока не предвидится. Поэтому могу только руками размахивать и теоретизировать в симуляторах.Теория хорошо ,а практика лучше ..
Кстати, интересно:
1) Можно ли задать порядок выполнения fADD. Теоретически, нужно ряд складывать наоборот: x5/120-x3/6+x. Когда складываешь "совпадающие по величине числа" погрешность float'а меньше копится.
2) Насколько симулятор верно считает (нет ли там глюка, что внутренние вычисления идут в double)
Вот это уже лучше ,с примерами
Ваши права
