I was just wondering if anyone knows of an implementation of a multidimensional root finder in .NET that is free and preferably open source. I have found implementations in C but haven't found anything in .NET. Have any of you guys seen anything?
Printable View
I was just wondering if anyone knows of an implementation of a multidimensional root finder in .NET that is free and preferably open source. I have found implementations in C but haven't found anything in .NET. Have any of you guys seen anything?
I'm sorry, I don't know any. You might have better luck trying to find an external library written in another language. Of course, arbitrary multidimensional root finding is horrifically complicated in general so I wouldn't recommend writing your own routine.
I'm not surprised. I've seen plenty of implementations in C but nothing in .NET. I am thinking of trying to port one but even that is a pretty big job as there are a lot of utility libraries that most of the implementations rely on. Just to make sure, do you know of anything in Java? At least that would be easier to port.
Nope, C only for me, and barely. I myself would put a lot of time into a search for (easily...) callable libraries before porting an existing solver to .NET. You might even find an API for a computational package you and your users have access to (Matlab, Mathematica, Maple, many more, methinks).
I'm curious, what's your application for such a solver in .NET? I just wonder because .NET seems to be for heavily UI-driven apps, instead of computation-driven ones (as a gross generalization).
Well the application I am working on is a web app and we're using .NET so it's easiest just to use a .NET library. It can be a pain to wrap dll's but I still may end up doing so. My primary concern about this approach is that the app we are developing might possibly be serving multiple simultaneous clients but when you wrap a DLL in .NET the methods must be marked static (this still may be possible but it makes me uncomfortable). As far as speed is concerned, you are most certainly correct about it being slower but I'm not sure exactly how much slower (we'll know if it 'feels' too slow). If we find that it's too slow we'll have to take another approach.