Any elegant way to operate with generic types? [duplicate]

Question

I am working in a small educational project where we have to implement a n-dimensional matrix. Depending on the context, this matrix has either to work with our own built-in ComplexNumber struct or with System.Double and for very simple examples, with integral types (mainly System.Int32).

Due to the nature of the application, we are not demanded to implement lightning fast performance.

My first idea was therefore to implement a Matrix<T> where T would somehow need to be restricted to "numbers".

The obvious problem in doing this is that there is no way right now in the language to constraint the generic type T with defined operators. Also I do not see an easy way to restrcit T to reasonable types.

My questions are:

1. Can somebody please point me in the direction of an elegant way to make mathematical operations with generic types that doesn't compromise performance too much and to somehow make that work with built in types (if possible).

2. If Eric ever reads this, does this feature (constraining generic types by defined operators) ever come up in hypothetical future versions of C# design meetings and has it ever been close to making it into the language?

I know its easier and better to implement a ComplexMatrix type and create wrappers around it for each matrix "sub-type" (double, integral, etc.) and pay the performance costs of the conversions between our complex type and whichever type the matrix elements happen to be. This question is more out of curiousity on how would someone implement a similar scenario.

Answer 1

If Eric ever reads this,

If you want something brought to my attention, try the contact link on my blog. Or put my full name in the text of the question so that me searching for myself will find me.

does this feature (constraining generic types by defined operators) ever come up in hypothetical future versions of C# design meetings and has it ever been close to making it into the language?

Indeed, this is a frequently requested feature. We've been getting requests for this sort of thing since C# 1.0.

The feature would requires support from the CLR team, not just the language -- it is the sort of feature that we would want to integrate into all our languages, which increases the cost.

The CLR team has expressed interest in features like this, but they also have a lot of competing features that they could be doing, and limited time and effort to implement those features.

There are numerous ways such a feature could be implemented. For example, we could add the ability to specify static methods in interfaces:

interface IAddable<T>
{
    static T operator+(T x, T y);
}

and then

static T Sum<T>(IEnumerable<T> seq) where T : IAddable<T>
{
    T sum = default(T);
    foreach(T item in seq) sum = sum + item;
    return sum;
}    

The idea would be that the interface means "a type that implements this interface must have the given static methods". We'd then make int automatically implement IAddable<int>, and so on.

How do do so efficiently in a world with runtime-generated generic code is an open question.

I hasten to add that this is just a sketch of an idea. There are many ways to implement this sort of feature. The "statics in interfaces" idea is one that has broader usage than just mathematics, and that's attractive to us. If we're going to go to the huge expense of this sort of feature, it would be nice to have a really general, powerful feature rather than one narrowly focussed on math.

On the other hand, the perfect is the enemy of the good; it might be better to just concentrate on the math problem and not go for a more expensive general solution.

It's an ongoing debate. It is definitely on everyone's radar screen, but I would not expect it any time soon. The language designers are all heads-down working on going through the feedback from the async CTP.

As always, Eric's musings about hypothetical future language features of hypothetical unannounced future products are for entertainment purposes only.

Answer 2

It depends on your idea of what is elegant. If your idea of elegance to being able to write a+b where a and b are of the generic type, and that would be my idea of elegant, then this cannot be done.

Sadly, C# generics cannot achieve the elegance of C++ templates for this type of code.

Answer 3

The only way to achieve this goal somewhat semi elegant is the following: Let the caller specify a delegate for the needed operators and use these delegates.

e.g.:

class Matrix<T>
{
    Func<T, T, T> _add;
    Func<T, T, T> _subtract;
    // ...

    public Matrix(Func<T, T, T> add, Func<T, T, T> subtract, ...)
    {
        _add = add;
        _subtract = subtract;
        // ...
    }
}

var m = new Matrix<int>((a,b) => a+b, (a,b) => a-b, ...);

// Assuming that ComplexNumber has two static methods Add and Subtract
var m = new Matrix<ComplexNumber>(ComplexNumber.Add, ComplexNumber.Subtract, ..);

However, I have no idea about the performance of this approach...

Answer 4

One workaround with decent performance (that's still ugly) is using a struct that encapsulates the arithmetic behavior you want.

You first define an interface:

public interface IArithmetic<T>
{
    T Add(T n1,T n2);
}

Then you implement that interface using a struct:

public struct DoubleArithmetic:IArithmetic<double>
{
    public double Add(double n1,double n2)
    {
        return n1+n2;
    }
}

And finally you pass the struct as generic parameter into your type:

public class Matrix<T,TArithmetic>
  where TArithmetic:struct, IArithmetic<T>
{
  private static readonly TArithmetic arithmetic=new TArithmetic();

  void DoStuff()
  {
    arithmetic.Add(1,2);
  }
}

I haven't benchmarked it, but I suspect it's rather fast since generics get specialized for each value type passed into it. That's why DoubleArithmetic is a struct.