Ada for numerics computation (i.e. forget Fortran ?)

Ada for numerics computation (i.e. forget Fortran ?)

[Hans N. Beck]

Hi,

does anyone has experiences with Ada and numerical
applications ?
Does Ada fit for this ? It's not only a question of types
available, but also
of efficiency (speed) of the compilers. Yeeeees I know, in
the most cases Fortran
is used, but perhaps anyone walks on new fields ?

Thanks !

Hans

--
            Dipl.-Ing. Hans N. Beck
 --------------------------------------------
  Technischer + didaktischer Computereinsatz
 --------------------------------------------
        Waldstr. 28, D-75045 Walzbachtal

        \   Tel: +49 (0)7203 922280   /
         \  Fax: +49 (0)7203 922281  /
          \ Handy:    0177 5383233  /

           eMail: hnbeck@t-online.de

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Gautier]

> does anyone has experiences with Ada and numerical
> applications ?

Yes, me ;-)

> Does Ada fit for this ?

Yes.

> It's not only a question of types
> available, but also
> of efficiency (speed) of the compilers. Yeeeees I know, in
> the most cases Fortran
> is used, but perhaps anyone walks on new fields ?

* Speed: same between DEC Fortran & DEC Ada, Lahey Fortran and GNAT/DOS
for simple things. (pragma suppress_all -> =Fortran; else -> slower for debugging).
For big programs Ada is faster with a smart usage
of cross-package inlining (available with GNAT) and subtyping.

* Coding time, debugging time, human energy: you _can_ forget Fortran!

There are plenty of numerics resources there:
  http://amok.ast.univie.ac.at/~stift/stift_home.html
For finite elements, sparse matrices, etc. contact me for some sources.

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Gautier]

> * Coding time, debugging time, human energy: you _can_ forget Fortran!

Preventive warning: I didn't write you _must_ forget Fortran
- in case people mixing religion and programming read it...
Just personal + collected around experiences!

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Markus Kuhn]

In article <372083A1.45A5EB97@t-online.de>, HNBeck@t-online.de (Hans N. Beck) writes:
|> does anyone has experiences with Ada and numerical
|> applications ?

Have you seen

  http://amok.ast.univie.ac.at/~stift/stift_home.html

which is a web page that propagates the use of Ada95 in
astrophysics number crunching.

|> Does Ada fit for this?

It think it does! You have all the types available (including complex),
you have a better exception handling than in Fortran, and with tasks,
you have a powerful construct for using parallel processors. Ada is
certainly much better suited than C, which thanks to the array/pointer
duality prevents many of the strong optimizations that number-crunching
applications need on modern RISK architectures. C implicitely assumes
that arrays have to be stored always in RAM (as opposed to registers),
while compilers can handle non-aliased Ada arrays much more flexible.

(I actually wonder, whether GNAT 3.11p does produce more efficient
code for non-aliased arrays than the corresponding C code, or whether
GNAT limits itself to the optimization capabilities of gcc.)

|> It's not only a question of types available, but also
|> of efficiency (speed) of the compilers.

You get Ada compilers today that are quite comparable in efficiency
with C compilers. On more exotic architectures such as super
computers, you might not find the same level of optimization yet
as it is available for Fortran 77 compilers. It depends a lot on the
architecture.

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Ada for numerics computation (i.e. forget Fortran ?)

[bglbv]

mgk25@cl.cam.ac.uk (Markus Kuhn) writes:

> In article <372083A1.45A5EB97@t-online.de>, HNBeck@t-online.de (Hans N. Beck) writes:
> |> does anyone has experiences with Ada and numerical
> |> applications ?
> 
> Have you seen
> 
>   http://amok.ast.univie.ac.at/~stift/stift_home.html
> 
> which is a web page that propagates the use of Ada95 in
> astrophysics number crunching.

I had an email exchange with Martin Stift a few days ago, in which
he expressed wonderment at the fact that his stuff drew no reaction
at all for years, and then suddenly in the past few months he's
been getting lots of feedback. Nice. (But please don't overload him
with code maintenance requests: I for one am also interested in
his research on Cepheids...)

> |> Does Ada fit for this?
> 
> It think it does! You have all the types available (including complex),
> you have a better exception handling than in Fortran, and with tasks,
> you have a powerful construct for using parallel processors. 

As an experienced Fortran user who is experimenting with Ada 95 for
some (small-scale, to begin with) numerical projects, let me comment
on this.

