This post originated from an RSS feed registered with .NET Buzz by Steve Hebert. Original Post: .Math Development Directions Feed Title: Steve Hebert's Development Blog Feed URL: /error.htm?aspxerrorpath=/blogs/steve.hebert/rss.aspx Feed Description: .Steve's .Blog - Including .Net, SQL Server, .Math and everything in between Latest .NET Buzz Posts Latest .NET Buzz Posts by Steve Hebert Latest Posts From Steve Hebert's Development Blog

I’ve been asked by a few developers for a roadmap of where .Math development is headed.  I thought I’d put these thoughts to paper and attempt to explain my reasoning at this point.  My goal is to garner some input to the process and see if there are other approaches to this process based on other developer experiences and needs.  Here are the areas I see from where I sit:

-        Feature Enhancements and Code Refactoring

-        Speed Optimizations

-        New language/operational implementations (Fuzzy Logic engine)

Please remember, this list is not final and represents one developers view serving a few implementation uses.  I’m very interested in any feedback and adjusting this roadmap as necessary.

Feature Enhancements / Refactoring

Feature enhancements have currently stalled at this point.  I get the feeling the feature list for the library is fairly complete for the task at hand.  However, this is usually the time when broadsided with a cool idea.  I’m always open to new ideas and I’ll be listening to the user community for these ideas.

Refactoring of the interface is largely trivial at this point. I’d like to follow internal variable naming conventions more closely and eliminate some code duplication in a few spots.  These areas have largely been eliminated, but there would be some additional areas where code can be simplified using generics in the Visual Studio 2005 version of C#. The biggest area that I feel needs refactoring is the creation of custom functions.  I feel the token identification process and instantiation of new function instances is clumsy.  On one hand this could be handled nicely by generics or pushed higher into the object hierarchy.  The current solution focused on simplicity for the developer to create new function implementations for extending the compiler, but I believe the time may be ripe to revisit this at some point.  Given that this is an open-source project, I’d like to maintain backward-compatibility to avoid breaking anyone’s current function implementations.

All that said, I strongly hesitate on moving to generics as this breaks compatibility with the .Net 1.0 and 1.1 implementations of C#.

Speed Optimization

Speed optimization is very interesting to me as I know I can squeeze out at least another factor of 10 speed improvement on performance.  However, given the satisfaction with current evaluation performance I cannot justify the time and effort required to perform this change.  This will also directly impact the implementation of the user-defined function implementations and I hesitate to break current implementations.  I believe I have a way to use the current functions through a sort of ‘proxy’, but that needs to be fleshed out.

The biggest speed optimization would come from changing the compiler from a stack-based implementation to something of a register-based machine.  This allows for the elimination of stack memory allocations for evaluating the expression and generally only becomes noticeable when running over 100 million expression evaluations.

This is perhaps the most interesting area of the compiler – the .Math compiler does not appear to be a stack-based compiler, however the resulting IL looks a lot like the resultant code you’d find in such an implementation. Not to mention the fact that the IL is compiled once and the evaluation is performed by the runtime stack organization of the individual objects makes this interesting.

New Language Implementations

I’ve considered releasing a fuzzy logic engine that utilizes the parser and compiler structure to provide very fast evaluations of fuzzy logic sets.  While this is a fun exercise, my implementation is rather small compared to other, more complete open source sets currently available.  On the other hand, I believe the performance of my implementation will outpace most others (including the commercial tools).  I can’t really see following this trail without an economic reason to flesh out the tool to a point that will be well respected by the ‘fuzzy logic community’. 

The .Math library as it stands plays a key role in the model for providing custom fuzzy membership shaping functions.

Summary

Those are the three issues I currently see on the .Math plate.  I would argue that feature enhancements and refactoring are priority #1, speed enhancements are priority #2 and new language enhancements are priority #3.  Enhancements and refactoring are the most likely to be completed but not on a schedule at this point.  Anyone who would like to contribute to this effort is certainly welcome.  Speed enhancements are the #2 priority because language enhancements would create a central dependency on the engine at this point and reworking speed enhancements after completing language enhancements becomes a more difficult proposition (even though #3 is more fun).

Please feel free to contact me regarding this plan with questions or suggestions. I can be contacted via the project site at http://workspaces.gotdotnet.com/math or my blog site at http://codebetter.com/blogs/steve.hebert/contact.aspx.