Crear una biblioteca matemática utilizando generics en C #

¿Hay alguna forma factible de usar generics para crear una biblioteca matemática que no dependa del tipo base elegido para almacenar datos?

En otras palabras, supongamos que quiero escribir una clase de fracciones. La fracción se puede representar con dos entradas o dos dobles o lo que sea. Lo importante es que las cuatro operaciones aritméticas básicas están bien definidas. Entonces, me gustaría poder escribir Fraction frac = new Fraction(1,2) y / o Fraction frac = new Fraction(0.1, 1.0) .

Lamentablemente, no existe una interfaz que represente las cuatro operaciones básicas (+, -, *, /). ¿Alguien ha encontrado una forma factible y factible de implementar esto?

Aquí hay una manera de abstraer a los operadores que es relativamente indolora.

  abstract class MathProvider { public abstract T Divide(T a, T b); public abstract T Multiply(T a, T b); public abstract T Add(T a, T b); public abstract T Negate(T a); public virtual T Subtract(T a, T b) { return Add(a, Negate(b)); } } class DoubleMathProvider : MathProvider { public override double Divide(double a, double b) { return a / b; } public override double Multiply(double a, double b) { return a * b; } public override double Add(double a, double b) { return a + b; } public override double Negate(double a) { return -a; } } class IntMathProvider : MathProvider { public override int Divide(int a, int b) { return a / b; } public override int Multiply(int a, int b) { return a * b; } public override int Add(int a, int b) { return a + b; } public override int Negate(int a) { return -a; } } class Fraction { static MathProvider _math; // Notice this is a type constructor. It gets run the first time a // variable of a specific type is declared for use. // Having _math static reduces overhead. static Fraction() { // This part of the code might be cleaner by once // using reflection and finding all the implementors of // MathProvider and assigning the instance by the one that // matches T. if (typeof(T) == typeof(double)) _math = new DoubleMathProvider() as MathProvider; else if (typeof(T) == typeof(int)) _math = new IntMathProvider() as MathProvider; // ... assign other options here. if (_math == null) throw new InvalidOperationException( "Type " + typeof(T).ToString() + " is not supported by Fraction."); } // Immutable impementations are better. public T Numerator { get; private set; } public T Denominator { get; private set; } public Fraction(T numerator, T denominator) { // We would want this to be reduced to simpilest terms. // For that we would need GCD, abs, and remainder operations // defined for each math provider. Numerator = numerator; Denominator = denominator; } public static Fraction operator +(Fraction a, Fraction b) { return new Fraction( _math.Add( _math.Multiply(a.Numerator, b.Denominator), _math.Multiply(b.Numerator, a.Denominator)), _math.Multiply(a.Denominator, b.Denominator)); } public static Fraction operator -(Fraction a, Fraction b) { return new Fraction( _math.Subtract( _math.Multiply(a.Numerator, b.Denominator), _math.Multiply(b.Numerator, a.Denominator)), _math.Multiply(a.Denominator, b.Denominator)); } public static Fraction operator /(Fraction a, Fraction b) { return new Fraction( _math.Multiply(a.Numerator, b.Denominator), _math.Multiply(a.Denominator, b.Numerator)); } // ... other operators would follow. } 

Si no implementa un tipo que utiliza, obtendrá un error en tiempo de ejecución en lugar de en tiempo de comstackción (eso es malo). La definición de las MathProvider siempre será la misma (también mala). Sugeriría que evite hacer esto en C # y use F # o algún otro idioma que se adapte mejor a este nivel de abstracción.

Editar: se corrigieron las definiciones de sumr y restar para Fraction . Otra cosa interesante y simple de hacer es implementar un MathProvider que opera en un árbol de syntax abstracta. Esta idea apunta inmediatamente a hacer cosas como la diferenciación automática: http://conal.net/papers/beautiful-differentiation/

Creo que esto responde tu pregunta:

http://www.codeproject.com/KB/cs/genericnumerics.aspx

Aquí hay un problema sutil que viene con los tipos generics. Supongamos que un algoritmo implica división, digamos eliminación gaussiana para resolver un sistema de ecuaciones. Si pasas enteros, obtendrás una respuesta incorrecta porque llevarás a cabo una división entera . Pero si pasa argumentos dobles que suceden tienen valores enteros, obtendrá la respuesta correcta.

Lo mismo ocurre con las raíces cuadradas, como en la factorización de Cholesky. Factorizar una matriz entera saldrá mal, mientras que factorizar una matriz de dobles que tenga valores enteros estará bien.

Primero, su clase debe limitar el parámetro genérico a primitivas (Fracción de clase pública donde T: struct, new ()).

En segundo lugar, es probable que necesite crear sobrecargas de conversión implícitas para que pueda manejar el envío de un tipo a otro sin que el comstackdor lloriquee.

En tercer lugar, también puede sobrecargar los cuatro operadores básicos para hacer que la interfaz sea más flexible al combinar fracciones de diferentes tipos.

Por último, debe considerar cómo maneja la aritmética por encima y por debajo de los flujos. Una buena biblioteca va a ser extremadamente explícita en la forma en que maneja los desbordamientos; de lo contrario, no puedes confiar en el resultado de las operaciones de diferentes tipos de fracciones.