The types are indeed available (and the type system itself is much
better than that of Fortran in my view, although I'm quite certain that
most of my colleagues would disagree with me on this). The array
operations, however, are not. Some of them can be implemented in
user-defined packages, but I wouldn't want to bet that Ada compilers
are very good at optimising away array temporaries. (Many Fortran
compilers also leave to be desired in this area, but at least the more
serious vendors are working on this sort of thing.) I've found that
GNAT, for example (3.10p; I haven't had time to upgrade to 3.11 yet),
seems to require a lot of stack space to execute something like
   Big_2d_Array := (others => (others => 0.0));
as if it was allocating a temporary for the right hand side, then
copying the result to the left hand side. Recoding this as two nested
loops got rid of the stack overflow. This was all with -O3, by the way.

As for Ada tasking making it easier to program parallel processors,
I don't buy that claim. The problem with Ada tasking is that the
programmer has to make it explicit. This is in stark contrast to
Fortran's pragma-based schemes (OpenMP, HPF) where the compiler takes
care of the details and the programmer only supplies a few hints.
Ada and Fortran are on more of an equal footing where explicit
message-passing parallelism (based for example on the MPI standard)
is concerned. But this paradigm is better described in terms of Annex E
stuff than of tasking constructs.

Perhaps an OpenMP-style parallel Fortran program could be translated
using Ada tasks, at least in some cases. The obvious platform to
benchmark this on would be SGI. I don't have time to try it myself
(and I've always steered clear of parallelism as much as I could,
since it's a big sink of developer's energy), but perhaps someone
else will. The results would be well worth publishing, if that can
help.

>                                                              Ada is
> certainly much better suited than C, which thanks to the array/pointer
> duality prevents many of the strong optimizations that number-crunching
> applications need on modern RISK architectures. C implicitely assumes
> that arrays have to be stored always in RAM (as opposed to registers),
> while compilers can handle non-aliased Ada arrays much more flexible.

Yes, there is no doubt that Ada is superior to C. But that's a weak
strawman, as Fortran 95 is itself so much better than C that no one in
his right mind even tries to put them on equal footing. The question
is Fortran 95 vs. Ada 95 vs. C++ 98.

Also, production C compilers from reputable vendors usually support
at least a command-line option (sometimes also a pragma) to permit
no-aliasing assumptions.

> (I actually wonder, whether GNAT 3.11p does produce more efficient
> code for non-aliased arrays than the corresponding C code, or whether
> GNAT limits itself to the optimization capabilities of gcc.)

The gcc back-end is being improved in this area to support g77 (and
GNAT too, I suppose), so the two possibilities are not mutually
exclusive.

> |> It's not only a question of types available, but also
> |> of efficiency (speed) of the compilers.
> 
> You get Ada compilers today that are quite comparable in efficiency
> with C compilers. On more exotic architectures such as super
> computers, you might not find the same level of optimization yet
> as it is available for Fortran 77 compilers. It depends a lot on the
> architecture.

And on the coding style. (This is reportedly also true of C++,
and in any case it should come as no surprise.) There is a learning
curve both for users (who have to learn about the relative efficiency
of various approaches) and for compiler developers (who tend to work
hardest on optimising the constructs they see in user code, and will
need to see a lot of number-crunching applications in Ada for their
guidance). Exactly the same issues arise with Fortran users and
Fortran compiler writers, the difference being that progress has been
more rapid because the user base is larger. (To avoid misunderstandings,
I'll underline: _for classical number-crunching applications_. I'm not
in a position to comment on other application domains.)

At this time I wouldn't commit to Ada for my heavily CPU-bound applications
(which I'm not going to recode from scratch anyway, for obvious reasons).
But I have no doubt whatsoever that something like "Numerical
Recipes in Ada 95" would be appropriate. (Well, except for the fact
that Numerical Recipes code is meant as an illustration of the various
techniques involved, not as industrial-strength reusable software.)

If you *really* want to "sell" Ada to a Fortran user, show him/her how
to instantiate generics. (It helps if you have useful generics at
hand, and that's where something like Numerical Recipes would fit
into the picture.)

And of course Ada is a perfectly fine choice for a number of support
tools (visualisation, file format conversion, etc.) that are also part
of supercomputing's bread and butter. That alone can make it worth
learning. Recently I got a colleague interested in learning C simply
by solving an endianness problem he had with a few routines out of my
toolbox, which I customized under his eyes. Had my solution been in
Ada (and it would have been more elegant in Ada), I might just as
easily have hooked him on that. (Well, except I couldn't have pointed
him to an Ada reference book in the reading room the way I did with
K&R.)

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Edwin Guenthner]

