Function minimization and random numbers

[Jon Harrop]

I'm looking for cheap libraries that implement these two things (most likely
separately) in C#. There are a few all-encompassing numerical libraries out
there but they're too expensive. Any ideas?

 

[Peter Duniho]

I'm looking for cheap libraries that implement these two things (most
likely
separately) in C#. There are a few all-encompassing numerical libraries
out
there but they're too expensive. Any ideas?

Well, "you get what you pay for" comes to mind. I realize there are
exceptions, but I'm not sure this would be one of them.

But beyond that, maybe you could be more specific about the "random
numbers" aspect of your request. Function minimization I get, since it's
obviously not something that would be found in the .NET Framework itself.

But random numbers? Obviously you're looking for something more than just
the basic RNG implementations found in .NET (including the simple Random
class, and the randomization stuff you can find in the crypto namespace).
You'll probably get better answers if you're more specific about what
randomization features you're looking for that aren't already in .NET.

Pete

 

[Jon Harrop]

Well, "you get what you pay for" comes to mind. I realize there are
exceptions, but I'm not sure this would be one of them.

How much would you expect to pay for such a library then?

But beyond that, maybe you could be more specific about the "random
numbers" aspect of your request. Function minimization I get, since it's
obviously not something that would be found in the .NET Framework itself.

But random numbers? Obviously you're looking for something more than just
the basic RNG implementations found in .NET (including the simple Random
class, and the randomization stuff you can find in the crypto namespace).
You'll probably get better answers if you're more specific about what
randomization features you're looking for that aren't already in .NET.

Mersenne twister and random number generators for different distributions,
like Gaussian.

 

[Peter Duniho]

How much would you expect to pay for such a library then?

I'm the wrong person to ask. But, as long as you brought it up, what do
you consider "cheap"? That might help guide someone else who might know
of such a library but not whether it's in a cost range you're willing pay.

Heck, if your idea of "cheap" is generous enough, you might even find
someone here who'd implement it for you.

Mersenne twister and random number generators for different
distributions,
like Gaussian.

Granted, it's been awhile. But it's my recollection that you can generate
Gaussian and other non-linear distributions by appropriate iteration of
linear distributions. For example, summing multiple linearly distributed
random numbers gets you a Gaussian distribution (the more sums, the closer
to a true Gaussian curve you get).

As for Mersenne, Wikipedia has a pseudo-code implementation of Mersenne
twister. It's quite short, and I would think that if you actually want it
in C#, it wouldn't take even 30-60 minutes to translate it:
http://en.wikipedia.org/wiki/Mersenne_twister#Pseudocode

Pete

 

