Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I know something about Pascal, Mathematica and Matlab, but I dont have any idea about C,C++,C# languages.

I want to learn one of the languages that they they are fast and exact to compute some arithmetic functions for large numbers(for example larger than $10^3000$). I asked somebody and he said he used C++ and he said I computed this sequence in less than 10 min.

I want to know C, C++, C# and visual kind of theses programs and know which is better for my goal.

Let $f$ be an arithmetic function and A={k1,k2,...,kn} are integers in increasing order.

Now I want to start with k1 and compare f(ki) with f(k1). If f(ki)>f(k1), put ki as k1.

Now start with ki, and compare f(kj) with f(ki), for j>i. If f(kj)>f(ki), put kj as ki, and repeat this procedure.

At the end we will have a sub sequence B={L1,...,Lm} of A by this property: f(L(i+1))>f(L(i)), for any 1<=i<=m-1

I have written a code for this program with Mathematica, and it take some hours to compute f of ki's or the set B for large numbers.

For example, let f is the divisor function of integers. Do you know how to write the code for my purpose in Mathematica or Matlab. Mathematica is preferable.

share|improve this question
what sort of calculations do you want to make? Matlab is probably as good as C++ for just integer arithmetic, especially if you're already familiar with it. –  TZHX Jan 28 '11 at 9:08
Are you interested in exploring the mathematics (e.g. number theory), or reimplementing computational number theory algorithms in a mainstream programming language? These goals are somewhat different. –  rwong Jan 28 '11 at 11:43
my question is similar to this one: stackoverflow.com/questions/4830953/… –  asd Jan 28 '11 at 23:56
I don't see any actual question here - which explains why the answers are all over the map. –  Aaronaught Jul 5 '11 at 2:00

5 Answers 5

If you are trying to do very high precision arithmetic (not quite the correct terminology, since this is integer rather than floating point), 99.9% of the CPU time will be spent in the library functions for said arithmetic, and it won't matter if the user layer is an intrepreter or a fast compiled language. What matters is finding a good "big integer" library, with a decent interface to a language you like.

share|improve this answer

C and C++ don't natively support very large numbers; you'd have to use a third-party bignum library (can't speak to C#).

Frankly, C and C++ aren't the best tools for number-crunching work.

share|improve this answer

You'd better use a language with a decent support for large numbers - e.g., Scheme, or a specialised language like Mathematica or Maxima. With C++ your choice is pretty much limited to libgmp.

share|improve this answer
Not even close to true -- there are about as many large integer math libraries for C++ as there are languages that support large integers as part of the language (e.g., NTL, MIRACL, LIP, ...) –  Jerry Coffin Jan 28 '11 at 14:32
@Jerry Coffin, most of that libraries are (IMHO, IMHO) inferior to GMP, so there is only one choice left, and it is not nearly close to ideal as well. –  SK-logic Jan 28 '11 at 14:35
disliking something is no excuse for denying its existence. –  Jerry Coffin Jan 28 '11 at 14:39

Bearing in mind "large numbers" (hence presumably bigger than 2^32), which means that it's "C or C++ or C# and a decent library". Some languages ship with support for large numbers (Smalltalk, Haskell, Common Lisp) and some don't.

share|improve this answer

Every task is different.

I'd say, pick a flawed micro-benchmark which comes closest to your requirements, e.g. http://shootout.alioth.debian.org/, and draw your conclusions.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.