bglbv@my-dejanews.com wrote:


> I had an email exchange with Martin Stift a few days ago, in which
> he expressed wonderment at the fact that his stuff drew no reaction
> at all for years, and then suddenly in the past few months he's
> been getting lots of feedback. Nice. (But please don't overload him
> with code maintenance requests: I for one am also interested in
> his research on Cepheids...)

Probably the reason for this is the Java hype. People suddenly 
realize that there are more languages in this world than just FORTRAN. 

There are even some people who think that Java will be the future in
numerical computing (see http://www.javagrande.org/).

I dont know if this is true - I just hope it and wait for things to happen.

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Robert Dewar]

In article <7fvbth$4m4$1@news.rz.uni-karlsruhe.de>,
  Edwin Guenthner
<s_guenth@studsun1.informatik.uni-karlsruhe.de> wrote:
> There are even some people who think that Java will be
> the future in numerical computing (see
> http://www.javagrande.org/).

Seems unlikely unless the fundamental problems with the
floating-point model of Java are solved. The current
spec requires disastrously inefficient execution modes
on many high performance machines.

The goals of absolute portability and high performance are
seriously incompatible when it comes to floating-point if
by portability you mean bit-for-bit identity in results.

Robert Dewar

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada for numerics computation (i.e. forget Fortran ?)

[bill]

In article <7fvbth$4m4$1@news.rz.uni-karlsruhe.de>, Edwin says...
>
 
>
>There are even some people who think that Java will be the future in
>numerical computing (see http://www.javagrande.org/).
>
 
I like Java, but for numerics?

There is no user defined operators, so instead of writing

a = (b * (c +d)) / h ;  -- where a,b,c,d,h are non primitive data types

one would write

a = b.multiply(c.add(d)).divide(h);

Now, really, which is better?

Also, in java, the Interger, Float, Long etc.. types, can't be used to
limit the range they are define over. For example, in Ada, I can have a
variable of type integer, but limit this varible to only takes
values between say 0..100, and have the run-time check when/if I try to write
a value outside this range.

This is good, since it allows me to design my data types to match the
problem domain. of course, one can make a java class to do that, but it 
is not part of the language.  Ada allows me to have closer correspondess
between my datatypes and the physical system. C/C++ /Fortran/Java do not
without doing more work on your part to program these limits in.

Also, Java has no enumeration datatype. bad bad. (how could one design
a language in this modern age, and not have an enumeration data type?)

The only thing that Java has over any other language nowadays, is that it
has a much richer standard API to do so many things (from GUI, database,
graphics, networking, distributed, animation, tasking, etc..) With Java, 
one can, out of the box, do many more things with it than in Ada. 
This will remain so, unless, and untill, Ada gets a standard library 
that is many orders of magnitudes more extensive than the current one.
 
Bill

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Edwin Guenthner]

> I like Java, but for numerics?

Of course, there are a lot of problems (the people from JavaGrande
came up with some more). But AFAIK Sun knows about this. There are some
things going on (for example I extended a compiler to use complex numbers
like a basic type with java ;-).
Lets see what happens during the next months.

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Edwin Guenthner]

Have a look at:
http://www.cs.unc.edu/Research/HARPOON/
Or check out "ninja" at www.alphaworks.ibm.com

And there is really a lot of stuff at www.javagrande.org. 
People know about all those problems ... and hope that SUN will
take care of some of them.

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Markus Kuhn]

Edwin Guenthner <s_guenth@studsun1.informatik.uni-karlsruhe.de> writes:
|> And there is really a lot of stuff at www.javagrande.org. 
|> People know about all those problems ... and hope that SUN will
|> take care of some of them.

Why would one want to wait until the problems that Java has with
number-crunching applications are fixed in the year 2010 (which
would turn it de-facto in a completely new language, just as the
smartcard subsetting has done), if Ada95 is already a suitable
and excellently supported platform available today?

