Generics for numbers?

[Aurrin]

I'm attempting to write an application which does quite a bit of math, and since speed is a real factor, I wanted to provide the end-user with a choice on how much precision they want (as a speed trade-off). So, I came up with a vector class like this:

public partial class Vector<T> where T : float, double, decimal
{ /* stuff */ }

However, it gives me a strange set of errors:

Error	1	'float' is not a valid constraint. A type used as a constraint must be an interface, a non-sealed class or a type parameter.	D:\Coding\C# Projects\Work\MyApp\Math\VectorMath.cs	23	19	MyApp
Error	2	'double' is not a valid constraint. A type used as a constraint must be an interface, a non-sealed class or a type parameter.	D:\Coding\C# Projects\Work\MyApp\Math\VectorMath.cs	23	26	MyApp
Error	3	'decimal' is not a valid constraint. A type used as a constraint must be an interface, a non-sealed class or a type parameter.	D:\Coding\C# Projects\Work\MyApp\Math\VectorMath.cs	23	34	MyApp

I understand what it means, but I don't understand why there would be such a restriction on type constraints. Is there another way I should be doing this, short of three separate classes? I don't want to implement the entire program three times, and there are many numeric operations I'd need to do that couldn't be done on just a general object.

[jmcilhinney]

Types of Constraints
Your constraint can specify the following requirements in any combination:

The type argument must implement one or more interfaces

The type argument must be of the type of, or inherit from, at most one class

The type argument must expose a parameterless constructor accessible to the code that creates objects from it

The type argument must be a reference type, or it must be a value type

Your constraints don't meet those requirements. Perhaps it would be convenient to be able to provide a list of types that the type argument must be one of, but generics do not support that. Generics just aren't going to do what you want to do. One class with overloaded methods would do the job.

[Aurrin]

Your constraints don't meet those requirements. Perhaps it would be convenient to be able to provide a list of types that the type argument must be one of, but generics do not support that.

Yeah, I just don't see why not. It will let you specify for classes & interfaces, but not specific structs or basic data types? Gimme a break. The compiler should be able to easily enforce that kind of type safety.

Generics just aren't going to do what you want to do. One class with overloaded methods would do the job.

It would do the job if you have huge amounts of computing power, yes. But efficiency is very high on the list of priorities for this project. It's not at all uncommon for the old, unmanaged version written in C & FORTRAN and hand-optimized to run for 10 minutes or more to do the computation. If this doesn't at least get somewhere in that ballpark, no one is going to pay it any attention. I'd probably sooner just give up on variable precision and go with double precision like the old one.

Oh, and since this is basically the foundation of the math libraries for the project, it wouldn't be one class that would need to be overloaded, it would more than likely be dozens. If you did manage it with one class or set of classes, it would be something bizarre like implementing INumber or some ugly work-around like that.

Though... sometimes things that should have been in the language are there, but buried in the CIL. Is there a way to modify the IL to make such a constraint on generic type parameters?

[TheCPUWizard]

You are thinking that generics are like templates in C++ (a common mis-conception).

In C++ a seperate code base is actually "written" by the compiler for each set of template arguments.

With generics it is a SINGLE codebase with all of the dirty typecasting done behind the scenes, and optimized.

This is the reason for the restrictions, the IL has to be able to CAST AT RUNTIME whatever parameter you specialize with to the type you put in the where clause.

Regarding performance. Remember Manage, Manage, Manage. If you have a program written even 3-5 years ago and are using hardware from that generation, then probably even the worst version you could write today would still be significantly faster.

I have seen companies waste hundes of thousands of dollars because they "needed optimized code", when n fact the overall performance of the application has no noticible difference between an optimizzed version and a well written version (reliable, maintainable being the focus)

btw: The application I was refering to was a gas dispersion control system for ion-beam systems running in a hi-vacuum environment with turbos and cryogenic plates. LOTS of physics, tons of math.

[Mutant_Fruit]

In C++ a seperate code base is actually "written" by the compiler for each set of template arguments.

With generics it is a SINGLE codebase with all of the dirty typecasting done behind the scenes, and optimized.

Nope, you're thinking of Java there. Java generics are purely a compile time constraint. There exists no java bytecode for 'generic type'. In java for a List<string> type, all that happens is the compiler takes your 'generic' class, inserts the relevant casts, and uses a bog standard arraylist.

In C# we have things a little better. Generics support is built into the runtime. In C#, if the JIT hits a generic class in your code (for example List<string>), it then checks to see if it has already compiled a List<string>, if it has not, it compiles a strongly typed class with no casts which is a List<string>. If i instantiated a List<int>, the JIT would generate a brand new class which has no casting/boxing for List<int> In java there would be both casts and boxing for value types.


