Marker interface for generic math interfaces

[SmartK8]

I'm trying to practically use these interfaces. They're great, but it would be even better, if generic math interface had a marker interface. Example:

// marker interface only
public interface ISignedNumber {}

// standard generic math interface
public interface ISignedNumber<TSelf> : ISignedNumber, INumber<TSelf>...

Advantages:

• you can use them as a generic constraint without specifying exact generic type
• you can test for the interface presence easier
• it's easy to implement

Disadvantages:

• it's just a marker interface
• maybe someone will explain to me: why not

My logic behind it:

These interfaces are to be used in generic classes as constraints. The marker interfaces broaden the ability to use them in these scenarios. You can specify that only signed numbers (for example) will be used and specify the exact type down the line of inheritance.
Attribute would not fulfill the same function. Unless.. attributes as generic constraints.. but let's not open that can of worms.

[svick]

You can specify that only signed numbers (for example) will be used and specify the exact type down the line of inheritance.

What is the advantage of the constraint in that case?

[SmartK8]

You can either handle them by determining generic argument in code, or you can use them in an interface and then make specific constraints later in inherited interfaces/structs/records/classes. You're just marking on the ancestor interface that only these types will flow this way.

[svick]

You're just marking on the ancestor interface that only these types will flow this way.

Yes, but why? In what way is the code with the constraint better? (Maybe some example code would help explain that?)

[SmartK8]

public interface ICalculator
{
    ISignedNumber Add(ISignedNumber a, ISignedNumber b);
}

public interface ICalculator<TType> : ICalculator where Type : ISignedNumber<TType>
{
    TType Add(TType a, TType b) => a + b;

    ISignedNumber ICalculator.Add(ISignedNumber a, ISignedNumber b) => Add((TType) a, (TType) b);
}

public class Calculator : ICalculator<Int32> {}

ICalculator calculator = new Calculator();
ISignedNumber result = calculator.Add(0, 0); // you can only put constrained type here

[svick]

The problem with the non-generic ICalculator interface is that you can only use it if you know how it's implemented. E.g. calculator.Add(0.0, 0.0) would throw. This effectively defeats the primary purpose of an interface. Also, it would be quite inefficient, since it would require boxing.

As such, I don't think interfaces like the non-generic ISignedNumber should be added, to discourage types like your non-generic ICalculator.

[SmartK8]

The problem is... I know how it will be implemented. Of course it will throw, because the functionality is not there. The example is just made up on the spot, but the problem is real. The boxing is in this made up sample. I just wanted to point out the advantage. Reality is much more complex than this. It's just a focus point.

[bartonjs]

FWIW:

AVOID using marker interfaces (interfaces with no members).

Framework Design Guidelines, 3rd edition, section 4.6 (p 105 in the print edition).

So it'd need a whole lot of value to justify going against guidelines. Because of how generic constraints cascade (not well), I don't think there'll be a whole lot of value here.

[SmartK8]

Unless you have many of those ICalculator<T> implementations, and want to store those somewhere, or work with them in a bulk - in abstract. Then you'll need ICalculator, but that interface cannot just do nothing. That would defeat the purpose of doing something in bulk. It has to do all the useful operations of generic interfaces otherwise it's unusable. If you know you'll work with a specific T its OK, if you want to work with many Ts, it starts to be a problem.

[tannergooding]

That's the point of generic math, it gives you access to operators generically.

You need one generic implementation that constrains its type parameters to the new generic math interfaces. If you want a method which sums values, you define:

public static TResult Sum<T, TResult>(IEnumerable<T> values)
    where T : INumber<T>
    where TResult : INumber<TResult>
{
    TResult result = TResult.Zero;

    foreach (var value in values)
    {
        result += TResult.CreateChecked(value);
    }

    return result;
}

If you want a method which averages values:

public static TResult Average<T, TResult>(IEnumerable<T> values)
    where T : INumber<T>
    where TResult : INumber<TResult>
{
    TResult sum = Sum<T, TResult>(values);
    return TResult.CreateChecked(sum) / TResult.CreateChecked(values.Count());
}

You don't need n different implementations. You need one generic implementation and now anyone can call Sum<int, int> or Sum<int, long>, Sum<byte, BigInteger>, or Sum<float, double>. All of these are possible with a single method implementation (and if you want T in, T out; you can do that to, just don't include a TResult generic parameter and the code still works).

If you want to build StandardDeviation on top of these:

public static TResult StandardDeviation<T, TResult>(IEnumerable<T> values)
    where T : INumber<T>
    where TResult : IFloatingPointIeee754<TResult>
{
    TResult standardDeviation = TResult.Zero;

    if (values.Any())
    {
        TResult average = Average<T, TResult>(values);
        TResult sum = Sum<TResult, TResult>(values.Select((value) => {
            var deviation = TResult.CreateSaturating(value) - average;
            return deviation * deviation;
        }));
        standardDeviation = TResult.Sqrt(sum / TResult.CreateSaturating(values.Count() - 1));
    }

    return standardDeviation;
}

There are no real restrictions or limitations here. You simply just define your algorithms generically, which wasn't previously possible.

[SmartK8]

That works if the specificity of type is determined per method (and its nested method calls). But when it is determined on the whole interface, and needs to be consistent across the methods, because they use properties (which can't have local generic constraints), you'll end up with my scenario. In your case there's a multi-type-use wide interface, in mine there are vertically-leveled branches (i.e. multiple Ts) of inheritance of one-type.

[tannergooding]

You can also do this at the type level as well.

This is equally as valid and extends to any number of generic type parameters you want to specify.

public class NumberMath<T>
    where T : INumber<T>
{
    T _iCanBeAField;

    T ICanBeAProperty { get; set; }

    public static TResult Sum(IEnumerable<T> values)
    {
        TResult result = TResult.Zero;
    
        foreach (var value in values)
        {
            result += TResult.CreateChecked(value);
        }
    
        return result;
    }

    public T ICanBeAMethod(T value)
    {
        /* code */
    }

    public class ICanBeUsedWithNestedTypes
    {
        T _value;

        // etc
    }
    
    public class ICanBeUsedWithNestedGenericTypes<U>
    {
        // etc
    }
}

[SmartK8]

You're right. That was the missing part. I was skeptical, but converted some portion of my considerable structure, and it seems to magically work out so far. That set of "static abstract" methods on the generic is surprisingly pulling the weight of whole paradigm change. I'm really impressed that this seemingly small toolset can have such impact. It will take time to convert all, and I hope I won't be stopped by something later down the line, but I'm starting to believe. Thanks, I think I've gained new appreciation for this effective change.