avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] Some question regarding FP-math


From: David Brown
Subject: Re: [avr-libc-dev] Some question regarding FP-math
Date: Sun, 01 Jul 2012 15:20:52 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 07/01/2012 09:25 AM, Dmitry wrote:
18.06.2012 18:53, Dr. Alexander Klein:
[...]
1. Most if not all transcendental functions are implemented as power
series approximations, but no hints are given as to their properties
of approximation. Are the polynomials or maybe their derivatives
optimal in any L_p-sense? Can a description be found anywhere?

Main reason was the flash usage minimization. Minor reason was a
fast multiplication: avoid division.

2. All we have for the time being is single precision float. Are the
functions for power series evaluation optimised so as to minimise
summation error?

A part of internal calculations is more precision: 32-wide mantissa is
used.

3. In an old post
(http://lists.nongnu.org/archive/html/avr-libc-dev/2006-04/msg00068.html)
someone benchmarked basic arithmetic operations, but only for one
platform. How do other platforms perform? Especially, would it be
worthwhile to try to speed up multiplication?

The avr-libc documention contains a good set of benchmarks. The big
difference between avr2 and avr4 is due to multiplication.

Regards,
Dmitry.


Is there any interest in alternative implementations for some of these functions? I've got some code for calculating sines and cosines using a table with cubic interpolation which I used on another processor. It is probably a little bigger than the current avr-libc implementation, but not too bad - with cubic interpolation the table can be a lot smaller than with linear interpolation. It is also not quite as accurate as power-series implementations tend to be, but it is a lot faster, and accurate enough for many uses.

I'm sure I could adapt the code to the avr. But I don't know the best way to include such code in avr-libc - because it is not accurate enough for IEEE standards, it can't replace the standard implementations.

mvh.,

David




reply via email to

[Prev in Thread] Current Thread [Next in Thread]