Every language has applications that it is particularly suited for.
In the case of Java, the paramount design goal was portability-over-
everything. There sure is some market for that, and it sure is not
number crunching. In numerical applications, you are interested
in speed-over-everything plus some assurance over how
your numeric types behave. I don't see, why the number
crunching community should get excited about a super-portable
byte-code interpreter language with a sophisticated GUI API.
A language designed for programming GUIs in set-top boxes
and Web browsers couldn't be further away from what you want to run
your finite-element code on. I do see a number of reasons however,
for why the number crunching community should get interested in
Ada95 as an alternative to Fortran90 and Fortran95.

The childish hype surrounding "Javajavajava" is what has most of all
turned me a bit against this language. Java is praised by too many
people for applications completely outside its legitimate field,
including smartcards, embedded computing, number crunching, image
processing, AI, systems programming, etc. Java is well on the way
of turning from a programming environment into a religion, and for
me at least, this means that healthy scepticism is adviseable. The
Ada community also has an excellent language, but treats it pragmatically
and with more maturity.

Next we hear that Python is the number-crunching language of the
future ... 8-)

Markus
(who participated in his first programming language
flame war at the age of 12 and still enjoys it)

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Jean-Pierre Rosen]

bill@ a �crit dans le message <7fvpl8$mpm@drn.newsguy.com>...
[lot of interesting stuff deleted]

Don't forget also the problem with arrays and dynamic allocation.
Since every object is dynamically allocated, a 100x100 array of
anything but simple types will require 10_000 dynamic allocations.
Since there are NO multi-dimensionnal arrays (only arrays of arrays),
even a 100x100 array of int will require 100 dynamic allocations.

Moreover, the "array of arrays" paradigm has a very unfortunate
consequence: if you clone an array of arrays, only the *first*
dimension gets cloned, i.e. you get a array which is partially cloned,
partially shared. Such a beast has neither a value nor a reference
semantics! And since arrays have no definitions of their own, it is
not possible to redefine a "clone", unless you package your array into
something else.

When I see benchmarks telling that Java is almost as fast as compiled
code, I really wonder if the benchmarks included things like matrix
operations... Does anyone have figures of Java efficiency in this area
?
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Matthew Heaney]

me@me writes:

> I think the reason for Java popularity is that people in general were not
> happy with C++ (too complicated, etc..) , and wanted a different OO 
> language, and Java came at the right time, and it looked like C++ to 
> keep the crowds happy.

I doubt it.  The only people who think C++ is too complex are the
marketing people at Sun, who spend millions selling the
complexity-is-bad idea to the rest of us.

Programmers want expressive languages that allow them to compose
powerful abstractions.  Mostly they don't care about language
complexity, in spite of what Sun says.

Re: Ada for numerics computation (i.e. forget Fortran ?)

[dennison]

In article <m3wvyyt1er.fsf@mheaney.ni.net>,
  Matthew Heaney <matthew_heaney@acm.org> wrote:
> me@me writes:
>
> > I think the reason for Java popularity is that people in general were not
> > happy with C++ (too complicated, etc..) , and wanted a different OO
> > language, and Java came at the right time, and it looked like C++ to
> > keep the crowds happy.
>
> I doubt it.  The only people who think C++ is too complex are the
> marketing people at Sun, who spend millions selling the
> complexity-is-bad idea to the rest of us.

I suspect Niklaus Wirth and fans of Oberon would disagree with this statement.

--
T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Ada for numerics computation (i.e. forget Fortran ?)

[me]

In article <7g1qcm$o4$2@pegasus.csx.cam.ac.uk>, mgk25@cl.cam.ac.uk says...
>

>The childish hype surrounding "Javajavajava" is what has most of all
>turned me a bit against this language. 

But hype sells !

I think the reason for Java popularity is that people in general were not
happy with C++ (too complicated, etc..) , and wanted a different OO 
language, and Java came at the right time, and it looked like C++ to 
keep the crowds happy.

One thing that I did not see many discuss about java, is its default use
of references.

What I do not like in Java, is that it is not 'value' based by default.

meaning, when I write (where A and B are objects):

A = B;

then I go and modify the value of object B in some other part of 
the program, this results in A's value also being modified.


This is a side effect of the fact that in Java, objects are references,
hence in the above assignment, A takes on the same reference as B, making
A and B references to the same 'object' data on the heap.

(In simpler terms, A and B point to the same object on the heap).

