/usr/share/doc/mathomatic/ideas.txt is in mathomatic 15.8.2-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 | Ideas to code in Mathomatic
---------------------------
A free software GUI needs to be written for Mathomatic. Anyone interested in
writing one should contact me at some point, so it can be included in the
Mathomatic distribution.
Implement natural logarithms as the "log(x)" or "ln(x)" function, using a
dummy operand internally. The dummy operand should be the M_E constant for
logarithms with changeable base and should be first. The rules for logarithms
can be slowly added later. This is a large project that only George Gesslein
II knows how to do properly (well, maybe). An easier idea to implement will
be to make logarithms a binary operator like in the J programming language,
then use m4 as a macro preprocessor to map the log(x) and ln(x) functions to
it. I am currently looking for ideas on which ASCII character or characters
should represent the logarithm function.
Simplify nested radicals like ((9 + 4*(2^.5))^.5) to (1 + 2*(2^.5)). This may
be difficult, I don't know how this is generally done. Slow trial and error
algorithms are not acceptable for this. Here is an article on how to do this:
"http://www.almaden.ibm.com/cs/people/fagin/symb85.pdf". Also, see Landau's
algorithm (http://en.wikipedia.org/wiki/Landau%27s_algorithm).
Use the GNU Scientific Library (GSL) to automatically numerically solve any
degree numeric polynomial equation, like "misc/roots.c" does, when symbolic
solving fails. Unfortunately, the GSL results are sometimes inaccurate, and
it adds a library dependency, so I may not do this. Instead, the general
cubic formula in "tests/cubic.in" could be hard-coded into the Mathomatic
poly_solve() function, so any cubic equation could be automatically solved. I
just haven't figured out how Mathomatic is going to easily handle 3 solutions
per equation space. Solving quartic equations with "tests/quartic.in" is not
recommended, due to the large, accumulated round-off error of floating point
when approximating large formulas, and the many cases that quartic formula
causes division by zero and fails, though handling an even number of
solutions is very easy in Mathomatic.
Implement complex number factorials, when an accurate, floating point,
complex number gamma calculating function is found. The GSL does this.
Make polynomial gcd calculation partially recursive. This is difficult, as
the expression storage areas are currently static globals. If successful,
this will make polynomial gcd calculation multivariate, so it will succeed
with larger expressions with many variables. There is no need for total
recursion, because it would never be used anyways, with the amount of
floating point round-off error that occurs in Mathomatic. Every inexact
floating point mathematical operation has a small round-off error that adds
up with many operations, making polynomial gcd determination fail with large
polynomials, anyways.
Add a "polynomial" command that tells what type and degree polynomial the
current expression is, if it is a polynomial in the optional specified
variable. Study Maxima's facsum() function, it does a related thing.
matho and rmath don't work perfectly; because they use m4 as a front end,
there are some user interface problems. I probably should write some C code
to do the string macro expansion as part of the main mathomatic program. If I
am feeling better I will do that and add logarithm function support.
-----------------------------------------------------------------
This file was written by George Gesslein II of www.mathomatic.org
|