Микроконтролери и електроника
http://mcu-bg.com/mcu_site/

Trigonometric functions
http://mcu-bg.com/mcu_site/viewtopic.php?f=3&t=3994		 Страница 1 от 2
Автор:  Vilo [ Сря Апр 04, 2007 8:57 pm ]
Заглавие:  Trigonometric functions
Triabva da subera smetka na arc sin v okolo 1kB ROM i 256B RAM.
Preciznost: min. 4 cifri sled zapetaiata v intervala +/- PI/2. Moje i da e skalirano v int.
MCU: 8051
Skorostta ne e ot znachenie.
Vsiakakvi idei i nasoki sa dobre doshli. Blagodaria predvaritelno. Google ne beshe osobeno slovoohotliv otnosno CORDIC :(.
Автор:  evc [ Сря Апр 04, 2007 9:50 pm ]
Заглавие: 
Каква дискретност ти трябва? За таблично представяне(стойностите на предварително изчислени арксинуси с някаква стъпка в таблица, а аргумента ти се явява офсет от началото на таблицата) мислил ли си? В 1к можеш да натъпчеш 512 стойности, т.е. дискретност от 0.35градуса или около 21минути.
Автор:  Vilo [ Сря Апр 04, 2007 10:03 pm ]
Заглавие:  discretnostta...
Triabva da e po dobra ot 0.05 gradusa. Tablicata e chastichno reshenie, neshto kato pomosht kum "niakakva" matematika.
Автор:  sv_shady [ Сря Апр 04, 2007 10:31 pm ]
Заглавие: 
Охооо не си го и помисляй :) Уча в СМГ и в часовете за подготовка на отбора по математика точно с това ни занимаваше господина извстно време. Общо взето, за да пресметнеш математическа стойността на една тригонометрична функция ти трябват доста ресурси (5-6 листа писане :P ) и това, ако тръгнеш да го реализараш програмно не ми се мисли!!! То е векторна алгебра, после решаване на уравнение от сравнително висока степен и понеже трябва да го решиш трябва да ползваш формулите на Фераро и Кардан (съкратеният им вариант е един ред А4 на дълго :P) Виж, че ще се ползват формули хубаво само, че понеже участват доста корени и при закръглянето постепенно се натрупва сериозна грешка. Абе не си е работа... Не случайно има "ЧЕТИРИЗНАЧНИ ТАБЛИЦИ" :)
Автор:  BrainStorm [ Сря Апр 04, 2007 10:45 pm ]
Заглавие: 
Е неми се вярва да е чак пък толкова сложно :P щом един обикновен калкулатор ги смята с точност до 6 знак :)
Автор:  sv_shady [ Сря Апр 04, 2007 10:47 pm ]
Заглавие: 
Мислиш ли че ги смята ??? И, ако смята едва ли е "обикновен" калкулатор :)
Автор:  BrainStorm [ Сря Апр 04, 2007 10:50 pm ]
Заглавие: 
Еми смятаги немисе вярва да ги научква :D ... и да обикновен е някъв турски боклук ... малиии езъх че съм приложна математика :D

http://links.jstor.org/sici?sici=0025-5 ... size=LARGE
Автор:  sv_shady [ Сря Апр 04, 2007 11:14 pm ]
Заглавие: 
Абе то, че не ги научква не ги :) Ама ползва някакви таблици 1000%
Автор:  BrainStorm [ Сря Апр 04, 2007 11:17 pm ]
Заглавие: 
Ем сигурно :) .. трябва да се разровя имам едни библиотеки за пресмятане на arc xxx за AVR ... да видя как става там ..
Автор:  kasparov [ Сря Апр 04, 2007 11:55 pm ]
Заглавие: 
Vilo, виж глава 7 на тази кника ( само 3 Мб)
http://rapidshare.de/files/7833926/Digi ... Z.rar.html
Автор:  HCL [ Чет Апр 05, 2007 12:00 am ]
Заглавие: 
По-добрите могат до 10-ия знак след запетаята :D
Става и без таблици разбира се. Нали затова сьществува т.н. Numerical analysis, MATLAB в таблици ли тьрси. Тази таблица е трябвало да бьде изчислена пьрвоначално.
Ключовата ти дума в гооглето е infinite series.
Сигурен ли си, че се изискват 0.05 градуса, градуса, в цялото ДМ? Това означава в двата края на диапазона резолюция от около 1Е-7. Hа кой му е притрябвало подобно нещо? Освен ако не конструираш калкулатор разбира се :)
Но както и да е, да кажем, че такова е заданието.


Изображение


Още на прьв поглед се вижда, че в диапазона +/- pi/6 имаш почти линейна функция. Това което ти препорьчвам като решение е да разделиш ДМ на части и за всяка част да направиш по една апроксимация. Колкото повече области толкова по-добро бьрзодействие и толкова повече необходима програмна памет. Според ресурсите си и поставеното изискване за точност тьрсиш подходящото решение.
Ето пример за развит ред на Маклаурин, иначе казано Тайлор редица с точка на развитие 0.

http://upload.wikimedia.org/math/2/a/8/ ... 818504.png