(this one time caused subtle a bug in one of my programs, when I started
learning Java, as I was used to value-based languages, untill I 
noticed this. I was 'saving' objects in a vector, then reading new values
into the source objects, but this was also causing the objects in the
vector to change indirectly).

To make A get its own value of the object B, one needs to be explicit and
write

A = B.clone();

(Assuming B supports the clone() method).

So, in Java, to get the value, you need to be explicit, else you get
the reference (pointer).

In Ada, (and C++), they are value based, i.e. the default in assignment
is to get the value of the object. If you need to get a reference, you
need to be explicit.

Some people might not consider this a big deal, and can get used to it
(as with LISP). For me, I find that I spend more mental energy while 
programming in Java for the above reason, to watch out for when I need
to use clone() or not. I do not have this problem with value based languages,
such as Ada.

What do you like more? or think is better, value-based assignments, or 
reference based?
(I assume you would prefer value-based if you are an Ada programmer).

me.

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Joachim Schroeer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]


Hans N. Beck schrieb in Nachricht <372083A1.45A5EB97@t-online.de>...
>Hi,
>
>does anyone has experiences with Ada and numerical
>applications ?
>Does Ada fit for this ? It's not only a question of types
>available, but also
>of efficiency (speed) of the compilers. Yeeeees I know, in
>the most cases Fortran
>is used, but perhaps anyone walks on new fields ?
>
>Thanks !
>
>Hans

Ada is excellently apt for numerical software.
I wrote a little publication for the OOP 97 (in german, "Numerische und
symbolische Mathematik mit Ada 95"). There are some 30000 lines of code
showing the use of Ada for state space systems and numerical integration
and for symbolic mathematics. The software as well as the documentation
(180 pages in german) are freely available from the following source:

http://www.cci.de
ftp://cci.de/pub/Ada/Numeric/         oopmath.tgz  &  read.me

There are a some generic packages for simple linear algebra like
vectors and matrices. In the 80's at the university of paderborn a group of
4 students / assistants also implemented a subset of the linpack/eispack
algorithms in Ada 83, especially linear algebra, svd, eigenvalues. This
software is well tested and still is used in the institute for controller
design
and nonlinear simulation. It's not yet on any public internet server, but
the
leader of the institute (Prof. Dr.-Ing. J. L�ckel) allowed to make it
public.
I want to sort the Ada 83 packages into my new Ada 95 package
hirarchy before making them available, but seldom have time for that
task.

Dr.-Ing. Joachim Schr�er
AMST-Systemtechnik GmbH
Postbox 3
A-5282 Ranshofen, Austria
Tel.: (++)43 7722 892 30
E-Mail: schroeer@amst.co.at

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Jean-Pierre Rosen]

me@me a �crit dans le message <7g4av3$bgd@drn.newsguy.com>...
[good stuff about reference semantics deleted]
>To make A get its own value of the object B, one needs to be explicit
and
>write
>
>A = B.clone();
>
>(Assuming B supports the clone() method).
>
But, as I noted in a previous message, this doesn't work if A and B
are two-dimensional arrays. You should then write:
for (i=0; i<B.length; i++)
  A[i]=B[i].clone()
... unless A and B are tri-dimensional arrays, in which case you
should write:
  (etc, etc.)
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Edwin Guenthner]

Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote:

>
> But, as I noted in a previous message, this doesn't work if A and B
> are two-dimensional arrays. You should then write:

Pardon? There is now law in Java that says:
you are not allowed to write a clone method which will give you a deep
copy of a whole array. 

You have to iterate over all fields - but you should hide this detail 
from your user.

Re: Ada for numerics computation (i.e. forget Fortran ?)

[Jean-Pierre Rosen]

Edwin Guenthner a �crit dans le message
<7g6c5v$8tg$2@news.rz.uni-karlsruhe.de>...
>Jean-Pierre Rosen <rosen.adalog@wanadoo.fr> wrote:
>
>>
>> But, as I noted in a previous message, this doesn't work if A and B
>> are two-dimensional arrays. You should then write:
>
>Pardon? There is now law in Java that says:
>you are not allowed to write a clone method which will give you a
deep
>copy of a whole array.
>
>You have to iterate over all fields - but you should hide this detail
>from your user.

The trouble is that arrays are *implicit* classes. AFAIK, there is no
way to redefine a method for stuff[], only for stuff.
Therefore, you must package your array into a class. But if the user
of stuff wants to declare a stuff[], there is nothing you can do.
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog