Click here to Skip to main content
12,553,687 members (60,001 online)
Click here to Skip to main content
Add your own
alternative version


206 bookmarked

Using generics for calculations

, 11 Oct 2004
Rate this:
Please Sign up or sign in to vote.
Performing calculations with generic types is not as easy it seems. This article shows how to do it.


The current implementation of .NET generics is used mainly to make type-safe collections faster and more easy to use. Doing calculations on generic types is not as straightforward.

The problem

An example for doing calculations on generic types would be a generic method to calculate the sum of all elements in a List<T>. Of course, summing up all elements of a list only makes sense if T is a type such as int, double, decimal that defines an addition operation.

Somebody coming from a C++ background might implement such a method like this:

public class Lists {
    public static T Sum(List<T> list) 
        T sum=0;
        for(int i=0;i<list.Count;i++)
        return sum;

This is not possible in C# because unconstrained type parameters are assumed to be of type System.Object, which does not define a + operation.

To constrain type parameters in C#/.NET, you specify interfaces that the type has to implement. The problem is that interfaces may not contain any static methods, and operator methods are static methods.

So with the current constraint system, it is not possible to define operator constraints.

A clean way to enable numerical computations would be to let the basic data types like int, float, double, decimal etc. implement an interface for arithmetic operations. Then this interface could be used to constrain the type parameters. This would work similar to the IComparable<T> interface that all basic data types implement.

I tried to convince the people at Microsoft to implement such an interface, but apparently they won't be able to do it in time for Whidbey.

We are on our own

Many people have been thinking about this problem, among them Eric Gunnerson and even Anders Hejlsberg.

The solution proposed by Anders Hejlsberg was to have an abstract class Calculator<T> that has to be specialized for each primitive type. The generic type would then use an instance of the appropriate calculator to do the calculations.

Here is the code (copied from Eric Gunnerson's Blog):

First define the abstract base class:

public abstract class Calculator<T>
    public abstract T Add(T a, T b);

Then specialize for the types you want to perform calculations on:

namespace Int32
    public class Calculator: Calculator<int>
        public override int Add(int a, int b)
            return a + b;

Then use an appropriate Calculator<T> to do the calculations. Here is an example that calculates the sum of all elements in a List<T>.

class AlgorithmLibrary<T> where T: new() 
    Calculator<T> calculator;

    public AlgorithmLibrary(Calculator<T> calculator)
         this.calculator = calculator;

    public T Sum(List<T> items)
        T sum = new T(); 

        for (int i = 0; i < items.Count; i++)
            sum = calculator.Add(sum, items[i]);

        return sum;

You would use it like this:

AlgorithmLibrary library = new AlgorithmLibrary<int>(new Int32.Calculator());

There are many other creative solutions, but all of them have the drawback that they involve some kind of dynamic method invocation (virtual methods, interfaces or delegates). So while they make it possible to perform calculations with generic type parameters, the performance is unacceptably low for numerical applications.

The Solution

The first person to come up with a solution that does not involve any virtual method invocation was Jeroen Frijters. The solution uses the fact that constraining type parameters using interfaces is not the same as casting to interfaces. Calling a method using an interface has the overhead of dynamic method dispatch, but calling a method on a type parameter that is constrained by an interface has no such overhead.

Here is an example. It is a generic method that sorts two numbers. The type T has to implement IComparable<T> so that we can be sure that it has the CompareTo method. But nevertheless, calling the CompareTo method does not have the overhead normally associated with interfaces.

public class Sorter
    private static void Swap<T>(ref T a, ref T b)
        T t=a;a=b;b=t;
    public static void Sort<T>(ref T a,ref T b)
        where T:IComparable<T>
            Swap(ref a,ref b);

The approach suggested by Jeroen Frijters uses a second type parameter. To avoid unnecessary object creation and virtual method dispatch, it is best to use a value type for the type containing the operations. Here is a small example for this approach:

interface ICalculator<T> 

    T Sum(T a,T b); 


struct IntCalculator : ICalculator<int> 

    public int Add(int a,int b) { return a+b; } 


// struct FloatAdder ... 

// struct DoubleAdder ... 

class Lists<T,C>
    where T:new() 
    where C:ICalculator<T>,new();{
    //since C is a struct with zero size, we can create an instance
    //of C whenever we need one without any overhead.
    private static C calculator=new C();
    public static T Sum(List<T> list) 
        T sum=new T();
        for(int i=0;i<list.Count;i++)
        return sum; 


The use of this class is a bit awkward because of the second type parameter. But you could use an alias. Here is how you would use the Lists<T,C> type:

using IntLists=Lists<int,IntCalculator>;
List<int> list=new List<int>();
Console.WriteLine("The sum of all elements is {0}",


Since we made sure that our code does not contain any virtual method calls or unnecessary object creation, the generic code should be exactly as fast as non-generic code. To test this, I wrote a small benchmark. The result is encouraging. Even the current very limited JIT compiler manages to inline the Sum method, so the generic version is indeed exactly as fast as the non-generic version on my machine.

Please make sure that you run the benchmark in release mode, since in debug mode many very important optimizations such as method inlining are disabled.

Using operators with type parameters

We now can do calculations on generic types with acceptable performance. But we still can not use operators with type parameters. In the above example, we had to write sum=calculator.Add(sum,list[i]) instead of simply writing sum+=list[i].

This might not be a big deal if you want to perform a simple addition. But if you have large, complex methods that excessively use operators, it would be a tedious and error-prone process to convert them to use method calls instead.

Fortunately, it is possible to create a wrapper struct that defines operators. By using implicit conversions to and from the wrapped type, we can use this wrapper struct almost transparently.

This is how a wrapper struct for the above ICalculator interface might look like:

public struct Number<T,C>
    where C:ICalculator<T>,new()
    private T value;
    private static C calculator=new C();
    private Number(T value) {
    public static implicit operator Number<T,C>(T a)
        return new Number<T,C>(a);
    public static implicit operator T(Number<T,C> a)
        return a.value;
    public static Number<T,C> operator + (Number<T,C> a, Number<T,C> b)
        return calculator.Add(a.value,b.value);
    ...other operators...

Now, instead of using T in your generic class, you would just use the wrapper struct instead. Here is how the Sum example would look like using the wrapper struct:

class Lists<T,C>
    where T:new()
    where C:ICalculator<T>,new()
    public static T Sum(List<T> list)
        Number<T,C> sum=new T();
        for(int i=0;i<list.Count;i++)
        return sum;

You might expect that this code runs exactly as fast as the non-operator version. But unfortunately, this is not the case. The current .NET JIT compiler has some very serious limitations. Basically, it does not do any inlining if a method has an explicit struct parameter (Yes, I was shocked too).

Since the operator methods in the wrapper struct have struct parameters, they will not be inlined, so the performance will suffer. But I am sure that Microsoft will fix this important performance issue soon.

Here is a suggestion about this topic that you can vote for. This is the only thing that is missing for lightning-fast and easy to use numerics in C#.


Even though the constraint syntax of .NET generics system is very limited, it is possible to work around those limits by using a second type parameter. This approach is a bit more work for the writer of the generic class library, but it is quite transparent for the user of the class library and it yields performance that is identical to a non-generic version. Just like with C++ templates, the runtime cost of the abstraction is zero.

There are some limitations, but these should go away very soon as Microsoft and the competing vendors improve the JIT compiler performance. So, it is possible to write numeric libraries that are as fast or even faster than compile-time template libraries such as the C++ STL.

About the code

The included project consists of interfaces, implementations and wrappers for all primitive types with a few nice additions. The list benchmark calculates the standard deviation of a large list both with generic and with non-generic methods. Another benchmark compares the performance of the non-generic System.Drawing.Point and System.Drawing.PointF structs with a generic Point<T> version.

The code is under the BSD license, so feel free to use it for your own projects.


  • Anders Hejlsberg proposed using an abstract base class.
  • A solution using dynamic method generation.
  • Jeroen Frijters proposed using value types for the calculator.
  • This was my first posting about the topic. As you might notice, I was quite angry...
  • Here is where I will publish newer versions of the code.
  • Two articles by me on osnews about the topic.
  • Please vote for this suggestion. It is more important than the presidential elections :-)


This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here


About the Author

Rüdiger Klaehn
Web Developer
Germany Germany
Rüdiger Klaehn works as freelance developer in the space industry. He is very interested in functional programming languages and hopes that .NET will lead to a more widespread adoption in the industry.

You may also be interested in...


Comments and Discussions

GeneralMy solution [modified] Pin
DuncanWoods6-Jul-06 0:08
memberDuncanWoods6-Jul-06 0:08 
GeneralUpdate Pin
fdssfsdfsdfsdfsd20-Feb-06 19:03
memberfdssfsdfsdfsdfsd20-Feb-06 19:03 
GeneralMin and Max Pin
SimmoTech23-Oct-05 5:17
memberSimmoTech23-Oct-05 5:17 
GeneralI would solve the problem like this: Pin
Daniel Steiner12-Aug-05 9:53
memberDaniel Steiner12-Aug-05 9:53 
GeneralRe: I would solve the problem like this: Pin
Rüdiger Klaehn14-Aug-05 2:03
memberRüdiger Klaehn14-Aug-05 2:03 
GeneralRe: I would solve the problem like this: Pin
Keith Farmer23-Aug-05 9:31
memberKeith Farmer23-Aug-05 9:31 
GeneralRe: I would solve the problem like this: Pin
Rüdiger Klaehn22-Sep-05 23:11
memberRüdiger Klaehn22-Sep-05 23:11 
GeneralRe: I would solve the problem like this: Pin
Keith Farmer19-Oct-05 13:00
memberKeith Farmer19-Oct-05 13:00 
Questionwhy?? Pin
fedo50011-May-05 21:09
memberfedo50011-May-05 21:09 
Generalerror Pin
fedo5002-May-05 17:48
memberfedo5002-May-05 17:48 
GeneralRe: error Pin
Nishant Sivakumar11-May-05 21:32
staffNishant Sivakumar11-May-05 21:32 
GeneralGood but a bit offtopic Pin
Max Shaposhnikov11-Mar-05 23:02
sussMax Shaposhnikov11-Mar-05 23:02 
GeneralRe: Good but a bit offtopic Pin
Rüdiger Klaehn12-Mar-05 1:56
memberRüdiger Klaehn12-Mar-05 1:56 
GeneralRe: Good but a bit offtopic Pin
gaby2r5-Apr-05 4:29
membergaby2r5-Apr-05 4:29 
the Rose | [Rose] is for the efort. however you pointed out the problem :
There is no theroetical reason why MSIL should be slower than natively compiled binaries.
you should start looking at the problem from bottom to top and you will see the difference
GeneralRe: Good but a bit offtopic Pin
Keith Farmer8-Jun-05 9:17
memberKeith Farmer8-Jun-05 9:17 
GeneralRe: Good but a bit offtopic Pin
pascal ganaye30-Oct-05 10:48
memberpascal ganaye30-Oct-05 10:48 
General.Net 2.0 Pin
BishoyAtef12-Jan-05 16:50
memberBishoyAtef12-Jan-05 16:50 
QuestionWant to try this with matrices? Pin
Serdar Astarlioglu1-Dec-04 17:00
sussSerdar Astarlioglu1-Dec-04 17:00 
AnswerRe: Want to try this with matrices? Pin
Keith Farmer20-Jun-05 13:21
memberKeith Farmer20-Jun-05 13:21 
GeneralGreat!! Pin
Luis Alonso Ramos21-Nov-04 16:59
memberLuis Alonso Ramos21-Nov-04 16:59 
GeneralExcellent Pin
Paul Watson21-Nov-04 10:00
staffPaul Watson21-Nov-04 10:00 
GeneralRe: Excellent Pin
computerguru9238225-Feb-06 16:20
membercomputerguru9238225-Feb-06 16:20 
Generalbenchmark with floats Pin
Michael Nischt11-Nov-04 3:45
memberMichael Nischt11-Nov-04 3:45 
GeneralRe: benchmark with floats Pin
Pierre Arnaud30-Nov-04 19:54
memberPierre Arnaud30-Nov-04 19:54 
GeneralThank you ! Pin
Sébastien Lorion20-Oct-04 20:56
memberSébastien Lorion20-Oct-04 20:56 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.161021.1 | Last Updated 11 Oct 2004
Article Copyright 2004 by Rüdiger Klaehn
Everything else Copyright © CodeProject, 1999-2016
Layout: fixed | fluid