Prev: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
Next: Gnat cross compiler
From: Nasser M. Abbasi on 5 Jun 2010 04:04 On 5/20/2010 11:49 AM, Gautier write-only wrote: > On May 20, 2:53 pm, Duke Normandin wrote: > > >> and in what area(s) does it excel, e.g. data processing, number crunching, graphics, etc? > > It is excellent in these areas, and probably in many others... > _________________________________________________________ I think the fact that complex numbers are not a build-in primitive data type in Ada makes it bit harder to use for number crunching. Fortran, for example, had complex numbers build into the language. I wonder why the orginal designers did not add complex data type to the design of Ada. Other than that, I think Ada would be a very good choice for number crunching, but from what I see, it is very little used in this area. --Nasser
From: Yannick Duchêne (Hibou57) on 5 Jun 2010 05:05 Le Sat, 05 Jun 2010 10:00:07 +0200, Dmitry A. Kazakov <mailbox(a)dmitry-kazakov.de> a écrit: > Another problem which worries me, is program changes. Let I modify the > program, the result is *another* program. How can I talk about the > "reliability" of what? Well, they share some code, but certainly we > cannot > consider source lines random. E.g. Let I modify 0,01% of the source of > 90% > "reliable" program. I can tell nothing about whether the result is 90% > reliable +/- factor * 0.01%. This model just does not work. So this is chaotic (and there is a science which can talk about it too). -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Yannick Duchêne (Hibou57) on 5 Jun 2010 05:24 Le Sat, 05 Jun 2010 10:04:52 +0200, Nasser M. Abbasi <nma(a)12000.org> a écrit: >>> and in what area(s) does it excel, e.g. data processing, number >>> crunching, graphics, etc? >> > >> It is excellent in these areas, and probably in many others... >> _________________________________________________________ > > I think the fact that complex numbers are not a build-in primitive data > type in Ada makes it bit harder to use for number crunching. > > Fortran, for example, had complex numbers build into the language. I > wonder why the orginal designers did not add complex data type to the > design of Ada. > > Other than that, I think Ada would be a very good choice for number > crunching, but from what I see, it is very little used in this area. > > --Nasser May be possible reason is that a complex number is seen a composite type, and how would one fix the type of its two component ? Float ? Fixed ? Both the same ? Different ? And so on. Unless with a special ugly/heavy syntax, difficult to image a way to simply declare a complex type in Ada (unless you do it the C way : one type for all use, without constraints, and no other choices). -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Dmitry A. Kazakov on 5 Jun 2010 05:30 On Sat, 05 Jun 2010 11:05:16 +0200, Yannick Duch�ne (Hibou57) wrote: > Le Sat, 05 Jun 2010 10:00:07 +0200, Dmitry A. Kazakov > <mailbox(a)dmitry-kazakov.de> a �crit: >> Another problem which worries me, is program changes. Let I modify the >> program, the result is *another* program. How can I talk about the >> "reliability" of what? Well, they share some code, but certainly we cannot >> consider source lines random. E.g. Let I modify 0,01% of the source of 90% >> "reliable" program. I can tell nothing about whether the result is 90% >> reliable +/- factor * 0.01%. This model just does not work. > So this is chaotic (and there is a science which can talk about it too). Do you mean chaos theory here? In that context reliability must be redefined. Well, I doubt that chaos theory could efficiently handle that. Although most of programs as well as software developing processes are indeed cyclic/iterative. One could try to apply the theory there. Boarding a plane would you be glad to hear that the software developing process used for its flight system wasn't random? It was CHAOTIC! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Yannick Duchêne (Hibou57) on 5 Jun 2010 05:45
Le Sat, 05 Jun 2010 11:30:08 +0200, Dmitry A. Kazakov <mailbox(a)dmitry-kazakov.de> a écrit: > Boarding a plane would you be glad to hear that the software developing > process used for its flight system wasn't random? It was CHAOTIC! (:-)) In some way (despite the fact is should be all avoided), yes: at least this is a sign that security matter know what to focus on. This end into a very different situation than the one where it could just be said said âreally nobody know at all where a trouble is the most likely to occurs if one ever happenedâ. -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise. |