Introduction
As a developer, I'm involved in writing a lot of mathematical code everyday and I'd like to add very few syntactic sugar to the C# language to ease code writing and reviewing.
I've already read about this thread and this other one for possible solutions and would simply like to know which best direction to go and how much effort it may represent to solve only for the three following syntactical issues*.
*: I can survive without described syntactic sugars, but if it ain't too much work and Rube-Goldberg design for simple compilation process, it may be interesting to investigate further.
1. Multiple output arguments
I'd like to write:
[double x, int i] = foo(z);
Instead of:
double x;
int i;
foo(out x, out i, z);
NB: out parameters being placed first and foo being declared as usual (or using same kind of syntax).
2. Additional operators
I'd like to have a few new unary/binary operators. Don't know much how to define for these (and it seems quite complex for not introducing ambiguity when parsing sources), anyway would like to have something like:
namespace Foo
{
using binary operator "\" as "MyMath.LeftDivide";
using unary operator "'" as "MyMath.ConjugateTranspose";
public class Test
{
public void Example()
{
var y = x';
var z = x \ y;
}
}
}
Instead of:
namespace Foo
{
public class Test
{
public void Example()
{
var y = MyMath.ConjugateTranspose(x);
var z = MyMath.LeftDivide(x, y);
}
}
}
3. Automatic name insertion for static classes
It's extremely unappealing to endlessly repeating Math.BlaBlaBla() everywhere in a computation code instead of writing directly and simply BlaBlaBla.
For sure this can be solved by adding local methods to wrap Math.BlaBlaBla inside computation class. Anyway would be better when there's no ambiguity at all, or when ambiguity would be solved with some sort of implicit keyword, to automatically insert class names when required.
For instance:
using System;
using implicit MySystem; // Definying for 'MyMaths.Math.Bessel'
public class Example
{
public Foo()
{
var y = 3.0 * Cos(12.0);
var z = 3.0 * Bessel(42);
}
// Local definition of 'Bessel' function again
public static double Bessel(double x)
{
...
}
}
Would become:
using System;
using MySystem; // Definying for 'Math.Bessel'
public class Example
{
public Foo()
{
var y = 3.0 * System.Math.Cos(12.0); // No ambiguity at all
var z = 3.0 * MySystem.Math.Bessel(42); // Solved from `implicit` keyword
}
// Local definition of 'Bessel' function again
public static double Bessel(double x)
{
...
}
}
* The compiler may simply generate a warning to indicate that it solved the ambiguity because an implicit solution has been defined.
NB: 3) is satisfying enough for solving 2).
Have you considered using F# instead of C#? In my experience, I have found F# a great fit for scientific/mathematical oriented code, more so than C#.
Your first scenario is covered with tuples; you can write a function like let f a b = (a+b, a-b), which returns a tuple of 2 values directly, you can fairly easily overload operators or add your own, and modules may help you with the 3rd. And F# interoperates fairly smoothly with C#, so you can even pick F# for the parts where it's practical, and keep the rest of your code in C#. There are other niceties which work great for scientific code (units of measure for instance) as well...
I'd be one of the first people to support a mainstream C# that can be extended by users. However - for several reasons (design, time or cost-benefit) I cannot see C# being as extensible as you (or I) want. A C#-derived language I've found that is VERY good for meta-programming and extending functionality/syntax is Nemerle.
Boo is another .NET language with good meta-programming features. However, it is so far removed from C# that I didn't consider it an appropriate answer to this question (but added it for completeness, anyway).
Related
I'm studying C# and caught a piece of code that I don't understand. I was hoping that you could clearify it for me.
CreateCustomerTask.<>c__DisplayClass0 cDisplayClass0 =
new CreateCustomerTask.<>c__DisplayClass0();
What does the <> signify? And why is there a . (dot) in front of it?
You're looking at some decompiled code - specifically, something that was generated by the compiler.
The compiler uses <> (this is an implementation detail) because, whilst it's valid for a CLR identifier to start with such characters, it's not valid in C# - so it's guaranteed that the name will not conflict with any names in the C# code.
why the compiler has generated this code varies - it can be the implementation of a lambda, or an iterator or async block, and possibly some other reasons also.
And, hopefully the other part of your question is also answered - there's a . in front of it for the usual reasons - to separate namespace portions, or more likely in this case, to separate the name of a nested class from the name of the enclosing class.
As others have pointed out, what you're seeing is a name generated by the compiler that is deliberately not legal C#, so that no one can ever accidentally (or deliberately!) cause a name conflict.
The reason this name is being generated is because;
class C
{
void M()
{
int x = 1;
Func<int, int> f = y=>x+y;
}
}
Is generated by the compiler as though you'd written:
class C
{
private class DisplayClass
{
public int x;
public int AnonymousMethod(int y)
{
return this.x + y;
}
}
void M()
{
C.DisplayClass d = new C.DisplayClass();
d.x = 1;
Func<int, int> f = d.AnonymousMethod;
}
}
Except that of course all the names are deliberately mangled, as you've discovered.
The reason that a closure class is called "DisplayClass" is a bit unfortunate: this is jargon used by the debugger team to describe a class that has special behaviours when displayed in the debugger. Obviously we do not want to display "x" as a field of an impossibly-named class when you are debugging your code; rather, you want it to look like any other local variable. There is special gear in the debugger to handle doing so for this kind of display class. It probably should have been called "ClosureClass" instead, to make it easier to read disassembly.
Use this answer by Eric Lippert to decode names such as <>c__DisplayClass0. According to the table provided in the answer, you are looking at an anonymous method closure class. Do not rely on this always being true in the future, it is an implementation detail subject to change at any time.
I am trying to code C# versions (in C# style) of the F# reduce functions found here:
https://github.com/quantalea/AleaGPUTutorial/tree/master/src/fsharp/examples/generic_reduce
More specific to my question, take this function for example:
let multiReduce (opExpr:Expr<'T -> 'T -> 'T>) numWarps =
let warpStride = WARP_SIZE + WARP_SIZE / 2 + 1
let sharedSize = numwarps * warpStride
<# fun tid (x:'T) ->
// stuff
#>
I'm primarily an F# guy, and I'm not quite sure how I should go about coding functions like these in C#. For the C# version, the multiReduce function will be a class member. So if I wanted to do a more direct translation of the F# code, I would return a Func from my MultiReduce member.
The other option would be to "flatten" the multiReduce function, so that my C# member version would have two extra parameters. So...
public T MultiReduce(Func<T,T,T> op, int numWarps, int tid, T x)
{
// stuff
}
But I don't think this would work for AleaGPU coding in all cases because the quoted expression in the F# version is a device function. You need the nested function structure to be able to separate the assignment of certain variables from the actual invocation of the function.
Another way I see to do it would be to make a MultiReduce class and have the opExpr and numWarps as fields, then make the function in the quotation a class member.
So how are higher order functions like these generally implemented in AleaGPU-C#? I don't think it's good to return Func<..> everywhere since I don't see this done much in C# coding. Is AleaGPU a special case where this would be ok?
A basic AleaGPU C# implementation looks like this:
internal class TransformModule<T> : ILGPUModule
{
private readonly Func<T, T> op;
public TransformModule(GPUModuleTarget target, Func<T, T> opFunc)
: base(target)
{
op = opFunc;
}
[Kernel]
public void Kernel(int n, deviceptr<T> x, deviceptr<T> y)
{
var start = blockIdx.x * blockDim.x + threadIdx.x;
var stride = gridDim.x * blockDim.x;
for (var i = start; i < n; i += stride)
y[i] = op(x[i]);
}
public void Apply(int n, deviceptr<T> x, deviceptr<T> y)
{
const int blockSize = 256;
var numSm = this.GPUWorker.Device.Attributes.MULTIPROCESSOR_COUNT;
var gridSize = Math.Min(16 * numSm, Common.divup(n, blockSize));
var lp = new LaunchParam(gridSize, blockSize);
GPULaunch(Kernel, lp, n, x, y);
}
public T[] Apply(T[] x)
{
using (var dx = GPUWorker.Malloc(x))
using (var dy = GPUWorker.Malloc<T>(x.Length))
{
Apply(x.Length, dx.Ptr, dy.Ptr);
return dy.Gather();
}
}
}
Higher-order functions are not nearly as ubiquitous in C# as they are in F#. While there are plenty of examples of accepting functions as arguments, C# code rarely returns functions as results. I guess this is partly because the code comes out very ugly (Func<T,U> everywhere) and partly because C# programmers are not generally used to functional style and gravitate more toward OO ways.
In particular, there is no automatic currying/partial application in C#. You can think of it as if all your F# functions always had tupled parameters. In fact, that's how a multi-parameter C# method would look if you called it from F#.
I must also note that the function in your code is not, in fact, "higher-order". It neither accepts nor returns any functions. Instead, it accepts and returns quotations, which is not at all the same thing. Function is, roughly speaking, a reference to a piece of code, but quotation is a data structure. They look similar, but they're completely different animals.
C# does, too, have its own quotations, represented by the type System.Linq.Expressions.Expression<T> (where T must be a delegate type). However, they are not the same thing as F# quotations. From F# side, you can (sorta) use C# quotation, but not the other way around.
Both F# and C# quotations have their strengths and weaknesses. In particular, C# supports compilation, F# doesn't. F# supports splicing, C# doesn't.
Which brings me to the next point: you probably need splicing. Because you are using opExpr in the body of the returned quotation, aren't you?
And C# doesn't have an out-of-the-box support for it. Yes, it is theoretically possible to implement splicing as a library function, but for some reason there is no de-facto standard, regularly maintained implementation. We, for one, had to roll our own. It's open source, too, and pretty straightforward, so feel free to use it.
Now, having said all the above, I want to express a doubt that you would be able to use C# for this at all. I don't really know how AleaGPU works, but it looks like it expects you to return an F# quotation, which it then, presumably, compiles into GPU code. If that's the case, because C# and F# quotations are two different things, you probably won't be able to return a C# quotation to AleaGPU in lieu of the F# one. Unless it has separate support for it, of course.
In C++ templates have the feature that you can pass a value as the argument to the template of a function. How can I do the same in C#?
For instance, I want to do something similar to the following:
template <unsigned n> struct Factorial {
enum {
result = n * Factorial<n - 1>::result;
};
};
template <> struct Factorial<0> {
enum {
result = 1;
};
};
but in C#. How can I do this?
By the way, my actual need for them involves generating classes on demand (with a few static values changed), so the presented code is just an example.
C# generics are not like C++ templates in that way. They only work with types and not values.
but in C#. How can I do this?
By the way, my actual need for them involves generating classes on demand (with a few static values changed), so the presented code is just an example.
As Daniel explained, this is not possible via generics.
One potential alternative is to use T4 Templates. Depending on your needs, you could potentially generate your classes based off the templates at compile time, which sounds like it might meet your needs.
You are trying to make the compiler do stuff that your code should do at runtime.
Yes, this is possible in C++. In C#, It is not. The equivalent of your code in C# would be:
public class Factorial
{
public static ulong Compute(ulong n)
{
if (n == 0)
return 1;
return n * Factorial.Compute(n - 1);
}
}
Note that, while static code is already a bad violation of the OOP principle (but sometimes necessary), using value-based templates is even worse. Your types should depend on other types, which is possible using generics. They should not depend on concrete values.
I'm studying C# and caught a piece of code that I don't understand. I was hoping that you could clearify it for me.
CreateCustomerTask.<>c__DisplayClass0 cDisplayClass0 =
new CreateCustomerTask.<>c__DisplayClass0();
What does the <> signify? And why is there a . (dot) in front of it?
You're looking at some decompiled code - specifically, something that was generated by the compiler.
The compiler uses <> (this is an implementation detail) because, whilst it's valid for a CLR identifier to start with such characters, it's not valid in C# - so it's guaranteed that the name will not conflict with any names in the C# code.
why the compiler has generated this code varies - it can be the implementation of a lambda, or an iterator or async block, and possibly some other reasons also.
And, hopefully the other part of your question is also answered - there's a . in front of it for the usual reasons - to separate namespace portions, or more likely in this case, to separate the name of a nested class from the name of the enclosing class.
As others have pointed out, what you're seeing is a name generated by the compiler that is deliberately not legal C#, so that no one can ever accidentally (or deliberately!) cause a name conflict.
The reason this name is being generated is because;
class C
{
void M()
{
int x = 1;
Func<int, int> f = y=>x+y;
}
}
Is generated by the compiler as though you'd written:
class C
{
private class DisplayClass
{
public int x;
public int AnonymousMethod(int y)
{
return this.x + y;
}
}
void M()
{
C.DisplayClass d = new C.DisplayClass();
d.x = 1;
Func<int, int> f = d.AnonymousMethod;
}
}
Except that of course all the names are deliberately mangled, as you've discovered.
The reason that a closure class is called "DisplayClass" is a bit unfortunate: this is jargon used by the debugger team to describe a class that has special behaviours when displayed in the debugger. Obviously we do not want to display "x" as a field of an impossibly-named class when you are debugging your code; rather, you want it to look like any other local variable. There is special gear in the debugger to handle doing so for this kind of display class. It probably should have been called "ClosureClass" instead, to make it easier to read disassembly.
Use this answer by Eric Lippert to decode names such as <>c__DisplayClass0. According to the table provided in the answer, you are looking at an anonymous method closure class. Do not rely on this always being true in the future, it is an implementation detail subject to change at any time.
I am currently developing a C# P/invoke wrapper to a DLL that is part of my product. I have no experience with C# and this is the first significant C# coding I have done. I am acutely aware that I am lacking a lot of knowledge of the finer points and idioms of the language.
My question concerns the unit tests that I am writing for which I am using NUnit. I have a need to compare the values of double[] variables. If I use Assert.AreEqual(...) to do this then the values are compared for exact equality. However, I would like to compare up to a tolerance. There are AreEqual() overloads for scalar real values that admit a delta parameter. However, I have not been able to find an equivalent for arrays. Have I missed something obvious?
At the moment I have solved the problem with the following code:
class Assert : NUnit.Framework.Assert
{
public static void AreEqual(double[] expected, double[] actual, double delta)
{
AreEqual(expected.Length, actual.Length);
for (int i = 0; i < expected.Length; i++)
{
AreEqual(expected[i], actual[i], delta);
}
}
}
Whilst this appears to work I wonder if there is a cleaner solution available. In particular I am concerned that using the same name for my derived class is, not only poor style, but could lead to un-anticipated problems down the road.
I would have like to use extension methods but I understand they are only viable for when there is an instance of the class under extension. Of course, I only ever call static methods on the Assert class.
I'm sorry if this seems a bit nebulous, but my instincts tell me that I'm not doing this the best way and I would like to know how to do it right.
Since the introduction of the fluent assertion syntax in NUnit, the Within() method has been available for this purpose:
double actualValue = 1.989;
double expectedValue = 1.9890;
Assert.That(actualValue, Is.EqualTo(expectedValue).Within(0.00001));
Assert.That(actualValue, Is.EqualTo(expectedValue).Within(1).Ulps);
Assert.That(actualValue, Is.EqualTo(expectedValue).Within(0.1).Percent);
For collections, the default behaviour of Is.EqualTo() is to compare the collections' members individually, with these individual comparisons being modified by Within(). Hence, you can compare two arrays of doubles like so:
var actualDoubles = new double[] {1.0 / 3.0, 0.7, 9.981};
var expectedDoubles = new double[] { 1.1 / 3.3, 0.7, 9.9810};
Assert.That(actualDoubles, Is.EqualTo(expectedDoubles).Within(0.00001));
Assert.That(actualDoubles, Is.EqualTo(expectedDoubles).Within(1).Ulps);
Assert.That(actualDoubles, Is.EqualTo(expectedDoubles).Within(0.1).Percent);
This will compare each element of actualDoubles to the corresponding element in expectedDoubles using the specified tolerance, and will fail if any are not sufficiently close.
I had a need to create custom assert, in your case there was an alternative provided by the framework. However this didn't work when I wanted to have a completely custom assert. I solved this by adding a new static class calling into nunit.
public static class FooAssert
{
public static void CountEquals(int expected, FooConsumer consumer)
{
int actualCount = 0;
while (consumer.ConsumeItem() != null)
actualCount++;
NUnit.Framework.Assert.AreEqual(expected, actualCount);
}
}
Then in a test
[Test]
public void BarTest()
{
// Arrange
...
// Act
...
// Assert
FooAssert.CountEquals(1, fooConsumer);
}
I know I am a little bit late for the party, it might still be useful for somebody
"Better" is always a matter of taste. In this case, i would say yes. You should make your own assert, without subclassing the nunit assert. Nunit already has multiple Assert classes with different specific assertions. Like CollectionAssert. Otherwise your method is fine.
I think what I would have done is simply define a function somewhere in your test harness
public static bool AreEqual( double[], double[], double delta )
that does the comparison and returns true or false appropriately. In your Test you simply write :
Assert.IsTrue( AreEqual( expected, result, delta ) ) ;