OSNews

"thousands of vectors" - sure but why not use C structs .. I'm trying hard to understand this.

There's no operator overloading in C so you'd have to write something like
a=add_vector(b, mul_float_vector(c, d));
which is a lot less readable.

For so many reasons:

- because you might want natural mathematical notation:
Vector result = x1 * vector1 + x2 * vector2;

- because even if you do a C function doing this, like
void foo(float x1, const float *v1, float x2, const float *v2, float *result);
then you will have to redo the work all over again when you want another function that takes not 2 but 3 vectors, returning x1*v1+x2*v2+x3*v3

- because C++ template metaprogramming techniques (specifically, expression templates) allow you have this API,
result = x1*v1+x2*v2+x3*v3;
without the introduction of temporaries so that the code will compile to completely optimized assembly (in particular, the arrays traversed only once). I'm not saying that the trivial implementation does this, I'm saying that C++ makes it possible to make a clever implementation.

- because C++ template metaprogramming doesn't stop here, the compile-time metadata on expression types that you gather can be used to make explicit use of SSE instructions where appropriate (it works very well in above example), and to intelligently determine where to introduce temporaries.

To see that in action, see our lib (link i gave above, don't want to give more links as i'd be self-advertising. In my defense this is LGPL'd software).

Here's one of the reasons why C++ is at a turning point. For a long time, c++ template metaprogramming has been known to be possible, but too heavy for the compiler. Recent compilers change that (e.g. GCC >= 4.2) -- current C++ frontends are becoming very clever and robust. C++0x will make template metaprogramming much more convenient from the programmer's point of view (concepts, static asserts, compile-time constants, variadic templates, template typedefs, rvalue references... we're spoiled)

Fortran isn't touched when it comes to precision when doing Numerical Analysis.

Although its fame, I do not find Fortran better than C or C++ for mathematical operations.

Precision is not a language feature, it's a library feature. Don't know if by precision you mean number of significant digits or numerical stability of algorithms, but in both cases this should go into libraries. The language itself should only provide the bare minimum i.e. the IEEE754 floating-point types supported by CPUs.

Fortran indeed used to have by far the best math libraries, but, mark my words! We're a new generation of C++ math software coming to challenge that situation, and template metaprogramming will be a huge strength here.

Nothing to do with precision. Fortran use the same format than C those days on common machines (IEEE floating point); if you implement the same algorithm, you can in theory have exactly the same results (although differences with compilers mean this will never happen in practice). There is a lot of expertise in fortran numerical code, though, which is why you still have so much code implemented in fortran and used today (blas, lapack, optimization, etc...).

Fortran beats down C (and C++, they are the same here) because it does not have pointers, or more exactly does not have the aliasing problem (different pointers pointing at the same memory address), which makes optimization by compilers so difficult. That's why Fortran is still much faster than C or C++ on most benchmarks.

It has also an array concept: that's why most C++ is a really poor language IMO for numerical code, because everybody has a different, incompatible class for vectors, so the speed you gain from being in C++ is lost converting formats between libraries. This and the fact that the language is way too complicated IMO. I personally believe that C++ is a niche language: it is still the only "industry" language you can use when you need ten of thousand objects touching each other (heavy GUI, games), but I would never use C++ if I had a valid other choice.

Bullshit.

The C library MPFR implements arbitrary precision math with correct rounding. It supports all the basic operations you expect as well as a bunch of others that I have found useful for my research (e.g. polylogarithm). Unless you're doing actual mathematics (in which case you want to either use interval arithmetic (for which there is MPFI) or work over an algebraic number field(I recommend using Sage)), there is nothing more you can ask for in terms of precision. As for performance, I can't complain, though I don't know what Fortran is like.

Off-topic: To be honest, I have neither agreed with nor learned from anything that you ever post here. How do you have 2 fans?

Edited 2008-08-21 04:30 UTC

Yeah, but its readability is like LISP or Prolog.
The Fortran language itself encourages spaghetti code.
Too many implicit rules about variables with names beginning with a letter between i and n automatically being integers.

Python 3000 (or if you put from __future__ import division) is the first language that handles numbers the way I think is most natural. It, like Fortran, allows you to create variables on the fly but it does it in a way that makes sense. If you assign 1 it will be an integer, if you assign 1.0 it will be a float. All divisions are floating divisions. This is natural. If you want integer division you have to use //.