Hi there,

as you might have gathered from my previous posts, I am quite interested in numerical/scientific computing.

I have no idea how many experts in this area have had a look on the current state of the D language. From all I can gather, the scientific community has not really taken much notice of this great language at all.

From what I have read so far, D really has the potential to close the gap between C++ and Fortran and in this way gain a huge share in the scientific/high-performance area of computing. Anyway, to have any chance to go there, much care has to be taken now.

People unfamiliar with numeric programming often wonder why Fortran still has such a huge share among scientists. Many scientists still use Fortran77 and even those who have moved to Fortran95 only use it for its modern syntax, never touching the advanced concepts of it. And this is not only because they don't know better, but also because it is extremely hard to match the performance of Fortran77! (OK, 99% of the reason might actually be the lazyness to learn a different language and the existing code-base, but still people usual argue based on the superior performance of the language)

Actually, programming in Fortran77 is not much different from programming in plain old C (different syntax, many differences in details, but similar philosophy) Anyway, there are rather subtle details in the language definition of C that prevent optimization of the code the same way good Fortran compliers can do. Therefore the same algorithm  is very often somewhat slower in C. (The difference may be marginal but big enough for Fortran-believers to defend their language...)

Many people have spent a lot of time on C and C++ to repair at least the most pressing details (one of the results of that is the "restrict" keyword introduced recently)

It would really be advisable to get numerics experts (preferably those who worked on trying to close the gap between C/C++ and Fortran) to take a look at D and try to eliminate showstoppers before the language has been standardized. I don't claim to be an expert in these matters, but I have digged into the subject deep enough to realize how close one has to look to understand the issues of true high-performance computing in scientific applications.

For those interest in more details, the forum at http://www.oonumerics.org might be a good starting point.

Ciao,
Nobbi

I think what you propose is sensible. Who knows where we can did up some scientific programmers?

"Norbert Nemec" <Norbert.Nemec@gmx.de> wrote in message news:c65fmi$2js$1@digitaldaemon.com...
> Hi there,
>
> as you might have gathered from my previous posts, I am quite interested in numerical/scientific computing.
>
> I have no idea how many experts in this area have had a look on the current state of the D language. From all I can gather, the scientific community has not really taken much notice of this great language at all.
>
> From what I have read so far, D really has the potential to close the gap between C++ and Fortran and in this way gain a huge share in the scientific/high-performance area of computing. Anyway, to have any chance to go there, much care has to be taken now.
>
> People unfamiliar with numeric programming often wonder why Fortran still has such a huge share among scientists. Many scientists still use Fortran77 and even those who have moved to Fortran95 only use it for its modern syntax, never touching the advanced concepts of it. And this is not only because they don't know better, but also because it is extremely hard to match the performance of Fortran77! (OK, 99% of the reason might actually be the lazyness to learn a different language and the existing code-base, but still people usual argue based on the superior performance of the language)
>
> Actually, programming in Fortran77 is not much different from programming in plain old C (different syntax, many differences in details, but similar philosophy) Anyway, there are rather subtle details in the language definition of C that prevent optimization of the code the same way good Fortran compliers can do. Therefore the same algorithm  is very often somewhat slower in C. (The difference may be marginal but big enough for Fortran-believers to defend their language...)
>
> Many people have spent a lot of time on C and C++ to repair at least the most pressing details (one of the results of that is the "restrict" keyword introduced recently)
>
> It would really be advisable to get numerics experts (preferably those who worked on trying to close the gap between C/C++ and Fortran) to take a look at D and try to eliminate showstoppers before the language has been standardized. I don't claim to be an expert in these matters, but I have digged into the subject deep enough to realize how close one has to look to understand the issues of true high-performance computing in scientific applications.
>
> For those interest in more details, the forum at http://www.oonumerics.org might be a good starting point.
>
> Ciao,
> Nobbi

Matthew wrote:

> I think what you propose is sensible. Who knows where we can did up some scientific programmers?

I already contacted the mailing list at oonumerics that should be perfect for this purpose. I hope I'll attract people from there and get some discussion going on the list (which would probably attract even more people to take a look at D)

Norbert Nemec wrote:

> Hi there,
> 
> as you might have gathered from my previous posts, I am quite interested in
> numerical/scientific computing.
> 
> I have no idea how many experts in this area have had a look on the current
> state of the D language. From all I can gather, the scientific community
> has not really taken much notice of this great language at all.
> 
> From what I have read so far, D really has the potential to close the gap
> between C++ and Fortran and in this way gain a huge share in the
> scientific/high-performance area of computing. Anyway, to have any chance
> to go there, much care has to be taken now.
<snip>

You've practically taken the words out of my mouth here.  My university department uses Fortran 90, though there is still some F77 legacy code around.

Apparently they think C++ is too complex, or at least that OOP is an unnecessary complexity as far as scientific programming is concerned.  I don't know if my department could be persuaded to adopt D, considering its simplicity over C++.  It probably wouldn't happen in my time, particularly considering the number of things that have been recently redesigned and rewritten in F90 (including my code, which was in C++ before).

The features I like in F90 (and which are useful for SP) are built-in vector arithmetic and aggregate functions.  The former is in the D language, it just needs to be finally put into the compiler.  I've briefly suggested the latter....
http://www.digitalmars.com/drn-bin/wwwnews?D/21671

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:
> The features I like in F90 (and which are useful for SP) are built-in vector arithmetic and aggregate functions.  The former is in the D language, it just needs to be finally put into the compiler.  I've briefly suggested the latter.... http://www.digitalmars.com/drn-bin/wwwnews?D/21671

