Roadmap
From Omath
We're currently at version <math>10^{-17}</math> (release notes), growing exponentially. From this point on, version numbers will be tied to predefined milestones; this roadmap informally describes upcoming milestones.
Contents |
Obsolete
This page is obsolete. We're now using jira for our issue tracking, so you should use the jira roadmap instead. I've migrated everything on this page into jira.
Version 10^{-16}
Not much here yet. How about we target having string support, and rational arithmetic, for starters. Any nice sample algorithms to use as guidelines?
- Calculate the digits of <math>\pi</math> to any accuracy. Below is a formula (from MathWorld) for the n-th digit of <math>\pi</math> in base 16. I'm not sure why they call it so...after all the sums of the fractions aren't integers...In any case, this is a very fast algorithm. Each step increases your accuracy by a factor of 16.
<math>\pi=\sum_{n=0}^\infty\left(\frac{4}{8n+1}-\frac{2}{8n+4}-\frac{1}{8n+5}-\frac{1}{8n+6}\right)16^{-n}</math>.
Errr... actually this isn't much a good algorithm. It's the thing to use if you want to pick out small groups of digits from far down the base 16 expansion of pi, but not to generate large initial chunks. --Scott 14:31, 10 November 2005 (EST)
- Oh, BTW, this time I want a release PARTY! :-)
Apfloat
We're going to have to abandon the builtin Java BigInteger class, because it's lame. In particular, it uses high school multiplication algorithms, instead of what computers really should use, like the Karatsuba or Schoenhage (fft) multiplication. This is no big deal, because Mikko Tommila has written a nice, free, arbitrary precision arithmetic package for us (for C++ and Java), which does everything right. It's called Apfloat. (See also an overview of arbitrary precision package.)
I've plugged in Luschny's algorithm for factorial; while it's still a bit slower than MMA's, it is asymptotically faster :-)
Parser
- Add string support. done!
- Add nested comments. done.
- Rewrite using JJTree. done.
- Add parser level support for
f @@@ g -> Apply[f, g, List[1]]. Done.
Pattern Matching
- Optional. done!
- Repeated and RepeatedNull. done
Kernel
- Simple OutputForm implementation.
- In[] and Out[] (done!)
Core
- Fake implementations of With, Module and Block. done
- Plumbing; FixedPoint and friends, If, While, Do, For.
- How about a program to calculate the average word length in a sentence? (implementation)
- Prime factorisation. Euclid's algorithm. Actually do the Pythagorean triples from last time!
Extension framework
- Separate providers from tests.
- Allow writing omath rules directly in the provider files.
Benchmarking tool
It would be great to see, and record, how fast various algorithms are. If this data is easy to record, and make historical comparisons against, optimising will be both fun and easy :-)
There's a primitive mathematica package, hiding in http://svn.omath.org/other/testing/omathWrapper.nb which allows some comparative benchmarking. Could be automated considerably, and need some mechanism for recording data and making historical comparisons, so we can tell if we're really making progress!
Version 10^{-15}
Good enough implementation of With, Module and Block.
Kernel
Hook up JavaView, to display ListPlot's? Something else?
Core
ListPlot
Output
Have a look at what MakeBoxes is doing now; improve? Cobble together some other variants of ToString; say ToString[_, MathMLForm] and ToString[_, TeXForm], and try and integrate with something that can render that output!
Pattern Matching
Get specificity *right*, whatever that means; formally describe pattern specificity. Write a better ReplacementRuleTable implementation, with branching pattern matching?
Parser
- Simple error handling
- Reals?
- Deal with duplicate operators? (like '==' and '\[Equal]' or '<=' and \[LessEqual] etc)
Version 10^{-14}
Contexts
This requires some thought!
The indefinite future
- String support; StringCases, StringReplace, and so on. With this we could write a tokeniser, and perhaps a parser, in omath.
- This probably should be implemented on top of a regular expression engine; perhaps even with an appropriate abstraction layer.
- JavaView integration, for graphics support, subject to licensing issues.
- SlotSequence in Function.
- Contexts! Requires some thought.
I want JLink for omath! Shouldn't be too difficult, in fact. :-) Have a look at org.omath.core.java -- it's half written :-)
Start getting KnotTheory` code working
It's actually a short list of functions needed to run the Kauffman bracket code (for example). I don't think there's any work on the pattern matcher, parser, or kernel, required! Not bad!
That list is: Count, Delete, Append, Position, First, Sort, Union, and maybe a few others. Position is probably the hardest -- someone want to do this? In fact, we really should do another split -- separate kernel and core! :-)
Version 10^{-10}
Somewhere around here we should plan to have KnotTheory`, QuantumGroups`, and WikiLink` all running (perhaps with some slight changes to their code).
Version 1
Some distance off yet! Feel free to fill this section with pipe dreams for omath, and then move them down into earlier milestones if at some point they start to sound reasonable!
For the long term, we need to think about integrating code already written by other people. We'll never write a serious integration routine, and experience from other projects suggests this is a real problem! Here's idea, however. Say we want to write a symbolic integrator. Suppose we're already lucking enough to have a bunch of tests written. Now we just need to find an appropriate comp sci course somewhere out there, and give students a project to write an integrator, with their score determined by how many tests pass! :-) Could it really work?
See also
The Eclipse Webtools project has an impressively well organised roadmap!