При тези изисквания за точност и µC с който разполагаш ... може да отнеме малко време :twisted:
Затова развиваш няколко такива реда в критичните области и дерзаеш. И тьй като не е малко работа, не е лоша идеята на BrainStorm да се огледаш как е решен проблема от умните глави.
Автор:  HCL [ Чет Апр 05, 2007 12:44 am ]
Заглавие: 
evc написа:
Каква дискретност ти трябва? За таблично представяне(стойностите на предварително изчислени арксинуси с някаква стъпка в таблица, а аргумента ти се явява офсет от началото на таблицата) мислил ли си? В 1к можеш да натъпчеш 512 стойности, т.е. дискретност от 0.35градуса или около 21минути.


avc с offset няма да стане толкова лесно, защото функцията не е линейна. Ако искаш константно отклонение от 0.35 градуса ще се наложи да разположиш точките през динамични интеревали. Иначе казано в двата края на диапазона точките ти ще са разположени най-нагьсто, а около нулата най-нарядко. А това си изисква един search алгоритьм, binary search с малка модификация за междинните стойности мисля, че би бил най-подходящ.
С offset сьщо може да стане, спестяваш си тьрсенето в масива, в такьв случай LUT-а ще сьдьржа решенията за стойности лежащи през константен интервал 3.9Е-1 една от друга, което означава, че около нулата отклонението ще е около 0.22 градуса, а в двата края на диапазона около 5 градуса, малко кофти иначе вярно, по-бьрзо е.
Автор:  HCL [ Чет Апр 05, 2007 1:22 am ]
Заглавие: 
И понеже ми стана интересно, хвьрлих едно око как в действителност е реализирано в MATLAB.
Цитат:
asin uses FDLIBM, which was developed at SunSoft, a Sun Microsystems,


и като потьрсиш какви са ги творили от Sun стигаш до

Цитат:
FDLIBM (Freely Distributable LIBM) is a C math library
for machines that support IEEE 754 floating-point arithmetic.


Тук вече всякакви надежди за copy/paste са мьртви :). Но интересното е че в действителноcт използват метода, който споменах в началото. Апрокcимират функцията в отделни области.

Код:
/* __ieee754_asin(x)
* Method :                 
*Since  asin(x) = x + x^3/6 + x^5*3/40 + x^7*15/336 + ...
*we approximate asin(x) on [0,0.5] by
*asin(x) = x + x*x^2*R(x^2)
*where
*R(x^2) is a rational approximation of (asin(x)-x)/x^3
*and its remez error is bounded by
*|(asin(x)-x)/x^3 - R(x^2)| < 2^(-58.75)
*
*For x in [0.5,1]
*asin(x) = pi/2-2*asin(sqrt((1-x)/2))
*Let y = (1-x), z = y/2, s := sqrt(z), and pio2_hi+pio2_lo=pi/2;
*then for x>0.98
*asin(x) = pi/2 - 2*(s+s*z*R(z))
*= pio2_hi - (2*(s+s*z*R(z)) - pio2_lo)
*For x<=0.98, let pio4_hi = pio2_hi/2, then
*f = hi part of s;
*c = sqrt(z) - f = (z-f*f)/(s+f) ...f+c=sqrt(z)
*and
*asin(x) = pi/2 - 2*(s+s*z*R(z))
*= pio4_hi+(pio4-2s)-(2s*z*R(z)-pio2_lo)
*= pio4_hi+(pio4-2f)-(2s*z*R(z)-(pio2_lo+2c))
*
* Special cases:
*if x is NaN, return x itself;
*if |x|>1, return NaN with invalid signal.
*
*/


И нещо което бяхме пропуснали, не е необходимо изчисляване или LUT за цялото ДМ, а само за едната половината :wink:
Автор:  ДедоБоре [ Чет Апр 05, 2007 8:41 am ]
Заглавие: 
трябваше да му оставиш някаква надежда на човека :roll:
Автор:  evc [ Чет Апр 05, 2007 8:47 am ]
Заглавие: 
HCL написа:
evc написа:
...


avc с offset няма да стане толкова лесно, защото функцията не е линейна. Ако искаш константно отклонение от 0.35 градуса ще се наложи да разположиш точките през динамични интеревали. Иначе казано в двата края на диапазона точките ти ще са разположени най-нагьсто, а около нулата най-нарядко. А това си изисква един search алгоритьм, binary search с малка модификация за междинните стойности мисля, че би бил най-подходящ.
С offset сьщо може да стане, спестяваш си тьрсенето в масива, в такьв случай LUT-а ще сьдьржа решенията за стойности лежащи през константен интервал 3.9Е-1 една от друга, което означава, че около нулата отклонението ще е около 0.22 градуса, а в двата края на диапазона около 5 градуса, малко кофти иначе вярно, по-бьрзо е.


XCL, никъде в моя пост не е спомената думичката "лесно"! И няма нужда от сърч алгоритми, ако знаеш какво правиш! И особено е добре да говориш от първо лице, написал съм 512 стойности като съм имал предвид 512 ЧЕТИРИ байтови стойности, което в действителност са 256 за да може да ги събере в 1к, но когато аргумента е с обратен знак се ползва горната част на таблицата!
Страница 1 от 2 Часовете са според зоната UTC + 2 часа [ DST ]
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/