Ada noob here! Is Ada widely used?
in [ADA]
|
Prev: Symbolic tracebacks on Debian (Was: About static libraries and Debian policy)
Next: Gnat cross compiler
From: John B. Matthews on 5 Jun 2010 16:15 In article <hudsf0$41p$1(a)speranza.aioe.org>, "Nasser M. Abbasi" <nma(a)12000.org> wrote: > I am learning to use complex numbers in Ada from wiki Ada book, was > looking at the examples here: > > http://en.wikibooks.org/wiki/Ada_Programming/Mathematical_calculations#Complex_arithmethic You might also like the examples in this project: <http://home.roadrunner.com/~jbmatthews/misc/groots.html> The test driver (croot.adb) only instantiates one generic, the Generic_Roots procedure itself; others are predefined in the library, as described in ARM G.1.1(25/1): <http://www.adaic.com/standards/05rm/html/RM-G-1-1.html> I avoid use clauses, preferring renames, although tastes vary: package NCT renames Ada.Numerics.Long_Complex_Types; package NCA renames Ada.Numerics.Long_Complex_Arrays; A use type clause makes the operators visible: use type Ada.Numerics.Long_Complex_Types.Complex; -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: tmoran on 5 Jun 2010 16:41 > > The word "model" is key. It is meaningless to talk about whether > > something, software or hardware, *is* stochastic - but one can observe > > whether a stochastic *model* of the system is helpful or not. > > Hmm, I think a physicist would strongly disagree with that. AFAIK, there is > no working deterministic models of quantum processes. A fair number of physicists have tried to find a hidden-variable deterministic version of quantum mechanics. In the meantime, engineers quite successfully used the probabilistic model to build working devices. > 1. Confidence has nothing to do with probability. It is an absolutely > different model of uncertainly. That returns us to the square one. > Confidences and probabilities are incomparable. > > 2. Your confidence describes you, it does not the program. It fact, it is > like - I give my word, it works. Fine, but why anybody should trust my > word? We fundamentally differ. I use statistical decision theory, which takes costs of outcomes and *estimated probabilities* of outcomes, to make decisions. All I have is my best estimates, ie, confidence levels. I don't know the "absolute probability" of an event, and if you define that by frequency of occurrence, you really need to wait till the end of the universe to finally nail that down.
From: Maciej Sobczak on 5 Jun 2010 17:16 On 5 Cze, 14:59, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > As for different types of the real and imaginary parts, it would make > little or no sense because you can "rotate" numbers by multiplying them to > exp(j*angle). Nobody said that such a "rotation" must make sense in every single application domain. If it does not make sense in a given domain, then it does not have to be supported. I can perfectly imagine a domain where only the addition/substraction operation for complex and multiplying/dividing complex by scalar are necessary. > So the complex space must be isotropic So it does not have to be and Ada, as a language that promotes careful selection of types for the given purpose, would be more consistent by allowing separate base types for both components. Otherwise the model is simplified. Not necessarily bad, but certainly simplified. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4
From: starwars on 5 Jun 2010 18:43 > How do Interfaces.COBOL and Ada.Text_IO.Editing fit in here? The support is there to do the work, it's just much harder and uglier to do in Ada than COBOL. COBOL has built-in types for money and editing (COMP-3) but in Ada you have to have the Data Processing Annex and unfortunately many toolchains don't offer it. Even with the support, it's painful to do financial reporting on a large scale in Ada. COBOL wins here. It should, it was designed specifically for this above all else.
From: Robert A Duff on 5 Jun 2010 18:56
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> writes: > BTW, as the name suggest "complex" is not "elementary"! (:-)) The name Generic_Complex_Elementary_Functions is amusing (see G.1.2). ;-) > Well, in fact I don't know why ARM defines that, because beyond the name > there is nothing that could distinguish them from other types. Well, elementary types are pass-by-copy, but you're basically right -- there's not much to distinguish them from composite types. - Bob |