Systems of Ordinary Differential Equations

by Dennis Darland dennis.darland@yahoo.com

dennisdarland.com

Comments welcome

  1. Omnisode - What it is

    1. It is mainly a Ruby program which generates a program to solve a set of one or more ordinary differential equations.
    2. It currently can generate either Maple or Maxima programs.
    3. It uses a specifiable number of terms of the Taylor series of the equations.
    4. The Taylor series is iteratively computed from recursive relations determined by the equations.
    5. It runs under either Linux or cygwin (a linux like environment under windows).
    6. A shell script exists for each language for which a program can be generated.
    7. A ".ode" file specifies any problem to be solved.
    8. Output (using a tee) goes both to the screen and a file which is opened with emacs when the solution is completed.
    9. There is now documentation on the ode files.
    10. It is open source software licensed under the GNU General Public License v3.0
    11. There is now documentation on the script files used to run omnisode.
    12. The only idea in my code that may be original is the way I handle systems of higher order equations. I have always seen others transform them into a system of 1st order equations. (Please remember I have not had a regular math course since 1973, numerical analysis since 1978, or computer science since 1996, so I know I may be all wrong!). I just produce one function I call "atomall" which computes the reduced derivitives for all the equations, including the higher order derivatives. I realize though there will be inter-dependencies. I recompute atomall the number of times that there are terms I am using plus the number of equations. My theory is that I should pick up all the dependencies for at least one set of terms per pass though the loop. I know that this is kind of expensive - but I think other methods must be also. (Well I admit I have watched some of the math courses at MIT free on the web.) I think it should work even for non-linear equations. I know there may not always be solutions at all, and I don't know how to tell - I suppose probably there is no way.
    13. From email exchange with Dr. Corliss, I know Dr Chang also did not reduce to a system of 1st order equations. Looking at Dr Chang's ATOMFT manual, it seems he tried to determine the dependencies, and account for them in the generated code. I could not figure how to do this in a way I could guarantee to be correct. Dr Chang admitted in his manual that ATOMFT sometimes generated faulty code (asking to be informed of it.) I suspect the difficulties were in this area.
    14. A Summary Table (8/21/2012) Now including c and c++ (really just c code but compiled with c++) is at:
      Extensive tests for c. c++, Maple, and Maxima.
    15. Improved correct digits (9/3/2012) reporting (had been incorrectly reporting value for last equation for all in systems of equations)
      Better report of tests for c. c++, Maple, and Maxima.
      Improved version was released (9/3/2012). For some reason the tests "expt_c_sin", "expt_lin_sin", "expt_sin_lin", and "expt_sin_sin" got stuck in Maxima (in a prior test) and were removed from the test.
      NOTE: I have realized (in rev0016) the "Correct digits" reported in the cases of multiple equations is that of the last equation - for all of the equations.
      This is fixed in the rev0017 release.
    16. Made to work with negative increment in rev0018.
      Also ability to display values at only certain intervals in rev0018
    17. The current omnisode (0021) was published on the web December 17, 2012.
    18. The latest published version may be obtained at The Sourceforge Download page for Omnisode
    19. Documentation needs to be reviewed and updated.
    20. rdoc generated documentation for omnisode itself. (8/16/2012)
    21. rdoc generated documentation for djd pre utility used with omnisode. (8/16/2012)
    22. rdoc generated documentation for preodein utility used with omnisode. (8/16/2012)
    23. rdoc generated documentation for preindent utility used with omnisode. (8/16/2012)
    24. doxygen generated documentation for output of omnisode for mtest6.ode. (8/16/2012)
      Note: The peculiar way some of the code is written is due to the way arrays in maxima work (they seem to be call by value).
  2. Omnisode - Where it came from

    1. I became interested in this method from Y. F. Chang at the University of Nebraska, Lincoln in about 1977-1978.
    2. Unfortunately, I became ill and was unable to complete my Masters degree.
    3. I retained an interest in it, even though it was many years before I had a computer actually powerful enough for this method.
    4. I intermittently remained in contact with Prof. Chang and Prof. George Corliss who had also been at the UNL.
    5. Prof. Corliss is now at Marquette. I believe Prof. Chang is deceased.
  3. Omnisode - Test Results

    1. Summary Table 1 of various test results.
    2. Summary Table 2 of various test results (automated).
    3. Summary Table 3 of tests of systems of equations.
    4. Summary Table 4 of various tests of a nonlinear equation.
    5. Detail of some tests automated test.
    6. Detail of systems of equations tests automated test.
    7. New Summary Table 5 of test results with links to details.
    8. Table comparing tests using three methods on difficult system of equations
    9. I realized I made a mistake on the prior table - I had the method overridden in "ode.over." I reran it and got these results:
      Table comparing tests (2nd try) using three methods on difficult system of equations
    10. After much thought and work on systems of equations I started getting better results(June 12, 2012)
    11. Same tests, but increment and number of iterations both increased by factors of 10 new results (mult H & and iterations increased by factors of 10 )(June 13, 2012)
    12. Same tests, but just number of iterations increased another factor of 10 new results (iterations increased by factor of 10 )(June 13, 2012)
    13. Same tests, but just increment (H) increased another factor of 10 new results (increment increased by factor of 10 )(June 16, 2012)
    14. Same tests, but factorials pre-computed should be same results except faster(June 17, 2012)
    15. Same tests, but factorials computed only as needed, but then saved for when needed again should be same results except faster(June 18, 2012)
    16. Tables of ode files for testing operations and functions with constants and linear expressions handled as special cases.
      Started 7/2/2012
      More on 7/3/2012
      More on 7/4/2012
      More on 7/5/2012
      More on 7/6/2012
      More on 7/7/2012
      More on 7/8/2012
      Debugging 7/9/2012
      More Debugging 7/10/2012
      More Debugging 7/11/2012
      Functions
      Functionconstant linear full series
      sin add_sub_sin_c_cos_c_tan_c (30)lin_sin_cos (28)sin_sqrt_lin (30)
      cos add_sub_sin_c_cos_c_tan_c (30)lin_sin_cos (28)cos_sqrt_lin (31)
      tan add_sub_sin_c_cos_c_tan_c (30)lin_tan (25)tan_sqrt_lin (??)**
      cosh mult_div_sinh_cosh_tanh (31)lin_cosh (28)cosh_sqrt (31)*
      tanh mult_div_sinh_cosh_tanh (31)lin_tanh (29)tanh_sqrt (31)*
      arcsin arcsin_c_arccos_c_arctan_c (30)lin_arcsin (32)arcsin_sqrt (31)*
      arccos arcsin_c_arccos_c_arctan_c (30)lin_arccos (18)**arccos_sqrt (31)*
      arctan arcsin_c_arccos_c_arctan_c (30)lin_arctan (16)**arctan_sqrt (30)*
      ln ln_c_exp_c_sqrt_c (31)lin_ln (31)ln_sqrt (31)*
      exp ln_c_exp_c_sqrt_c (31)lin_exp (32)exp_sqrt (31)*
      sqrt ln_c_exp_c_sqrt_c (31)sin_sqrt_lin (30)sqrt_sqrt (32)
      Addition
      lhs constant linear full series
      constant add_sub_sin_c_cos_c_tan_c (30)add_c_lin (32)add_c_sin (30)
      linear add_lin_c (32)add_lin_lin (32)add_lin_full (32)
      full seriesadd_sin_c (30)add_full_lin(32)lin_sin_cos (28)
      Subtraction
      lhs constant linear full series
      constant add_sub_sin_c_cos_c_tan_c (30)sub_c_lin (32)*sub_c_sin (30)*
      linear sub_lin_c (32)sub_lin_lin (32)sub_lin_sin (30)*
      full seriessub_sin_c (30)sub_full_lin (32)sub_sin_cos (30)*
      Multipication
      lhs constant linear full series
      constant mult_div_sinh_cosh_tanh (31)mult_c_lin (31)mult_c_sin (30)
      linear mult_lin_c (32)*mult_lin_lin (32)mult_lin_sin (30)*
      full seriesmult_sin_c (30)mult_sin_lin(30)*mult_sin_sin(26)
      Division
      lhs constant linear full series
      constant mult_div_sinh_cosh_tanh (31)div_c_lin (32)div_c_exp (30)*
      linear div_lin_c (32)*div_lin_lin (29)* div_lin_exp (30)*
      full seriesdiv_sin_c (30)*div_sin_lin (29)div_exp_exp (31)*
      expt
      lhs constant linear full series
      constant expt_c_c (32)expt_c_lin (31)expt_c_sin (??)**
      linear expt_lin_c (31)* expt_lin_lin (4)**expt_lin_sin (3)**
      full seriesexpt_sin_c (30)*expt_sin_lin (??)**expt_sin_sin (??)**
      Tests were done with increment (h) set at 0.00001 and 10 iterations.
      (?) = no problem figured out with analytic solution. Though I need to try some more.
      (??)= checked for analytic solution with Maple and found none.
      The number in parenthesis is approximately the number of correct digits (with Maple 12 and Digits set to 32).
      I think at least most of the answers with low precision indicate an error on my part and require further work.
      Summary Table (7/8/2012) of tests of special cases..
      * = correction made since above table generated.
      ** Checked carefully and did not find error.
      Summary Table (7/10/2012) of tests of special cases after more debugging..
      Summary Table (7/11/2012) of tests of special cases - same code except WARNINGS added for cases with difficulties..
      On closer examination I noticed that most ot the Maxima tests are missing from the above tables. I had been doing the testing with just Maple. I need to look into it.
      Summary Table (7/11/2012) of tests of special cases - same code except WARNINGS added for cases with difficulties and correction for Maxima..
      Fixed most of the Maxima (3 were taken out before as maxima just got stuck) The problem had to do with number of good digits Maple had said infinite digits when there was zero error - Maxima was quiting - now both say -1.
      It may now be downloaded from The Sourceforge Download page for Omnisode
      Summary Table (8/13/2012) Now inmcluding c++ (really just c code but compiled with c++)(A couple things don't quite compile with gcc)
      Extensive tests for Maple, Maxima, and c++
      For some reason the tests "expt_c_sin", "expt_lin_sin", "expt_sin_lin", and "expt_sin_sin" got stuck in Maxima ands were removed from the test.
      A Summary Table (8/21/2012) Now including c and c++ (really just c code but compiled with c++) is at:
      Extensive tests for c. c++, Maple, and Maxima.
      NOTE: I have realized the "Correct digits" reported in the cases of multiple equations is that of the last equation - for all of the equations.
      This is fixed in the table below (9/3/2012) is released in rev0017.
      Improved correct digits reporting (had been incorrectly reporting value for last equation for all in systems of equations)
      Better report of tests for c. c++, Maple, and Maxima.
    17. Tests (9/7/2012) with negative increment and/or display interval
      Tests with negative H and/or display interval.
    18. Tests (9/21/2012) with larger increment (0.005) - Most results OK - But some very bad
      Report of tests for c. c++, Maple, and Maxima (WITH LARGER H - 0.005).
      NOTE: (Added 10/23/2012) The tests with the larger increment have catastrophic errors if they pass over singularities. (I have known this,
      but failed to comment on it here.) I have yet to work out how to handle this - I am researching and thinking about it.
    19. Tests (12/14/2012) Ruby code can now also be generated, and problem with time fixed in c and c++.
      Completed general test and one special test comparing different interval sizes for the same problem.
      See General test 0001
      In the following table results are given for various increment sizes.
      The increment is no longer set directly - the value used is computed to try to achieve a desired accuracy.
      But the increment will not be larger than an interval set to display the results at. So there is still some control.
      It turns out larger increments are better - at least up to some point. I still need a lot more testing on this.
      See Special tests 0001
      Note: Results files larger than 10MB have been removed. Many are still larger than 1MB. Some had been over 500MB.
    20. Tests (12/17/2012) Tests with different display interval for a problem with multiple equations.
      However computed glob_h for desired accuracy was generally smaller than interval anyway.
      See Special tests 0002
  4. Omnisode - Plans for the future

    1. Work on special cases with difficulties - perhaps use other numerical methods (Maple or Maxima) for some cases I have not found analytic solutions for. Have realized (12/13/2012) sometimes error is larger because greater range covered before timeout in some languages and other factors.
    2. Update documentation.
    3. Investigate use of interval arithmetic. Now (12/15/2012) think this is probably impractical.
    4. Ruby support using APFP Almost certainly impractical.
    5. Perl support - Little reason to do - except I like playing with languages.
    6. Python support - Little reason to do - except I like playing with languages.
    7. Note that the support would be for the programs generated, omnisode will remain a Ruby program.
  5. Omnisode - Items accomplished

    1. May 22, 2012 - Language independent ".ode" files (they define a set of equations to solve)
    2. May 22, 2012 - Documentation of ode file format
    3. May 24, 2012 - Capability to add test data to a html table automatically
    4. May 25-31, 2012 - Links to detail files added to tables generated.
    5. May 25-31, 2012 - Automatic generation of test scripts.
    6. May 25-31, 2012 - Automatic indentation of programs generated.
    7. May 25-31, 2012 - Work files moved to "temp" subdirectory.
    8. May 25-31, 2012 - Added "ode.over" file to override values in all ".ode" files for batch tests.
    9. June 5-12, 2012 - Improved significantly handling of systems of (multiple) equations.
    10. June 12, 2012 - More documentation.
    11. June 15-18, 2012 - Optimized factorial calculations.
    12. July 2-10, 2012 Treat constants and linear expressions as special cases of series in order to optimize these common cases. More efficient bothe in time and space. (Mostly Done - except difficulties in a few cases).
    13. July 11, 2012 Put in warnings for special cases which seem to have problems - or have trouble checking. (Also need to check these cases again).
    14. August 13, 2012 C++ code generation functioning (Almost c also).
    15. August 21, 2012 Now C as well as C++.
    16. September 6, 2012 Made to support negative increment (H).
    17. September 6, 2012 Added capability to display values calculated only at specified intervals.
    18. November 7, 2012 Now Ruby code can be generated.
    19. December 14, 2012 Attempting to control error using estimate of radius of convergence and other factors - still needs much testing.
  6. Taylor Series - Bibliography

    1. D. Barton, I. M. Willers, and R. V. M. - "The automatic solution of ordinary differential equations by the method of Taylor series", in The Computer Journal, 14(3): 243-248, (1970)
    2. Peter Henrici - Applied and Computational Complex Analysis: Volume 1: Power Series-Integration-Conformal Mapping-Location of Zeros(1973)
    3. Y. F. Chang - "Automatic Solution of Differential Equations" in Constructive and Computational Methods for Differential and Integral Equations, Springer-Verlag, (1974)
    4. Peter Henrici - Applied and Computational Complex Analysis: Volume 2: Special Functions-Integral Transforms-Asymptotics-Continued Fractions(1977)
    5. George F. Corliss - "Integrating ODE's Along Paths on Riemann Surfaces", in Proceedings of the Seventh Manitoba Conference on Numerical Mathematics and Computing (September 29 - October 1, 1977)
    6. George Corliss and David Lowery - "Choosing a stepsize for Taylor series methods for solving ODE's" in Journal of Computational and Applied Mathematics, volume 3 and 4, (1977)
    7. Y. F. Chang - Start of Draft of book on Taylor Series (1978)
    8. D. Barton - "On Taylor Series and stiff equations" - ACM Trans. Math. Softw. 6, 3 (Sept. 1980).
    9. Louis B. Rall - Automatic Differentiation: Techniques and Applications, Springer-Verlag, (1981)
      (this was hard to get, I finally found a discarded copy from the author's university's library on a web bookstore)
    10. George F, Corliss - "Integrating ODE's in the Complex Plane - Pole Vaulting", in Mathematics of Computation, Volume 15, Number 152, (October 1980)
    11. Y. F. Chang and G. Corliss - "Ratio-Like and Recurrence Relation Tests for Convergence of Series", in J. Inst. Maths Applics 25, (1980)
    12. George Corliss and Y. F. Chang - "Solving Ordinary Differential Equations Using Taylor Series" in ACM Transactions on Mathematical Software Volume 8 Number 2, June 1982, pp. 114-144
    13. Y. F. Chang - "The ATOMCC Toolbox" in BYTE, Volume 11, Number 4, pp 215-224, April, 1986
    14. Peter Henrici - Applied and Computational Complex Analysis: Volume 3: Discrete Fourier Analysis-Cauchy Integrals-Construction of Conformal Maps-Univalent Functions(1986)
    15. Andreas Griewank and George F. Corliss - Editors - Automatic Differentiation of Algorithms: Theory, Implementation and Application, siam (1992)
    16. Y. F. Chang - ATOMFT User Manual, ver. 3.11 (1994)
    17. Martin Berz, Christian Bischof, George Corliss and Andreas Griewank - Editors - Computational Differentiation: Techniques, Applications and Tools, siam (1996)
    18. George Corliss, Christele Faure, Andreas Griewank, Laurent Hascoet and Uwe Naumann - Editors, Automatic Differentiation of Algorithms: From Simulation to Optimization , Springer, (2002)
    19. Martin Bucker, George Corliss, Paul Hovland, Uwe Naumann and Boyana Norris - Editors Automatic Differentiation: Applications, Theory, and Implementations, Springer, (2006)
  7. Notes

    1. December 21, 2012
      Test equation is:
      y''''' = -y'''
      Error appears in y''''
      Somehow must miss its calculation or using some uninitialized value in its calculation.
      Will sleep on it!
      NO SLEEP!!! - Worked ALL Night!!!
      I think I fixed the problems I had detected!
      8:30am Started General Test.
      Will sleep (hopefully) while test runs.
    2. December 20, 2012
      I studied and improved debug code.
      Located and fixed errors in pre_emit_assign and emit_assign.
      Can tell these are correct 1st time through.
      There must be additional error in jump for higher order equations.
      Began inserting debugging there.
    3. December 19, 2012
      I decided to do testing on a problem that had higher order derivatives on both lhs and rhs, but a single equation.
      Decided on:
      y''''' = - y'''
      I put in debug to give both calculated and evaluated values of analytic solutions of first several terms.
      At the beginning of a run, they were very accurate, but then suddenly a term goes wildly astray.
      Thought it might be hardware.
      Tried on a different computer - had to install ruby and program.
      Had similar results - but not exactly same. - Sudden deviation - but not same place.
      Must be software bug - like memory clobber - but some of the languages I am using are supposed to check that.
      Enough for now!!!
    4. December 17, 2012
      Tests with different display interval for a problem with multiple equations.
      However computed glob_h for desired accuracy was generally smaller than interval anyway.
      See Special tests 0002
    5. December 14-15, 2012
      Completed general test and one special test comparing different interval sizes for the same problem.
      See General test 0001
      In the following table results are given for various increment sizes.
      The increment is no longer set directly - the value used is computed to try to achieve a desired accuracy.
      But the increment will not be larger than an interval set to display the results at. So there is still some control.
      It turns out larger increments are better - at least up to some point. I still need a lot more testing on this.
      See Special tests 0001
      Note: Results files larger than 10MB have been removed. Many are still larger than 1MB. Some had been over 500MB.
    6. December 13, 2012 (Later)
      1. Fixed time in c and c++.
      2. Discovered larger error when using larger interval seems more due to larger range tested than increased step error.
      3. Started work on testing specific cases for c only (ones showing larger error in general test).
      4. Rerunning general test with time fixed in c and c++.
    7. December 12-13, 2012
      Looked at test results and ran a few more smaller tests.
      Observations:
      1. Because some tests reached max time, Maxima has greater observed accuracy, but only because it is slower and had fewer iterations to accumulate error.
      2. Times in c and c++ are too large. I can tell the tests are running much faster than measured time. Maybe what I am using as a second is really a millisecond?
      3. Most tests run accurately.
      4. Most tests that are not accurate, are accurate when smaller increment (h) is used.
      5. When the smaller h is used, the results seem too accurate to be mistaken.
      6. Need more systematic testing for cases where error seems larger (with similar h).
      7. Note: because results often time out, before completing range, increasing h not only increases error on individual step, but also greatly increased the total range covered - thus magnifying the error reported.
      8. Regarding this last note: the last fact may be overcome with more systematic settings in ".ode" and "ode.over" files.
    8. December 11, 2012
      Looked at problem again with correct debugging.
      It appeared that I had already solved problem,
      and that remaining appearance of problem was in error in debug code.
      Started another general test for overnight.
    9. December 10, 2012
      Fixed code added for debugging.
      Then too tired to debug problem.
      Also updated project for SourceForge.
    10. December 9, 2012
      Isolated one error, but could not figure it out - could not seem able to think clearly.
    11. December 4, 2012
      Fixed a couple things related to problem below.
      Seems I have, at least, a problem with a sign somewhere.
    12. November 28, 2012
      Located one problem and fixed.
      Emit_pre_diff needed modification for the special case handling.
      Still something wrong.
      Too tired to think any more.
    13. November 27, 2012
      Narrowed bug down.
      I believe it is in emit_pre_assign and emit_assign (at least).
      But I could not think clearly about how it should work.
    14. November 22, 2012
      Added debug code for 1 specific problem (diff2.ode)
      Debug code seems OK, but still haven't solved problem.
      Seem unable to think (clearly)
    15. November 21, 2012
      Added Total Expected time to solve problem to output and replaced expected lime left with it in table produced.
      I think it is more useful.
    16. November 19, 2012
      Seems there definitely is a problem (see 11/18/2012)
      Studied code and didn't find the problem.
      May have to resurrect some debugging code.
      Too tired tonight.
    17. November 18, 2012
      I went over test results.
      It seems that there are accuracy problems iff the derivative on the lhs is order greater than 1.
      That is an isolated section of code to examine, but I am too tired today.
    18. November 16, 2012 (early morning)
      Fixed problem in ode files with lines containing only blanks - introduced with logic for comments.
      Improved logic for determining size of increment - but still not really correct.
      Started another general test.
      (later) Went over results, fixed some problems and started retest.
    19. November 11, 2012
      Comments now OK in ode files (except for top equations section)
      Increment automatically calculated to obtain desired accuracy for specified range. (Including negative increments.)
      The last item is coded and runs but it seems not to always give the desired accuracy and thus needs much more work and testing.
    20. November 10, 2012
      Continued working on the same things - some progress
    21. November 9, 2012
      Worked mostly on automatically determining optimal increment size.
      It started working, but then I got sidetracked on getting comments working correctly in preprocessor (preodein.rb).
      Making progress there also.
    22. November 8, 2012
      Working on testing.
      Tweaking ode files and not using "ode.over" - thorough testing requires that for now. (Especially size of increment.)
      Would be good to make program select values itself - hopefully that will come later.
    23. November 7, 2012
      Worked on logic to adjust step size based on estimate of radius of convergence.
      Started test on this including c, c++, Maple, Maxima and Ruby.
    24. November 6, 2012
      Indenting now OK.
      Started lengthy general test.
      Intend to make some support to adjust increment size for singularities.
      Also to take larger step size as long as sufficiently accurate.
      Also to support Ruby with my APFP library.
    25. November 5, 2012
      Have Ruby code generation working.
      Also working on making output code indented properly for every supported language. (Maple, maxima, c , c++, Ruby).
    26. November 4, 2012
      Studying articles relating to increment size and pole-vaulting around singularities.
      Interesting - but seems (especially pole-vaulting) to require special analysis of individual cases.
      Started adding support for generating Ruby code.
    27. October 23, 2012
      The tests with the larger increment (below) have catastrophic errors if they pass over singularities. (I have known this,
      but failed to comment on it here.) I have yet to work out how to handle this - I am researching and thinking about it.
    28. September 21, 2012 Tests with larger increment (0.005) - Most results OK - But some very bad - No changes in code.
      Report of tests for c. c++, Maple, and Maxima (WITH LARGER H - 0.005).
      Expect to mostly be studying problem of error control and experimenting with code - no more releases likely for a while.
    29. September 8, 2012
      The current omnisode (0018) was published on the web.
    30. September 7, 2012
      Improved September 6th work and made test below:
      Tests with negative H and/or display interval.
    31. September 6, 2012
      Made to support negative increment (H)
      Added capability to display values calculated only at specified intervals.
    32. September 3, 2012
      Improved correct digits reporting (had been incorrectly reporting value for last equation for all in systems of equations)
      Better report of tests for c. c++, Maple, and Maxima.
      Released this version (0017).
      This version (0017) may be obtained at The Sourceforge Download page for Omnisode
    33. September 2, 2012
      Fixed problems in my work done on August 30, 2012. Started general test.
    34. August 30. 2012
      Fixed problem with "Correct Digits" (see below) and started general test.
    35. August 22, 2012
      I have realized the "Correct digits" reported in the cases of multiple equations is that of the last equation - for all of the equations.
      This will be fixed in the next release.
    36. August 21, 2012
      Ran general batch test with fixes from yesterday
      There were some problems, so there is more to do before I post results.
      However I can give better time comparisons.
      I discovered the time reported by Maple is CPU time - so I am using the difference in the times in the time stamps instead.
      Maxima can report either clock or CPU time - there are 2 functions - I am using clock time.
      C and C++ report clock time.
      The following was obtained with mtest6.ode
      Maple did 100 iterations in 24 seconds (17 seconds CPU)
      C++ did 69 iterations in 60 seconds
      Maxima did 8 iterations in 67 seconds
      This is:
      Maple 4.17 iterations/second
      C++ 1.15 iterations/second
      Maxima 0.12 iterations/second
      NOTE: The comparison is not altogether fair. Digits was set to 32 for Maple, while only 16 digit precision was obtained for C++ and Maxima
      After Sleep:
      Fixed problems with changes to support local variables in ode files for maxima.
      Fixed Digits reported in c and c++ (got it right this time).
      Reversed order of entries is results table.
      Added script files for c.
      A Summary Table (8/21/2012) Now including c and c++ (really just c code but compiled with c++) is at:
      Extensive tests for c. c++, Maple, and Maxima.
      Published current omnisode (0016) on the web.
      The latest published version may be obtained at The Sourceforge Download page for Omnisode
    37. August 20, 2012
      Fixed a number of problems with last release (omnisode0014)
      1. Made to work with c as well as c++ (using gnu gcc and g++)
      2. Fixed time measurement in c and c++ (Also note Maple time is CPU time - Maxima, C and C++ time are clock time)
      3. Fixed digits field in table for c and c++
      4. Added number of correct digits to output and table when analytic solution given
      5. Added beautify program for tcppl.sh script.
      6. Made preodein.rb handle local declarations for maxima (only affects analytic solutions)
    38. August 12-13, 2012
      Testing and debugging c++. Test results at Extensive tests for Maple, Maxima, and c++
      For some reason the tests "expt_c_sin", "expt_lin_sin", "expt_sin_lin", and "expt_sin_sin" got stuck in Maxima ands were removed from the test.
      Need to study results thoroughly.
    39. August 11, 2012
      Ordered the 3 volumes of Peter Henrici - Applied and Computational Complex Analysis
      Finished work on generating c and c++
      Started testing c and c++ - a few corrections, but going well.
    40. August 10, 2012
      Added blocks and declared all local variables in maximas. Maxima was a little slower with the blocks added, but not very significantly. I knew where they all went, as I had them (local declarations) for Maple, and mint checks that so I should not have missed any. I have found out how to use big floats in maxima. It will be quite a bit of work, and as maxima is sort of slow, and presumably this would make it slower, I am not pursuing this now. Most of the time, I suspect input data to real problems is not known that accurately anyway. I will be looking into interval arithmetic though - probably not for maxima. Maple has something but I don't know if it will do what I need. I understand what mode_declare does now, but it doesn't support big floats, so I will avoid it for now. I don't have not had problems without it, and I think it is only effective if the code is compiled. I am not interested in compiling as then I could not use big floats, and I want to do that someday. Next, I guess, is finishing up C and C++.
    41. August 9, 20121
      I ran a timing test comparison for c++, Maple and Maxima.
      Set time limit to 1 minute.
      Maximum iteration was sufficient to solve entire problem.
      Problem was sin.ode for all three.
      Output was redirected to file only - none to screen
      Results:
      c++ solved entire problem in 23 seconds (140001 iterations)
      Maple performed 11542 iterations in 60 seconds
      Maxima performed 372 iterations in 60 seconds
      That amounts to:
      c++ 6,087 iterations/second
      Maple 192 iterations/second
      Maxima 6.2 iterations/second
      c++ is almost 32 times faster than Maple which is almost 31 times faster than Maxima.
      So c++ is almost 982 times faster than Maxima.
      Later (I think my dates may be off the last few days):
      Removed mode_declare's from maxima
      Then maxima performed 394 iterations in 60 seconds
      Or:
      6.6 iterations/second.
      Was able to get bloats (with trig functions) to work in maxima. I had misunderstood syntax before.
      Am going to try to compile maxima code - I realize I cannot do this with if I use bfloats - which I don't now.
    42. August 8, 2012
      c++ mostly working. So much faster will have to modify output.
      Files produced are too large to view, if enough iterations are used in order measure time.
    43. August 7, 2012
      c++ version running and giving good answers with very limited testing.
      Some problem with displaying time data, but it appears to be much faster than either Maple or Maxima.
    44. August 3-6, 2012
      Working on adding c and c++ to languages generated.
      Going much easier than anticipated.
      Mostly just tedious parts left - a few tricky ones also.
    45. July 27, 2012
      Checked coding of Chang's case 5 for expt_lin_lin.ode and found nothing wrong. Tried using Taylor series of 250 terms but this did not help. The analytic solution and derivation of Chang statements are beyond my skill level currently. I got to thinking that I remembered something on this in Rall (1981). Looked and found it. Not sure if it will help or not. No time now.
    46. July 11, 2012
      Made release 0013 It may be downloaded from The Sourceforge Download page for Omnisode- Main change is to handling constants and linear expressions as special cases.
      See test results above
    47. July 1, 2012
      Did sqrt, and modified array allocation to save memory as made possible with optimized logic.
    48. June 27-30, 2012
      All cases of exponentiation coded, except sqrt.
      Next - a lot of testing!
    49. June 25, 2012
      Continued changes for constants and linear expressions - exp, and log done.
      Log has truncation problem
    50. June 24, 2012
      LanguageCompute every timePre-compute allCompute as needed and saveWith Linear Opt
      Maple 1 min 40 sec (16 digits) 29 sec (16 digits) 41 sec (32 digits)20 sec (32 digits)
      Maxima 40 min 33 sec (16 digits) 31 min 58 sec (16 digits) 31 min 25 sec (16 digits)8 min 52 sec (16 digits)
      What I used here was the time left - I should have used the time elapsed + time left. - I did not think of that before.
      But I don't think it really matters - they should be proportional to each other.
      By linear opt, I mean taking advantage of the fact that the operand to the sin function is linear (In this particular example).
      Did more testing on arccos & arctan. Fixed 2 typos in arctan. Both did better when dividing increment by 100 even though multiplying iterations by 100. Thus it must be truncation error. (Getting about 20 place accuracy.)
    51. June 23, 2012
      I ran into less accuracy with arccos and arctan than I have been typically getting. (I know the domain of values matters and that I need to do much more thorough testing. I am to mostly trying to catch blatant errors now. But I was getting significantly less accuracy (for the domain I was using) for arccos and arctan than other functions. So I decided to look at the Fortran code generated by Chang's Atomft. First I tried it on Linux, but was unable to find g77. So I tried cygwin, and after a little work (mainly running d2u on the files and reworking the make files to my liking. - I had used Atomft before but only retained the original zip file.) ran it on the arc functions. I got error messages - they are not supported by Atomft. Then I went back to Linux and, with a little web browsing, found out that g77 is now called gfortran - and got the same results.
    52. June 21, 2012
      Continued changes for constants and linear expressions - sinh, cosh, tanh, and arcsin done.
    53. June 20, 2012
      Continued changes for constants and linear expressions - division, cosine and tangent done.
    54. June 19, 2012
      Continued changes for constants and linear expressions - subtraction and multiplication done.
      Also looking at some Taylor series capabilities in Maxima - should also look at Maple
    55. June 18, 2012
      Same tests, but factorials computed only as needed, but then saved for when needed again should be same results except faster(June 18, 2012) Started revisions to treat constants and linear expressions as special cases of series in order to optimize these common cases.
      I have modified the basic structure for this and implemented and tested for addition and sine.
    56. June 17, 2012
      Same tests, but factorials pre-computed should be same results except faster(June 17, 2012)
      I have revised the factorial logic again. Instead of pre-computing all the factorials, I am just computing them the first time needed. Also I noticed (Affecting maple only) I had Digits set to 16 in sin.ode, to 50 in h2sin.ode, h3sin.ode and sing4.ode, and to 100 in sing4.ode.
      These are all now set to 32. (like everything else).
      The timing results for sin.ode were:
      LanguageCompute every timePre-compute allCompute as needed and save
      Maple 1 min 40 sec (16 digits) 29 sec (16 digits) 41 sec (32 digits)
      Maxima 40 min 33 sec (16 digits) 31 min 58 sec (16 digits) 31 min 25 sec (16 digits)
      I have another general test running. It will take several hours and is on another computer so my editing here does not affect it
    57. June 16, 2012
      Same tests, but just increment (H) increased another factor of 10 new results (increment increased by factor of 10 )(June 16, 2012)
      NOTE: sometimes maxima's error is less - but because it reached the maximum time (set to 15 minutes) before it reached maximum iterations.
      Pre-calculated factorials to increase efficiency. Running test.
    58. June 13, 2012
      Same tests, but increment and number of iterations both increased by factors of 10 new results (mult H & and iterations by factors of 10 )(June 13, 2012)
      Same tests, but just number of iterations increased another factor of 10 new results (iterations increased by factor of 10 )(June 13, 2012)
    59. June 12, 2012
      After much thought and work on systems of equations I started getting better results.
      The poorest are mtest5.ode, mtest9.ode, mtest9_rev.ode and log.ode.
      BTW: mtest6.ode and mtest6_rev.ode were previously called complicated.ode and complicatedrev.ode
    60. June 8, 2012
      I added a capability to give initial conditions of order for a dependent variable higher than what appears on the LHS, to go along with permitting them on the RHS. This, I think is needed for some systems of equations. For such terms, there values will not be updated in the "atomall" loop. Rather, they will be projected in the "jump_series" function. I have all this coded and running, but have not yet made any examples where it is really used. I had to make a change to the "ode" files in order to accomplish this. Next I need to update the existing ode files (I have only done one.), and come up with some real examples.
    61. June 6, 2012
      Made global variable in omnisode to set which of 2 ways to jump - relating to the subiter methods and multiple equations. It runs but too tired to really test. Need better sets of equations - I have some ideas - but too tired now.
    62. June 5, 2012
      Had to make changes to omnisode to handle the sort of problem I was thinking of - I think I need a yet harder problem!
    63. Table comparing tests using three methods on difficult system of equations
      I realized I made a mistake on the prior table - I had the method overridden in "ode.over." I reran it and got these results:
      Table comparing tests (2nd try) using three methods on difficult system of equations
      I need interdependent equations at higher orders I think. I think maybe I have now made it so that one need not have the highest derivatives on the LHS!
    64. June 4, 2012
      Uploaded omnisode0010.tar.gz to The Sourceforge Download page for Omnisode Modified omnisode to use either one sub-iteration or total order sub-iterations or total order + max terms sub-iterations according to the variable glob_subiter_method is set to 1, 2 or 3 in the ".ode" file or "ode.over" file. This is to make testing easier. I need to invent an example that would seem to require the higher number of sub-iterations.
    65. June 3, 2012
      Working on improving my HTML and omnisode documentation. I made documentation on the script files used to run omnisode.
    66. June 2, 2012
      Testing various numbers of sub-iterations with various increments:
      1. H = 0.00001
      2. H = 0.00005
      3. H = 0.0001
      4. H = 0.0002
      5. H = 0.0005
      6. H = 0.001
    67. June 1, 2012
      I am uncertain of something having to do with the solution of multiple (simultaneous) equations. Obviously some either have no solution or no unique solution. E.g.:
      diff(y1,x,1) = diff(y2,x,1)
      diff(y2,x,1) = diff(y1,x,1)
      Has as solutions any differentiable equations where y1 and y2 differ by s constant.
      When I first started I first tried sorting the equations - but this cannot always be done. Then I tried executing the code (atomall) in a loop, until the solution stopped changing much, but this was inadequate. Then I tried executing the loop the number of times there were equations, but I decided this was insufficient. I currently have the loop executing the sum of the orders of the equations times. I am not sure if this is adequate or not. Perhaps one needs to add the number of terms of the series to this. Of course, one still cannot arrive at a solution when there is none or a unique solution when there is none, but perhaps one can usually (except when the function is badly behaving for some other reason) obtain a solution in cases where there is, indeed, a unique solution.
      I did some testing on this while watching the Celtics win.
    68. May 31, 2012
      Uploaded new test results with links to details.
      Waiting till I have things better tested and documented before another release.
    69. May 27, 2012
      Testing a nonlinear equation.
      Updated information on omnisode on Sourceforge and added latest tar file to its download page.
    70. Msy 26, 2012
      Ran automated test.
      Also ran tests on systems of equations.
    71. May 25, 2012
      I have realized a slight problem with how I track the "revision" of the code in my table.html. Fairly often, especially when I reach a staple point, I run a script to save the three main pieces of ruby code. They are saved with numbers I specify, and the script prevents overwriting. It also saves the revision numbers in a file, used in the table.html when a test is recorded. Well, in testing I noticed when a test completed all the way to the end point (no timeout or maximum iterations reached), the cell containing the expected time remaining was not filled, and everything after it is shifted a cell to the left. So I worked fixing it. But I did not save my work after every attempt, so the "revision" codes only indicate the last time the code was saved - not the last time it was changed.
      I've worked more on the html table The prior results are at html table 0001
    72. May 24, 2012
      I spent the last two days implementing automatic testing - constructing an html table automatically.
      I haven't made any more changes to the algorithm. It will take a little time to decide how to package the automatic table generation.
    73. May 23, 2012
      The new tar file is omnisode0007.tar.gz which may be obtained at the Sourceforge download page for Omnisode.
      There is one ode file format for both Maple and Maxima.
      The ode file format was documented yesterday.
      I briefly tested all ode files with maxima, and all seemed OK except complicated.ode and log.ode. Complicated seemed stuck. Maybe it was just very slow. Complicated.ode seemed OK with Maple. Also log.ode was not very accurate. But logs are difficult.
    74. May 22, 2012
      Maple: Sample generated Maple program
      Maple: Sample Maple program results
      Maxima: Sample generated Maxima program
      Maple: Sample Maxima program results
      I have written and tested making the ode files language independent. I have documented the ode files.
      It will be tomorrow till I get the tar file made - less than a half hour.
    75. May 21, 2012
      More testing of new version (tar file from May 20).
      See testrecords.html
      I believe Maple is limited to about 32 digits precision. That's all I seem to get, and there is a negligible time difference in calculations assigning either 32 or 100 to "Digits".
    76. May 20, 2012
      After considerable effort trying to get my software to use maxima big floats, I realized that maxima does not support many functions (e.g. trig) for big floats. My software, thus, only supports 16 digits for maxima. I did, however, fix a few other things in trying. I have had time to do only limited testing, but I know of no problems, other than that the order of poles seems a little off, although the radius of convergence seems ok. Next I plan to do extensive testing and work on documentation.
      omnisode0006.tar.gz was made.
    77. May 19, 2012
      It works for both Maple and Maxima now.
      The biggest difficulty had to do with arrays in Maxima. It seems they are call by value.
      I ended up using global arrays, and having the Ruby program generate code for each separate array.
      I haven't had enough time to test enough, but the code is greatly improved!
      The latest results are at:
      testrecords.html
      omnisode0004.tar.gz was made. I always worry that something will happen to me, before I finish.
    78. May 15, 2012
      It is working pretty well now.
      I need to refamiliarize myself with sourceforge's tools but there is a tar file on my own web site for now:
      omnitar0001.tar.gz was made. (removed as obsolete)
      The testrecords.html has also been updated.
      There is one sample output (and Maple echos the program) at Sample Solution
    79. May 14, 2012
      I have fixed a couple problems including multiple equations.
      The results have been added to the testrecords.html
    80. May 12, 2012
      I am making some progress on this again the past few weeks.
      I talk about this some on my blog Dennis' Daze
      I am not releasing anything yet, but may start using the source version control tool soon.
      A table of results of testing is at testrecords.html
    81. December 12, 2010
      I have abandoned this project.
      There are problems I am unable to solve and my mind is not working well.
      I intend to devote myself to philosophy - and may do some prolog programming for that.
    82. These Ruby programs generate programs in Maple or Ruby to solve Systems of Ordinary Differential Equations. A long Taylor series method, pioneered by Prof. Y.F. Chang, who taught at the University of Nebraska in the late 1970's when I was a graduate student there, is used. The number of Taylor series terms can be specified in the problem file, though it is usually 30. The Maple version is gone as, at least for now, I do not have Maple available to me. I have started on a maxima version. In it I am taking time to remove some of the biggest inefficiencies. Also I may have found an error that I am trying to resolve. The Ruby version below would possibly also contain the error. But no one has reported any problems to me.
    83. Coming soon here - a maxima version
    84. There are problems with the Ruby and Maple versions which will have to wait until the maxima version is released.
    85. Y. F. Chang's Draft Typescript(1978) on Taylor Series Chang on ATS
    86. The Taylor series terms are used to calculate the values of the dependent variables, and also (optionally) the radius of convergence and order of any singularities. These can be used to reduce the size of the next increment. These can be used to reduce the size of the next increment. Increasing it in the middle results in large errors because each successive term is multiplied by increasing powers of the ratio of the new h to the old h. In the beginning I determine h by starting with a very small h and increase it until the estimated truncation error is as large as specified as permissible.
    87. To visit the sourceforge project web page try Sode Project Page
    88. For info on RubyApfp: RubyApfp Home Page
SourceForge Logo