The Single-precision_floating-point_format has only a precision of 7..
8 decimal digits and a exponent of +- 38.
This results in many problems in filtering for AHS systems and
navigation.
Only Single-precision_floating-point is available in hardware on same
32 bit CPUs.of micro controller.(STM32F4).
I found a lot of problems in implementing mathlab code (80 bit of a
pentium CPU) to 32 bit single-precision_floating-point. Often the code
fails.
Fixed point formats with 2 words (64 bit) run very fast and may have
a good precision, but the implementation is difficult.
Our DCM implementation in paparazzi is running in 32 bit floating
point format and runs fast
and with good precision by the correction of numerical errors.
Heinrich
Felix Ruess schrieb:
Floating
point has a higher range, but _can_ have a lower precision than
fixed-point (which number you need to represent and where you set the
"decimal point" in your fixed-point representation).
So saying that in floating point your position resolution is
2.5m is not quite true... it depends on what value you want to
represent...
A floating point implementation is easier to write as you don't
have to take as much care of selecting a fixed fraction, checking for
overflows, too low precision leading to numerical issues, etc...
It also makes sense to keep the float versions as e.g. the
STM32F4 series have a floating point unit.
On Tue, Jun 26, 2012 at 7:17 PM, Christophe
De Wagter <address@hidden> wrote:
The only point was that the code is more readible so it was a
good starting point
On Jun 26, 2012 7:10 PM, "Chris Wozny" < address@hidden>
wrote:
Christophe,
That's very interesting. I meant to say more precise in terms of
having an integer versus a rational number although now that I put
more thought into it I realize that was a silly statement. If floating
points are both slower on STM32/ARM (and LPC?) and less precise, then
what is the purpose of having them as an option in float_quat and
float_cmpl?
- Chris
On Tue, Jun 26, 2012 at 12:50 PM, Christophe De Wagter
<address@hidden>
wrote:
> floats have LOWER precision as you need to store the exponent. you
loose 13
> bits there. in fixedpoint the exponent is written in the code so
you can use
> all 32 bits to store your number:
>
> e.g. in INT you can encode global position with 1cm resolution,
while in
> float it is 2.5m resolution....
>
> floats are much, MUCH slower in non-floating CPU like our ARM
autopilots...
>
> -Christophe
>
> On Tue, Jun 26, 2012 at 6:05 PM, Chris Wozny <address@hidden>
wrote:
>>
>> All,
>>
>> I had a general question born out of curiousity. I know
floating point
>> numbers are more computationally intensive than fixed point
integers
>> in terms of operations (i.e. multiplication, etc). I was just
>> wondering, what is the difference then between the int_quat
>> stabilization subsystem versus the float_quat one (or
int_cmpl_quat
>> versus float_cmpl if the only difference is fixed-point versus
>> floating point)? In an ideal world where we could compute both
>> operations just as quickly, is there one which is better than
the
>> other due to higher precision of floats? These aren't specific
to any
>> branch, it's just more of a general question that I was
wondering
>> about.
>>
>> Thanks,
>> Chris
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel
|