If speed is of the utmost concern, then using generics isn't the way to go. Calling a generic method is about 3-5 times slower than calling a regular method. I can't remember the exact figures at the moment. Also, calling virtual methods is slow too.

So, if you want the ultimate in performance, you'll have to create separate classes/structs for each of your types. If you're going to be making a lot of vectors (which i assume you will), then making it a struct would probably be the way to go.

EDIT: Also, to reiterate what TheCPUWizard said - Any project that starts out with the aim to make everything as fast as possible invariably ends up so convoluted that it's impossible to maintain. Code it in an easy to understand way first, then benchmark it to see where improvements can be made. Thats the approach i'd recommend, which has always worked for me.

[jmcilhinney]

Yeah, I just don't see why not. It will let you specify for classes & interfaces, but not specific structs or basic data types? Gimme a break. The compiler should be able to easily enforce that kind of type safety.

That might seem convenient to you but that type of functionality doesn't make sense. If you specify an interface or class constraint then you're saying that every type used will either implement that interface or inherit that class. Fixing that point guarantees that your generic type will have all the members defined by that interface or class, so you can then safely access those members within the generic type definition.

What exactly would a constraint of float, double or decimal fix? Nothing. There is no specific commonality among those types other than that they are value types, which you CAN apply a constraint for. Obviously you are interested in the fact that each of those types supports mathematical operators, but those operators are defined independently for each of those types. They are not inherited from a common source so they are not common functionality.

Just because something may appear to be convenient to your circumstances doesn't make it logical. Anyway, if efficiency is of utmost importance then purpose-written code is always going to be more efficient. As soon as you generalise something you lose a step. Generalisation is for developer convenience, not final performance.

[kasracer]

It sounds to me like you may want to look into using C++ and templates. I'm not sure if you can use templates with managed C++ code but that could also solve your issue.

[Aurrin]

If speed is of the utmost concern, then using generics isn't the way to go. Calling a generic method is about 3-5 times slower than calling a regular method. I can't remember the exact figures at the moment. Also, calling virtual methods is slow too.

This is true. I'm willing to take some performance hits for the improvements that managed code and generalization will bring to it. This project is born largely out of frustration at the built-in limits (such as hard-coded array limits) and specialization of the original program. So, what I'm trying to do is find a good balance between generalized, elegant code and efficiency of calculation.

The multiple classes really is going to make the code too complicated, and is probably unnecessary for many or most parts. I just wanted to keep the options open at this level, because this is the foundation of the rest of the program. I think what I'll do is forget float altogether and only use decimal in a few places if double overflows or is very close to zero.

So, if you want the ultimate in performance, you'll have to create separate classes/structs for each of your types. If you're going to be making a lot of vectors (which i assume you will), then making it a struct would probably be the way to go.

And thanks for the struct suggestion. I'll see if I can make that work with the code I already have.

EDIT: Also, to reiterate what TheCPUWizard said - Any project that starts out with the aim to make everything as fast as possible invariably ends up so convoluted that it's impossible to maintain. Code it in an easy to understand way first, then benchmark it to see where improvements can be made. Thats the approach i'd recommend, which has always worked for me.

Right. I don't want to hyper-optimize, I just want to go in with a good understanding of what effects the structure of the program will have on the efficiency so I don't end up with crap like avoidable boxing/unboxing bottlenecks and such.

And since you mentioned it, how much of a penalty would you take for calling a list of delegates (a more elegant solution for selecting optional calculations) instead of a long if-else train that calls functions? I'll probably do the list of delegates regardless, unless that's a very steep penalty, but I am curious.

[TheCPUWizard]

Nope, you're thinking of Java there. Java generics are purely a compile time constraint. There exists no java bytecode for 'generic type'. In java for a List<string> type, all that happens is the compiler takes your 'generic' class, inserts the relevant casts, and uses a bog standard arraylist.

In C# we have things a little better. Generics support is built into the runtime. In C#, if the JIT hits a generic class in your code (for example List<string>), it then checks to see if it has already compiled a List<string>, if it has not, it compiles a strongly typed class with no casts which is a List<string>. If i instantiated a List<int>, the JIT would generate a brand new class which has no casting/boxing for List<int> In java there would be both casts and boxing for value types.


If speed is of the utmost concern, then using generics isn't the way to go. Calling a generic method is about 3-5 times slower than calling a regular method. I can't remember the exact figures at the moment. Also, calling virtual methods is slow too.

So, if you want the ultimate in performance, you'll have to create separate classes/structs for each of your types. If you're going to be making a lot of vectors (which i assume you will), then making it a struct would probably be the way to go.

I was NOT thinking JAVA (but my explaination sure sounded like it )

