paparazzi-devel
[Top][All Lists]
Advanced

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

Re: [Paparazzi-devel] Proposition for the Core developpers


From: Arnault Ioualalen
Subject: Re: [Paparazzi-devel] Proposition for the Core developpers
Date: Thu, 27 Oct 2011 10:29:54 +0200
User-agent: Internet Messaging Program (IMP) H3 (4.3.7)


Hi Hector,
thanks for your quick answer.

Well, from my experience I could say that the numerical stability of an algorithm is really hard to predict by hand. Because it's strongly dependent on the values that are used. For exemple a polynomial expression is, in general, stable, except when you tried to evaluate it around one of its root (and specially around a multiple root), and sometimes roots aren't easy to know (for higher degree polynomial function for exemple).

Concerning the rounding-error, I'm not sure why they could negligible. On the contrary the more innacurate your sensors are, the more innacurate the calculations could be. The floating-point format (32 bits or 64) is even not relevant because it's only postpone the issue, if the calculation could diverge it will take just more time (i.e. more iterations) to diverge with a higher precision format. Also, most of the time the accuracy do not cause a direct system crash, it's more devious, as the numerical operation are executed without run-time "errors" but still the value are not necessarily the one expected. So the system could be seen as error-free, but it's not ! As I was saying in my last email, our tool take some range of the input variables, but it also takes account of the precision of the input, so that we could predict how a better sensor could improve the accuracy (that one of the requierment that the aeronotic industry in interested in). Typically we try to use the data given by the sensor constructor to know which range the sensor have, and how many digit calculated by the sensor are correct.

For the computational efficiency I'm totally aggree with you : it's critical. Our tool for now could not garantee a specific computational efficiency, but it's on our perspectives (one other phd student of our research team works on that aspect of the problem). For what I can say now, the output program efficiency could be slightly different (in a good or a bad way). Our transformation techniques of the code could introduce a small number of new nodes, or replace some nodes by one node with a different efficency (for exemple introduce more multiplication nodes which are slower to compute). I know that could a problem, but I think I still worth the shot. Because we still may be able to obtain an accurate And efficient version of your algorithms !

For the matter of C or C++ that not a big issue, I think I could input them as well in my analyzer, I'll just have to transform just a little the input code. Or I could start directly from the simulink representation of your program. Either way is good I suppose.

If you're interested to know about how we evaluate the rounding errors I could send you some articles.

Cheers,
Arnault Ioualalen
Phd Student
DALI team - UPVD - LIRMM




Hector Garcia de Marina <address@hidden> a écrit :

Hi Arnault,

first of all, it is always welcome to hear new points of view :P

In my opinion, if I am not wrong, the numerical stability is not a high
issue. Maybe in a Kalman Filter, computing the covariance matrix may be an
issue if it is not a positive-definite matrix.

On the other hand, do your algorithms leads to a better computational
efficiency? As far as I know, all the paparazzi embedded SW is written in C,
and I personally have some C++ code as well.
In real-time systems, this is really an issue.

About the rounding-errors, I guess the low-cost sensors that we use
introduce higher errors (noises), making the rounding-errors negligible in
the algorithms, even in 32bits floating point.

Cheers,
Héctor.


On Wed, Oct 26, 2011 at 5:25 PM, Arnault Ioualalen <
address@hidden> wrote:


Hi,
I contact this mailing list on the advise that CheBuzz gives me on IRC, so
that I could propose to the core developpers to test the numerical accuracy
of their algorithms.

Let me explain that a little :
First I'm a phd student in Perpignan (France), my work concerns the
numerical accuracy of floating-point calculations in embedded software.
Mainly, my work is on the behalf of Airbus, and adresses the issue of
rounding error propagation.

My point is, given
- a code written in some synchronous langage used in the industry (like
LUSTRE),
- and the range of the inputs (of the sensors for example)
I can :
- calculate a safe over-approximation of the numerical error induce by the
program
- propose automatically an equivalent program, this program is
mathematically equivalent but has a better numerical accuracy (I won't enter
into detail here because it's quite technical, but we already developped a
tool call Sardana wich allow us to do it).

Ok, I hope I haven't lost you !
Remember just that each time you use floating-point arithmetics each value
has a rounding error, and these rounding errors accumulate themselves during
the whole process. Some very classical examples exist, where the
rounding-errors became so big that the calculate value has nothing in common
with the expected value.


I saw on your website (http://paparazzi.enac.fr/wiki**) your "theory of
operation" and the graphical representations of your control loops.
From what I could understand it's very much look like my kind of test data,
so I'm gessing that (with some help) I could try to optimize, separatly,
each control loop you have (or, perhaps, even together in one big piece of
code).

My main problem is that I don't really understand what kind of value each
variables could take, and your simulink-like representation may not be
really complete.
Also, I would need some range of the inputs, or even better, a trace of a
real execution of the code with the evolution of the values at each
iteration.


If some core developpers are interested in my proposal, I can answer them
over this email : address@hidden Or, if he lives in
France (and more specifically in Toulouse) I can go there personnaly and
meet him in person, that's not an issue (if it's not in Toulouse I could
still arrange a trip to where he is, it's just little more time-consumming
to organize).

To finish, I'll just want to say that your project could constitute an
important example for my phd thesis and I'm really interested in working
with your team over this topic of numerical accuracy.

Thanks for your answers (I hope there will be some), and sorry for this
long email but it's never easy to make such a proposal in a few lines.


Arnault Ioualalen
Phd Student
DALI team - UPVD - LIRMM

ps: sorry for the possible orthographic errors, but it has been already a
long day.




______________________________**_________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/**mailman/listinfo/paparazzi-**devel<https://lists.nongnu.org/mailman/listinfo/paparazzi-devel>




--
Héctor

--
Ce message a été vérifié par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a été trouvé.
CRI UPVD http://www.univ-perp.fr








reply via email to

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