From: Keith Thompson on 5 Apr 2010 12:44
Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de> writes:
> C99 (note the year) has complex types, says C hasn't. Well, it
> hadn't, as some point in the last century.
Unfortunately, the C99 standard has not yet been universally adopted.
Very few compilers fully support it. Many support most of it,
but I understand that Microsoft's compiler still supports only C90
(with maybe a handful of C99-specific features).
Which means that as soon as you write "#include <complex.h>", you've
limited the portability of your program.
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Charmed Snark on 5 Apr 2010 13:33
Nasser M. Abbasi expounded in news:hp95j8$i29$1(a)speranza.aioe.org:
> I was browsing the net for scientific software written in Ada, and
> came across this strange statement:
> "Scientific programming languages
> What is the best high-level language to use for scientific
Just asking "what is best" in any selection process
is going to be contentious except for the simplest
of things. Somewhat like asking "what is the best
laptop?" Too many inputs to consider.
> This, unfortunately, is a highly contentious question.
> Over the years, literally hundreds of high-level languages have been
> developed. However, few have stood the test of time. Many languages
> (e.g., Algol, Pascal, Haskell) can be dismissed as ephemeral computer
> science fads. Others (e.g., Cobol, Lisp, Ada) are too specialized to
> adapt for scientific use.
> The remaining options are FORTRAN 77 and C. I have chosen to use C "
> I find this strange, because I think Ada can be the best programming
> language for numerical work. So, I do not know why the author above
> thinks Ada is "too specialized to adapt for scientific use".
Surely he expanded on this? How is it too specialized (in his
> Is there
> something in Ada which makes it hard to use for scientific
I recently tried to introduce a co-worker to the fact that
Ada is free and easy to install (cygwin gcc-ada) yada yada.
He started reading a couple of free online (PDF) books and
said his eyes glazed over and that he has no further interest.
I suppose things might be different if there was a job market
for that skill here (Toronto). So that factor seems to be one
important reason for some folks.
Library support would be another factor, I would think. People
don't want to become experts in interfacing to C (for example).
But as I do more and more of this, I am finding this to
be less of an issue. Maybe a good "The Art of Binding [GNAT]
Ada" document would help people with this.
I do feel that Ada does require you to "engineer" your
project more, which is a good thing. But this is something
that some folks seem to dislike. It probably impacts the
inexperienced programmers the most. This is the very
crowd that needs to be won over.
Otherwise, it sounds as if the author has too quickly
dismissed the language, without much familiarity in it.
> The main problem I see with Ada for scientific use is that it does not
> have as nearly as many packages and functions ready to use output of
> the box for this, other than that, the language itself I think is
> better than Fortran and C for scientific work.
One huge improvement I see in Ada-2005, is the built-in
inclusion of Ada.Containers. Having them "included" saves
me from having to instruct downloaders of where and which
version of the Booch components (or was it Charles?) etc.
Having them included means that my project should always
"work" the same, (in theory at least) regardless of the
version of the compiler used.
I am making big use of these containers in the rewrite of
my basic interpreter project. I have got far enough along
now to believe that this is a very practical language
change. I love the higher level of abstraction without
having to forego "repesentation" when it is required.
My only worry remains on compiler portability to HPUX,
Solaris and AIX. But at this point, I am going on faith
that this will not be a huge open source problem
going forward. It is encouraging to see the results of
gcc-ada making it more universally available, and
hopefully increasingly well tested.
I feel that the benefits of an Ada rewrite now seems
to outweigh the risk of compiler availability.
One beauty of open source is that I don't have to
justify the rewrite. But I could easily do that,
as the design is much improved now (I also expect
a big performance improvement later). Rewrites allow
the lessons learned to be applied and Ada is also a
It's funny how I got started on this rewrite- it
was the farthest thing from my mind in January. I was
starting to think about threads and matrix operations
that might benefit etc. The Ada tasking model came
into the thought process at some point. So now I'm
looking forward to designing that into the
interpreter when it gets further along.
Just my own nearly at par $0.02 Cdn.
From: Nasser M. Abbasi on 5 Apr 2010 15:24
"Charmed Snark" <snark(a)cogeco.ca> wrote in message
> I am making big use of these containers in the rewrite of
> my basic interpreter project. >
I looked at the Ada 2005 LRM, Containers.Vectors for example, and And I have
Given this below
function Element (Container : Vector;
Index : Index_Type)
Then to get the element at index 5, one needs to write something like
Is there a way to redefine this so one need to only write V(5) ? because If
I have large equations, it is more clear to write V(i) than Element(V,i)
everywhere? Did you find this "longer" syntax an issue for you?
I have not used Containers before. But the list of functions looks
ps. is your interpreter project somewhere on the net to look at?
From: Warren on 5 Apr 2010 16:28
Nasser M. Abbasi expounded in news:hpddc6$csh$1(a)speranza.aioe.org:
>> I am making big use of these containers in the rewrite of
>> my basic interpreter project. >
> I looked at the Ada 2005 LRM, Containers.Vectors for example, and And
> I have small question
> Given this below
> function Element (Container : Vector;
> Index : Index_Type)
> return Element_Type;
> Then to get the element at index 5, one needs to write something like
> Is there a way to redefine this so one need to only write V(5) ?
You could use V.Element(5), but that doesn't really
shorten the notation.
You could declare an internal function for that purpose, though
there are probably better solutions:
procedure My_Proc(args...) is
package P is new Ada.Containers.Vector(...);
V : P.Vector;
Function XV(X : Index_Type) returns Element_Type is
... := XV(5);
Note however (as I found out, snickers), you can't use the
V.Element() notation when the input value is a cursor. That
kept tripping me up until I clued in-- the cursor specifies
both the container and position internally. So you must use
Element(Csr) form of the call instead, for cursor values.
> because If I have large equations, it is more clear to write V(i) than
> Element(V,i) everywhere? Did you find this "longer" syntax an issue
> for you?
Not really, because when you deal with several containers (Maps mostly
in my case), I tend to spell out the full package heirarchy anyway
for clarity and to avoid hiding caused by "use".
One thing I did do however, was create a SimpMap package that
took care of all of the compare function definitions for me.
I got real tired of redeclaring equality functions for every
new integer/modular type involved.
> I have not used Containers before. But the list of functions looks
> ps. is your interpreter project somewhere on the net to look at?
My Ada rewrite is still in the early stages, so it is not up on
SourceForge yet. If you want to experiment with the C version,
or look at the documentation, you can visit:
or for language and other documentation:
But if you email me directly, I can also send you the tar-balled
Ada version of the project. You'll see a lot of container examples
in it, which might be useful.
From: none on 5 Apr 2010 16:51
On Mon, 05 Apr 2010 13:19:07 +0200, Georg Bauhaus wrote:
> On 4/4/10 6:46 AM, Nasser M. Abbasi wrote:
>> I was browsing the net for scientific software written in Ada, and came
>> across this strange statement:
>> "Scientific programming languages
>> What is the best high-level language to use for scientific programming?
>> This, unfortunately, is a highly contentious question. Over the years,
>> literally hundreds of high-level languages have been developed. However, few
>> have stood the test of time. Many languages (e.g., Algol, Pascal, Haskell)
>> can be dismissed as ephemeral computer science fads. Others (e.g., Cobol,
>> Lisp, Ada) are too specialized to adapt for scientific use.
>> The remaining options are FORTRAN 77 and C. I have chosen to use C "
>> I find this strange, because I think Ada can be the best programming
>> language for numerical work. So, I do not know why the author above thinks
>> Ada is "too specialized to adapt for scientific use". Is there something in
>> Ada which makes it hard to use for scientific programming?
> The text, by Professor Fitzpatrick, Physics, 2006, appears to be an
> fine example of quite useful justification rhetoric.
> (Of the kind well explained by, e.g. Leon Festinger or Irving Goffman.)
> It is full of false facts that in general would offer
> to an author the comforts of blissful ignorance and a convincing
> appearance at the same time. (Who has not been in this situation?
> Assuming that a quick proactive defence of your standing is
> more tempting than the alternative: is to shut up?)
The only reason I can think of is pure fashion - Ada has not been taken up
as a popular programming language for scientific use, therefore it is not
suitable. But choosing a language based on popularity is not the best
approach - although it does have some validity, providing you recognise
that popular today does not mean popular when you *really* need
maintenance on the software.
Dismissing Algol as ephemeral ignores its influence and continuing usage
as a base of pseudo-codes. Important numerical libraries were first
implemented in ALgol, and later translated to Fortran when Algol's
momentum faltered. But that again confuses usefulness of a language for
scientific programming with popularity. Ada is heavily influenced by
Algol, and I can see nothing in Ada that would prohibbit is wider uptake -
other, again, than fashion. It was a language designed to promote
re-usability, maximise correctness, and include efficiency and
portability, and still has a variety of compilers available, so I can't
see any reason why *not* to use it, if you are proficient in its use.