I don't really know how much of that has to be in the language. It is nice to have arrays as part of the language, but vectors and matrices should rather be defined in the library. There are plenty of efficient ways to deal with arrays, which can be implemented in a very efficient way by optimizing (perhaps also parallelizing) compilers.

Vector arithmetic actually gives arrays special matrix semantics which is not what you would want in general. By far not every array is a matrix so why should it behave like one?

vector arithmetic and aggregate functions may just as well be defined in the library. Just encapsulate arrays in your own class and give it all the semantics you need, without forcing everyone else to get that semantics when his arrays are something completely different.

Norbert Nemec wrote:

> Stewart Gordon wrote:
> 
>>The features I like in F90 (and which are useful for SP) are built-in
>>vector arithmetic and aggregate functions.  The former is in the D
>>language, it just needs to be finally put into the compiler.  I've
>>briefly suggested the latter....
>>http://www.digitalmars.com/drn-bin/wwwnews?D/21671
> 
> I don't really know how much of that has to be in the language. It is nice
> to have arrays as part of the language, but vectors and matrices should
> rather be defined in the library. There are plenty of efficient ways to
> deal with arrays, which can be implemented in a very efficient way by
> optimizing (perhaps also parallelizing) compilers.

The same applies to vector arithmetic.

> Vector arithmetic actually gives arrays special matrix semantics which is
> not what you would want in general. By far not every array is a matrix so
> why should it behave like one?

If you don't want to do arithmetic on a certain array, you don't have to.

> vector arithmetic and aggregate functions may just as well be defined in the
> library. Just encapsulate arrays in your own class and give it all the
> semantics you need, without forcing everyone else to get that semantics
> when his arrays are something completely different.

Operating on each element of an array is an intuitive and common concept, hence arguably a reasonable default.  One that saves having to define a class for such a simple task.  It also saves having to do two memory allocations for every vector.

It also doesn't prevent someone from encapsulating an array in a class, and defining operations on it, for more specialised purposes.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Sorry, misunderstanding of terms. Obviously you mean
"vector arithmetic"="elementwise operations" - there I fully agree with you.
It is good to have that in the language. I was just disturbed by an
association of vectors with linear algebra with matrix arithmetic. And that
definitely should go in the library.

For aggregates, though, I'm still not sure, whether sum,product,max,min, etc. have to be in the language or whether they could just go in the library. Might be an idea, though, thinking of parallelizing compilers.

> From what I have read so far, D really has the potential to close the gap between C++ and Fortran and in this way gain a huge share in the scientific/high-performance area of computing. Anyway, to have any chance to go there, much care has to be taken now.

In general I'd be pleasantly surprised if D is faster than C/C++ for scientific programming. I was just updating my GMP (www.swox.com/gmp) D wrapper and I timed the D object wrapper vs the C++ object wrapper supplied with GMP on evaluating an expression with about 10 terms thousands and thousands of times and the D version took 2.7 second and the C++ took 3.2 seconds. The reason is that the D version is reusing temporary values and the C++ version doesn't. If I don't recycle temporaries the GC overhead causes the D version to be slower.

-Ben

Add primitive-units-checking to D and a lot of people who work with numbers will
fall in love with D. What is primitive-units-checking? It is something we miss
in C++ or Java(I have never read a line of Fortran :$ ), that is being teach in
physic 101 and that could have avoid a Nasa probe crash on Mars(not the digital
one) few years ago(I dont remember the name of the probe sorry. It was a
forgoten miles-kilometers convertion factor problems). Check the following code
written in a fictive language and you will understand what was meant by
primitive-units-checking
float<meter>        distance = 100.0;
float<second>       time     =   3.0;
float<meter/second> speed1;
float<second>       speed2;
float<feet/second>  speed3;

speed1 = distance/time; // no error
speed2 = distance/time; // generate compile-time error
speed3 = distance/time; // ok only if the compiler knows the conversion

// factor between meters and foot because the //compiler can do the conversion for us automatically

As you migth have guessed, the notation float<meter> has nothing to do with c++ templates and wouldnt interfere with it since it can only be used with primitives. Notice that float<meter> still is a primitive. Of course, a lots of units are way more complex than meter/second in scientific equations. And its what would make primitive units checking a time-saving feature in D for scientific computing.


newbie11234

Sounds cool!  I'd like to try some template stuff to accomplish this.

Mars Climate Orbiter was the name of the probe btw :).

Charles

lacs wrote:
> Add primitive-units-checking to D and a lot of people who work with numbers will
> fall in love with D. What is primitive-units-checking? It is something we miss
> in C++ or Java(I have never read a line of Fortran :$ ), that is being teach in
> physic 101 and that could have avoid a Nasa probe crash on Mars(not the digital
> one) few years ago(I dont remember the name of the probe sorry. It was a
> forgoten miles-kilometers convertion factor problems). Check the following code
> written in a fictive language and you will understand what was meant by
> primitive-units-checking
> float<meter>        distance = 100.0;
> float<second>       time     =   3.0;
> float<meter/second> speed1;
> float<second>       speed2;
> float<feet/second>  speed3;
> 
> speed1 = distance/time; // no error
> speed2 = distance/time; // generate compile-time error
> speed3 = distance/time; // ok only if the compiler knows the conversion
> 
> // factor between meters and foot because the                           //compiler can do the conversion for us automatically
> 
> As you migth have guessed, the notation float<meter> has nothing to do with c++
> templates and wouldnt interfere with it since it can only be used with
> primitives. Notice that float<meter> still is a primitive. Of course, a lots of
> units are way more complex than meter/second in scientific equations. And its
> what would make primitive units checking a time-saving feature in D for
> scientific computing.
> 
> 
> newbie11234