I did over simplify. When I was referring to "behind the scenes" it is by the JIT compiler generating unique source (without runtime casting). The (Language) compiler does just generate one set of MSIL. This means that the implementations must be identical at the MSIL level.

You can not have different instanciations where a given operation will be a "floating point add" in one specialization, and an "integer add" in another.

One of the things I used to do all the time in C++ was write high performance (realtime multi-channel audio processing) where I would pass different class type to templates. The implementation of a given method might be virtual for one specialization, direct for another, or even completely different (and inlined) structures.

Since the (language) compiler generated specific code for each I could really achieve the same performance as doing #define based macro substution in 95% of the cases (without the intended headache).

Whith Generics, you have to qualify with an Interface or Class. If the method is virtual (which it almost always is), the compiler will generate the MSIL for a virtual call. There is simply no way do get multiple MSIL implementations that are optimized taking full advantage of the knowledge available at the time the specialization is encountered.

The JIT generation does eliminate the overhead of the casting (as you mentioned), but this comes at a price (checking if the specialization has been JITed. In many cases it can actually be faster to take the "hit" of a cast vs the "hit" of a JIT (especially if the code is called infrequently).

[Mutant_Fruit]

I was NOT thinking JAVA (but my explaination sure sounded like it

Heh, k.

In C++ a seperate code base is actually "written" by the compiler for each set of template arguments.

With generics it is a SINGLE codebase with all of the dirty typecasting done behind the scenes, and optimized.

This is the reason for the restrictions, the IL has to be able to CAST AT RUNTIME whatever parameter you specialize with to the type you put in the where clause.

It's just the above sounds like the perfect description of java generics. Java generics are a single codebase with dirty typecasting.

With C# the JIT does create new instantiations (i.e. it writes an entirely new class) for each generic type, this way there is no type casting involved.

this comes at a price (checking if the specialization has been JITed. In many cases it can actually be faster to take the "hit" of a cast vs the "hit" of a JIT (especially if the code is called infrequently).

Remember, each line of code is only JITed once, so the specialisation will only ever be JITed once - the first time it is executed. So even if the code is infrequently called (a few times per application lifespan), using generics is still the better choice.

[TheCPUWizard]

With C# the JIT does create new instantiations (i.e. it writes an entirely new class) for each generic type, this way there is no type casting involved.

And if you consider JIT to be behind the scenes.. In any case it is a matter of semantics, we both agree that the JIT creates new native code for each specialization.

Remember, each line of code is only JITed once, so the specialisation will only ever be JITed once - the first time it is executed. So even if the code is infrequently called (a few times per application lifespan), using generics is still the better choice.

Probably....but if you write a 1000 line class as a generic and there is only one typecast in an infrequesntly used portion of the code, and you have 100 specializations....

The point I am trying to make is that there can be no way to make an ABSOLUTE statement on this. As with any performance issue, it requires measurement of the specific situation.

[Kevin McFarlane]

I'm attempting to write an application which does quite a bit of math, and since speed is a real factor, I wanted to provide the end-user with a choice on how much precision they want (as a speed trade-off). So, I came up with a vector class like this:

public partial class Vector<T> where T : float, double, decimal
{ /* stuff */ }

However, it gives me a strange set of errors:

It should be:

public partial class Vector<T> where T : struct
{ /* stuff */ }

"struct" in this context denotes a value type, so it includes float, double decimal, but also int etc.

[Mutant_Fruit]

That's only marginally less useless, but still useless. 'struct' includes stuff like 'Point' and 'KeyValuePair<K, V>'. In this particular case, generics aren't useful.

[Aurrin]

It should be:

public partial class Vector<T> where T : struct
{ /* stuff */ }

"struct" in this context denotes a value type, so it includes float, double decimal, but also int etc.

I tried that. Unfortunately, that is quite useless, as it also allows string, int, bool, etc. I needed to pare it down to things that could do floating-point math, so that when I wrote

T result = t1 * t2;

The compiler could figure out that the multiplication operator would indeed work for every specified type. However, as was pointed out earlier, this is not a true commonality, and is (sadly) beyond the scope of generics.

[Aurrin]

And if you consider JIT to be behind the scenes.. In any case it is a matter of semantics, we both agree that the JIT creates new native code for each specialization.



Probably....but if you write a 1000 line class as a generic and there is only one typecast in an infrequesntly used portion of the code, and you have 100 specializations....

The point I am trying to make is that there can be no way to make an ABSOLUTE statement on this. As with any performance issue, it requires measurement of the specific situation.

Well, if it's possible, I would like to force the JIT compiler to pre-compile the entire thing immediately on installation. I believe I read that that is possible somewhere, though it's been a while back, and with an earlier version of .NET. Then JIT would only be an issue if/when you added plug-ins.