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.