[Jon Skeet [C# MVP]]

As for Mersenne, Wikipedia has a pseudo-code implementation of Mersenne
twister. It's quite short, and I would think that if you actually want it
in C#, it wouldn't take even 30-60 minutes to translate it:
http://en.wikipedia.org/wiki/Mersenne_twister#Pseudocode

Which means that presumably it would hardly take any time at all to
implement in F#

(Must finish Robert's book some time...)

 

[rossum]

Mersenne twister and random number generators for different distributions,
like Gaussian.

For various random distributions, see Knuth Vol 2, section 3.4.1.

There is a free C# Mersenne Twister at
http://www.codeproject.com/KB/cs/csharpmersennetwister.aspx

I have no idea how good the code is.

rossum

 

[Jon Harrop]

I'm the wrong person to ask. But, as long as you brought it up, what do
you consider "cheap"? That might help guide someone else who might know
of such a library but not whether it's in a cost range you're willing pay.

Say £99 for a DLL or £199 for the source code?

Heck, if your idea of "cheap" is generous enough, you might even find
someone here who'd implement it for you.


Granted, it's been awhile. But it's my recollection that you can generate
Gaussian and other non-linear distributions by appropriate iteration of
linear distributions. For example, summing multiple linearly distributed
random numbers gets you a Gaussian distribution (the more sums, the closer
to a true Gaussian curve you get).

Yes. There are lots of algorithms with different performance trade-offs so
it would be nice to have a selection.

Other problems include distributing random vectors in a sphere or on the
surface of a sphere (or equivalently circles) and many other distributions
(of course!).

As for Mersenne, Wikipedia has a pseudo-code implementation of Mersenne
twister. It's quite short, and I would think that if you actually want it
in C#, it wouldn't take even 30-60 minutes to translate it:
http://en.wikipedia.org/wiki/Mersenne_twister#Pseudocode

Great, thanks.

 

[Jon Harrop]

(Must finish Robert's book some time...)

How are you finding it?

 

[Jon Skeet [C# MVP]]

How are you finding it?

The book is excellent, as far as I've gone, and I'm certainly
interested in the language. Regrettably the time taken by my own book
(and other projects) has meant that I haven't had time to give it a
proper go yet.

I'm really hoping we get the immutable collections F# uses as an
extension to the standard framework. While I'm not convinced by the
idea of "everything is easier in F#" I'm certainly convinced by "it's
great to have the functional style available where it's suitable". C#
3 makes that a lot easier to cope with than before, and it looks like
F# will be contributing extra library support. Win/win situation, to
be honest.

I expect to learn techniques from F# rather than actually starting to
use it as a production language, but that doesn't mean it won't have
value for me. Just don't expect it to supplant C# any time soon.

Jon

 

[Jon Harrop]

I'm really hoping we get the immutable collections F# uses as an
extension to the standard framework. While I'm not convinced by the
idea of "everything is easier in F#" I'm certainly convinced by "it's
great to have the functional style available where it's suitable". C#
3 makes that a lot easier to cope with than before, and it looks like
F# will be contributing extra library support. Win/win situation, to
be honest.

For the time being, all of the extra libraries and features offered by F#
will remain F# only. I agree it would be nice if some of this stuff (I'm
thinking more of complex numbers, vectors and matrices) would be available
as standard in .NET but such things take a long time to change.

I expect to learn techniques from F# rather than actually starting to
use it as a production language, but that doesn't mean it won't have
value for me. Just don't expect it to supplant C# any time soon.

Microsoft will want to leverage F# as a way of pulling new users onto .NET
and Windows rather than shifting existing users over from C# to F#.
Consequently, 50% of our F# sales are to C# users and the rest are
to "outsiders".

 

[Marc Gravell]

Jon Harrop> I'm thinking more of complex numbers, vectors and matrices

Fundamentally, these aren't tricky data-structures (although it is
frustrating that they aren't provided out-of-the-box); can I ask: what
is it that F# does so well with these, that couldn't be done in C#
with a custom class/struct?

I ask this in the context of some work I have been doing on generic
operators for C# - i.e. a now have a fully working Complex<T>
implementation.

Marc

 

[Jon Harrop]

Jon Harrop> I'm thinking more of complex numbers, vectors and matrices

Fundamentally, these aren't tricky data-structures (although it is
frustrating that they aren't provided out-of-the-box); can I ask: what
is it that F# does so well with these, that couldn't be done in C#
with a custom class/struct?

Microsoft implemented all of them and put them all in the standard library
of F#. So every F# program and library uses the same compatible types and
they all interoperate beautifully as a consequence.

Microsoft didn't do that with C# so every library (e.g. Numeric Edge,
CenterSpace, NMath, us, Windale) uses its own incompatible implementation
of those same core types and the libraries can't interoperate as a
consequence.

As you say, minor oversights like this don't require genius to implement but
the fact that Microsoft overlooked these features has driven lots of
technical users away from .NET. One of the purposes of F# is to make .NET
alluring to those technical users and pull them back onto this platform.

 

[Marc Gravell]

Cheers for that; of course, it is double edged if "standard" .NET
consumers can't use the F# libs... but there we are ;-p

Marc

 

[Arne Vajhøj]

I ask this in the context of some work I have been doing on generic
operators for C# - i.e. a now have a fully working Complex<T>
implementation.

Out of curiosity what is a Complex<T> good for (the T part) ?

Arne

 

[Marc Gravell]

Out of curiosity what is a Complex<T> good for (the T part) ?
If you mean "what possible use?" - just me messing around with code,
but so that in the same way you can have "decimal", "float", "int"
etc, you can have a Complex<decimal>, Complex<float>, Complex<int>
with a shared implementation; so your choice of data format isn't
constrained by the implementation, and so that your code can further
use common code to process such [i.e. Foo<T>(Complex<T> bar)]

If you mean "which Ts is it good for?" - any you can think of (or
create) with suitable operators [or IL equivalents].

In reality, it was just a handy test vehicle for testing generic
operators generally; it possibly makes more sense in some other
scenarios (vectors would be another interesting case)...

Marc

 

[Jon Harrop]

Cheers for that; of course, it is double edged if "standard" .NET
consumers can't use the F# libs... but there we are ;-p

You can write libraries in F# that other languages can use but, of course,
you must avoid features (e.g. closures) that C# and VB lack.

Hopefully Microsoft will hoist the generally-useful functionality currently
in F#'s stdlib out and put it into core .NET instead. This would give the
best of both worlds.

 

[Jon Skeet [C# MVP]]

You can write libraries in F# that other languages can use but, of course,
you must avoid features (e.g. closures) that C# and VB lack.

In what way does C# lack closures? It supports them in the form of
delegates with captured variables etc. It may not be the same form that
F# uses, but that's not the same thing.

Hopefully Microsoft will hoist the generally-useful functionality currently
in F#'s stdlib out and put it into core .NET instead. This would give the
best of both worlds.

Indeed.

 

[Jon Harrop]

In what way does C# lack closures? It supports them in the form of
delegates with captured variables etc. It may not be the same form that
F# uses, but that's not the same thing.

Closures represent all functions but .NET delegates do not because .NET
draws an unnecessary distinction between members and delegates, making them
incompatible. C# inherits this but F# goes to great lengths to remove this
artificial distinction.

You could turn everything into a delegate but, of course, this would not be
an alluring interface for C# users.

To provide first-class closures, .NET (or C#) might replace all members with
properties that return delegates. Then you could say "C# supports
first-class closures".

 

[Jon Skeet [C# MVP]]

Closures represent all functions but .NET delegates do not because .NET
draws an unnecessary distinction between members and delegates, making them
incompatible. C# inherits this but F# goes to great lengths to remove this
artificial distinction.

It seems to me like *you're* making the artificial distinction here.
You can build closures in C# just fine according to every definition of
closure I've seen.

That's not to say that you can use every member *as* a closure, but to
me that's not the same thing at all. Claiming that C# lacks closures is
pure FUD in my view.

You could turn everything into a delegate but, of course, this would not be
an alluring interface for C# users.

To provide first-class closures, .NET (or C#) might replace all members with
properties that return delegates. Then you could say "C# supports
first-class closures".

No, then you could say "C# supports first-class closures in the same
way that F# does". Can you find a generic computer science definition
of closures that C#'s support doesn't fulfil?

 

[Jon Harrop]

It seems to me like *you're* making the artificial distinction here.

C#'s type system makes the distinction, not me.

That is why you must convert a member into a delegate manually in C# when,
in fact, they are both just functions. There's a whole MSDN help page
devoted to this no-op.

You can build closures in C# just fine according to every definition of
closure I've seen.

That's not to say that you can use every member *as* a closure, but to
me that's not the same thing at all.

Then you are retrofitting language features onto Algol with no regard for
what makes them useful. Provided you just want a list of checkboxes of
language features, that's fine, but if you want the features to be useful
then you're going to have to think a lot more about how they interact.

Claiming that C# lacks closures is pure FUD in my view.

Avoid closures if you want to call your F# libraries from C#.

No, then you could say "C# supports first-class closures in the same
way that F# does".

That is not how F# supports closures.

Consider a language that support integers but imposes a compile time
distinction between even and odd integers for no logical reason. If that
was the only language you knew, would you back it to the hilt because,
technically, you can work around the type system to use all integers?