[RexGrammer]

I'm wondering why isn't there in .NET an abstract class called 'Numbers' to represent the bond between all numbers: no matter of the type (doubles, ints, floats, etc. etc.).

That way you could make methods that accept numbers as parameters, not making overloads for every possible type.

So if anyone knows the reason, or knows a way to make methods that accept all numbers while not making overloads for every type, please post feedback. I'm really curious.

UPDATE: Or why isn't there a interface called INumber, then you could do something like this:

public void Method<T> where T : INumber()
{
}

So yeah, I'm not sure why isn't there something like this in the .NET... If anyone knows please tell...

This post has been edited by RexGrammer: 02 January 2012 - 12:41 PM

[AdamSpeight2008]

What would the interface contain?

Operators are shared methods, and since interfaces can't contain shared methods.

This post has been edited by AdamSpeight2008: 02 January 2012 - 01:09 PM

[RexGrammer]

Then forget about the interface, but what about an abstract class. It doesn't even have to contain anything, just needs to represent their bond.

[tlhIn`toq]

Probably because it wouldn't have much purpose in the real world.
Floats, decimals, integers and so on have been base types for decades.

Floats and decimals for example each allow fractions and ints do not. Yet converting from one type to another can involve loss of precision and so on. They have different pros and cons for their use.

Then where would you stop with it? Whole numbers versus rational numbers?

So how would they all be part of the same abstract class or share a 'bond'? I'm not even sure what you mean by sharing a bond in the context of coding. What is their 'bond' in your eyes, other than being numbers, which is a purely human convenience? They already share a bond in being data types.

[RexGrammer]

Here's an example:

I want to create a method that adds two numbers. If I want it to be able to add any two numbers: floats, doubles, ints, ... I need to make an overload for each of the types. Is there a way to avoid that?

Don't mind the example being totally absurd...

This post has been edited by RexGrammer: 02 January 2012 - 01:30 PM

[tlhIn`toq]

You do NOT have to make an overload for every combination of that.

Implied type conversion will handle that for you just fine.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace numbersSample
{
    public partial class Form1 : Form
    {
        public Form1()
        {
            InitializeComponent();

            int nOne = 10, nTwo = 20;
            AddGenericNumbers(nOne, nTwo);

            decimal mOne = 10m, mTwo = 20m;
            AddGenericNumbers(mOne, mTwo);

            float fOne = 10f, fTwo = 20f;
            AddGenericNumbers(fOne, fTwo);


        }


        public Decimal AddGenericNumbers(object One, object Two)
        {
            return (decimal)One + (decimal)Two;
        }
    }
}

This post has been edited by tlhIn`toq: 02 January 2012 - 01:44 PM

[RexGrammer]

But that way you're limited to returning a double? Anyway thanks. You helped much to clear up some things.

[tlhIn`toq]

As opposed to... What? If you have a more preferred return type then use it. I choose that one at random for a 10 second example that would accommodate whole and fractional values.

[RexGrammer]

It's all OK. It was just me wandering off there...

[lordofduct]

This has been a topic brought up several times for more languages than just C# or even .Net related.

We can only speculate as to why...

but we can suppose under the fact C# and .Net in general does not imply a lot with numeric values. If you screw up with a value, it will overflow on you, and throw an exception. Some languages just imply conversions and have rules about it, but C# does not, expecting you to handle odd conversions (convert a large int to a small byte, or a negative value to a unsigned value, or a fractional value to a integer type, etc etc etc). For my projects I create two utility classes a 'ConvertUtil' and a 'MathUtil' to create all my conversion rules, and my math functions (with appropriate overloads... yes its time consuming, but its worth it).

As been shown, if you just decide upon a common numeric conversion type (double or decimal for instance), you avoid most overloads. Other math functions I have are implicitly fractional anyhow and I only have a double and decimal implementation of it (why would sqrt or reciprocal have more? odds are they're fractional).

But if we drag in implicit numeric types issues arise.

How about this:

public static INumeric Summation(params INumeric[] values)
{
	? result = 0; //what type is this supposed to be? I can't create any abstract numeric type... it doesn't make sense
	foreach (INumeric value in values)
	{
		result += value;
	}
	return result;
}

So first we have a majour problem... what is the type of 'result'? We can't create a value in memory to store result with out knowing what the type is going to be. A Decimal (128-bit) takes up far more space than in int32 (32-bit). This also gets into what should the return type be of the number? The say that was pushed in? We could have pushed in 8 different numeric typs, that param array could contain any mixture of all the different numeric types. And what with those varying types? How do we handle numeric overflow and conversion? Should we conserve the fractional bit even if the majority of values passed in are integers? Should we allow an upper maximum of Double or Int32 or Decimal or Byte or what?

This is a lot of decissions you as the creater of this function have to decide. And in deciding it you probably will run into 2 types of choices:

1) pick a small handful of common return types (int, double, decimal only like previously suggested)
2) decide you want to restrict the input to specific types (ruling out any need for a generic/abstract numeric type, and requiring a handful of overloads to meet your specific needs)



In the end it's a lot of puff to really end up with a limited use interface/type. There has been talk of a INumeric, but never actually done as the most of the time, overloads are just easier.

This post has been edited by lordofduct: 03 January 2012 - 08:16 AM

[Curtis Rutland]

Honestly, I think C# Interfaces should be updated to allow for including Operators. It would make some sense, since operators are at their heart a method. We allow interfaces to include property definitions.

Allowing for that, we could conceivably have some INumeric type. The best argument for something like this would be for generic methods/classes/delegates. It'd be nice to be able to make a method that can expect an operator for a generic type.

[lordofduct]

It would be nice, I do agree.

But for reasons separate from what OP is talking about.

[RexGrammer]

Everything's clear now, thanks!

[cilaes]

I enjoyed this discussion, it's interesting coming from PHP (pre-OO) and learning C# and realizing how much types and memory allocation matter, whereas I never really had to pay too much attention to that before.

[CodeGrappler]

Personally I would like to be able to restrict generics to "INumeric" like you can with say IComparable or other interfaces.

public static T DoSomethingWithNumbers<T>(T someNum, T someOtherNum) where T: INumeric
{
    return someNum + someOtherNum;
}