Здравейте,
правя едно устройство с пик18 и трябва да се смятат едни сложни неща, алгоритъма за това го имам готов като програма на С, но проблемът е, че на повечето места се използва числа от тип double, който по принцип е 64 битов, но като гледам компилаторите за пик поддържат само 32 битов double. Сметките са доста, грешките се натрупват и става... Има ли някакъв безболезнен начин да работя с по-голяма точност като ползвам операции с float да кажем? Или да направя всички действия (+,-,/,* и сравнение) с подпрограмки на асемблер като за 64 битови числа с плаваща запетая?

IAR имаше 64 битови флоат дори и за PIC. Сигурно и още някой компилатор ще има.

Сега погледнах IAR - и техните са 32 битови

Имаш ли проблеми да ползваш фиксирана запетая?

long double или само double мисля че беше в IAR. И трябваше да се даде в командния ред на компилатора --64bit_doubles по спомен за да е 64 бита. Иначе е 32. Но има някаква вероятност да се бъркам с други процесори. Нямам качен за PIC да проверя.

Ако 64 бита integer-и ти стигат, докато търсиш кой компилатор какви ги върши и т.н. ще
си направиш аритметиката сам десет пъти.
Ако ти трябва 64 бита fp и не си писал такива библиотеки досега, най-лесният път е да намериш
готови за ползване, в рамките на компилатора или извън него. Не е ракетна наука да си ги
напишеш и сам, но няма да стане за ден-два ако нямаш опит.

CCS няма 64 битов флоат със сигурност. 95% съм убеден също и за С18 и Х-Тек... и то какво остана Сори за лошите новини

Интересно ми е кaто е толкова сложна сметката за колко време ще ги смята PIC-а тези неща и то long double формат ?

Варианта с компилатор, който да поддържа такова нещо отпада, тези, които ги знам не стават - C18, hi-tech, ccs, iar.
Времето за смятане е приемливо горе-долу - около 700 ms с C18 с пълна птимизация, но мисля, че ще може и да се намали ако оптимизирам някои неща, има малко цикли, там може да се пипне нещо. Из нета срещнах едно решение - да ползвам структура от две float числа - едно за цялата част и едно за дробната, но умножението и деленето ще става доста бавно. Никъде не намерих някои да е писал такова нещо. Някои може ли да ми препоръча някаква книга от където да видя как са точно алгоритмите, защото из нета има, но липсват важни детайли за практическата реализация?

C30 до колкото си спомням имаше 64float, ако ти се минава на 24ки - ще смята по бързо. А и от новите 18ки на 3.3 волта май има еквиваленти по крака от 24ките.

Направи си асемблерски вложки и си ги викай като подпрограми.
Библиотеката на Майкрочип има 64 бита FP, ползвал съм ги, работят.
Впрочем, функцията през С работеше на симулатор, но компилирано процесора се задръсти и минахме на асемблерския вариант.
С него стана.

А, това е добра новина! За коя библиотека на майкрочип имаш предвид?

Ами някъде из App Notes, не си спомням вече точно кой - ще трябва да поровиш.
http://www.microchip.com/stellent/idcpl ... e=en010961
http://www.microchip.com/stellent/idcpl ... e=en010984
http://www.microchip.com/stellent/idcpl ... e=en010982
Впрочем, за всякакви сметки, освен ако не са астрономически, 32 бита стигат

Трябва да се има предвид, че плаващата запетая е логаритмично представяне на числата.
Малките числа се представят с много голяма точност, а големите с по-малка `по абсолютна стойност`.
виж това за пример
The problem with integer systems is that they cannot be extended to larger scale environments. Typically if one chooses the grid spacing for an integer system to represent one tenth of an inch, then the maximum distance from side to side of the virtual environment supporting this precision is about 7,000 miles. This is obviously insufficient to support a docking maneuver in space. The problem for integer systems is that one must determine in advance how large of an environment will be supported and the precision of the position representation is then limited based on the environment's maximum size.

Floating point formats were created to increase the range of representable numbers. However, this is done at the expense of precision at the extremes of the representation. While floating point systems were intended to increase the size of the virtual environment, this is illusory because inaccuracies increase as one moves away from the origin. More specifically, a floating point value usually has only 6 or 7 decimal digits of precision but can represent numbers up to 1038 and as small as 10-38, a much greater range than integer values. The result is, while numbers close to, zero have a smaller grid size, numbers close to the maximum value have ever expanding grid sizes, thus limiting precision at large distances. Although floating point systems are useful, it is this discrepancy of expanding grid size as one moves far from the origin that causes problems for large virtual environments.

By way of example, using floating point representation, grid lines 3000 miles from the origin of a virtual environment would represent 15 inch separations vs. 0.01 inch separations one mile from the origin. As a result, with floating point, spatial aliasing exists in the placement of objects far from the origin of the virtual environment since objects cannot be positioned between grid lines. Spatial aliasing occurs when an object that is supposed to be at one location cannot be put there because the result would be between grid lines. When this occurs, floating point systems move the object to the nearest grid line.

For a 32 bit floating point system one inch from the origin, one can specify a position within 0.12 microinches or 1.2×10-7 inches of accuracy. At a mile away, the precision is limited to, about 1/100th of an inch. At 3000 miles away the precision is about 15 inches.

Всъщност сметките са астрономически
Устройството ще изчислява положението на слънцето. Реших така да направя - ще си направя мой тип double, който няма да е по стандарта, защото ще губя време да разопаковам, функциите ще бъдат написани на семблер в по-голямата си част. Само едно нещо не мога да разбера - мантисата като е отрицателна в допълнителен код ли се представя или само знака е отрицателен?

Супер интересно звучи Сподели малко повече инфо относно твоя проект. Спрямо какво ще изчисляваш положението на слънцето??? И какви сензори (датчици) използваш???