Ok. All participants interested in the Solver Component, heads up! I'll give you some useful information to get you started on this task (the core developers, please correct any inaccuracies in my post anytime).
First, if you're not already subscribed, consider joining our mailing list by sending an empty email to [EMAIL PROTECTED] Unsubscribing is equally easy, that is, send an emtpy email to [EMAIL PROTECTED] You can still post to the list without subscribing to the list. But most of us only reply to the list only, so your subscription is highly recommended. Next, let me give you some general information regarding how to develop an official add-on component for OpenOffice.org. For your code to be accepted into our codebase, you must sign a Joint Copyright Assignment (JCA) with Sun, our primary sponsor and the original owner and current co-owner of the OpenOffice.org (OO.o) source code. For more details of how to contribute and/or sign a JCA, please see http://contributing.openoffice.org/programming.html An add-on component is typically developed by using the OO.o API called UNO, which is the OO.o's networkable component framework designed to be independent of any particular programming languages. Currently it has bindings for C++, Java, Python, and Basic (Mono is in the works). To learn more about UNO, visit http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html or download the PDF version available on that page. You may also be interested in Ian Laurenson's API page at http://ext.openoffice.org.nz which focuses on the Basic binding of UNO. While a component may not necessarily be written in Basic, using Basic to familialize yourself with UNO may be a good strategy, especially for the first-timers who are already familiar with some form of Basic-like language, such as VB. Also, Rovert Vojta's blog may be useful to get started on UNO component technology in Java and Python. http://blog.vojta.name/archives/2005-06-02T13_36_48.html (for Java) http://blog.vojta.name/archives/2005-06-02T11_51_04.html (for Python) The SDK, which is what you need to develop a UNO component and also contains many examples in Java and C++, can be downloaded from http://download.openoffice.org/680/sdk.html And finally, if you ever want to work on the core codebase (you brave soul!), be sure to check out Michael Meeks' excellent hacker's guide: http://go-ooo.org/hackers-guide.html for a good introduction of how to hack the core OO.o. But I won't recommend it for this competition. ;-) Now that the boilerplate is over, here is some additional info specific to the Solver Component. This Solver Component, first and foremost, is to be developed as a C++ UNO component. You may use the boost library or the STL library as you see fit, but no other non-standard libraries shall be used. The user interface portion is to be written by using the UNO AWT framework, which provides access to OO.o's native Visual Class Library (VCL) that encapsulates platform-specific rendering calls into common abstract calls. If you want to code multiple optimization algorithms, they should be written such that they can be used interchangeably by using a design pattern that allows easy swapping of algorithms as well as easy addition of more algorithms at later time. Now, that's the big picture. The good news is that I have done much of the initial heavy-lifting work of this Solver Component (I'm the current owner of this task), and you are free to study my (rather ugly) code to learn how the code is organized. But remember, the code is still work in progress, so no comments on its ugliness please. ;-) You can download it from: http://www.openoffice.org/nonav/issues/showattachment.cgi/26871/solver_r46.tar.bz2 (This is heavily geared toward Unix/Linux environment, because that's the environment that I work in. If you develop in Windows you'll probably have to do some additional work to get it to work. Do it at your own risk.) Here is a run-down of what I have completed so far: * Basic UNO component framework to communicate with the core application * User interface for data input (this constitutes the majority of the current code) * Prototype and implementation of Revised Simplex and Bounded Revised Simplex for constrained LP * Prototyping of Quasi-Newton algorithm for unconstrained NLP (not integrated, but the code is being developed) * Algorithm for solving for a specific target value (Yoann Le Bars' contribution) Note that the current solver implementation does not actually solve a model, as the underlying algorithms are not yet connected with the UI component, but the effort is underway. While the description of this task on our Summer Code page may suggest that you must complete the whole component from start to finish, you should probably start from my code to avoid duplicating/wasting effort!, and propose and code for this competition that: * adds additional functionality, either in the UI or the algorithm part, or both (but some notes on the UI code later) * alters design in some areas that may prove to be more efficient/simpler/better/etc. But you must back up your claim with good argument/evidence of why your design is better than mine! ;-) I personally don't recommend this route, but the choice is up to you. Here are my personal ideas of what could be added to the component (Your contributions): Algorithms (in order of urgent needs): * Penalty or Barrier method for constrained non-linear model. * Branch-and-Bound and/or Branch-and-Cut method for solving a mixed integer linear/non-linear model. * Interior point method for solving a constrained linear model. * Genetic algorithm for [fill in the blank] so that we can brag about it to other open-source projects :-) * Any other algorithms worth adding? Keep in mind that, if you decide to start from my code, then each _linear_ algorithm must be publicly inherited from the "BaseAlgorithm" class located in numeric/lpbase.hxx. Please also provide a test program that can call your algorithm separate from the UI and solve multiple models with proper output text (see numeric/lpsimplex_test.cxx as an example). A framework for non-linear algorithm is not yet in place, so you can either 1) analyze the current code structure and propose a framework design that can accommodate non-linear algorithms, or 2) write non-linear algorithms in a generic way so that we can later integrate it after this competition, or 3) just stay away from writing non-linear algorithms. User Interface (some ideas): * Mechanism to deal with a non-linear model * Mechanism to deal with a linear model with a specific target value * Options dialog * Ability to use a third party algorithm library at user's choice, such as lp_solve, OPT++ etc. * Ability to save algorithm iteration output as a text file. * More cool/useful features But, for the next few months, I'll be making a significant amount of changes into the UI code, so you may want to stay away from the UI if you don't want to deal with the changes. I will post an update on my code on this [email protected] mailing list as I make progress. Of course, you are not restricted to these above items. Some of you may be more familiar with optimizations in operations research, UI design and/or software development in general than I am, so feel free to pick something different. Although not recommended, you are free to redo the entire component from scratch. However, that may prove to be just too much (and likely wasted) effort for just a 3-month development time frame, and your chances of getting your code accepted may be slim, unless you are a super-duper code generator who can produce some awesome code very fast! Also, allocate a realistic amount of time for the initial learning of the UNO API. The UNO API is very powerful but its framework design is very complex, so if you are not already familiar with UNO, learning it may require some effort. However, just writing an algorithm should not require too much knowledge on UNO. The bottom-line: Assess your skill objectively and use your best judgment. Set a realistic goal given the time-frame of 3 months, and don't be too greedy and try to implement too many features. Three months is not very long for coding, so pick your feature(s) wisely. Again, you must sign a JCA to get your code accepted. Ok. That's all I can think of. If there is any inaccuracy in my above statement, others please jump in and correct me. For any further questions, please ask us on this list. Best of luck to you, thanks for your participation! Kohei -- Kohei Yoshida OpenOffice.org Calc contributor http://kohei.us/ooo/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
