We now always use MathJax for HTML docs so that formulas look nice.
o Remove the --enable-mathax option from configure.ac
o build_html.sh.in sets HTML_MATH to mathjax so texinfo will use
Mathjax.
o texi2html.init.in no longer needs @mathjax_script@. Texinfo takes
care of this for us.
NOTE: The current HTML docs look kind of bad now because displayed
formulas aren't and all HTML formulas are wrapped in "$$". This needs
to be fixed before we can deploy this.
Put more space between the integrand and the differential.
For the list of elementary functions in terms of carlson_rc, add more
space between the formula and the constraint. It was kind of smashed
together and hard to read.
Previously, we the html and tex docs didn't actually define
elliptic_eu in terms of integrals. It just listed the integrals. Add
elliptic_eu to the integrals to make it clear.
Add a little extra space around dv in the integral.
Make the html and tex formula for the relationship between elliptic_eu
and elliptic_e match the info version.
Make "sn" be roman instead of being in math font in the html version.
transl: subscripted functions now behave correctly
Prior to commit ce1ea1c1 any array functions (including subscripted
functions) would always silently fail to translate. After that, and
prior to commit 21ec6fc9, subscripted functions suffered from the
same problem as general upward funargs wrt free vars that were bound
in the definition environment. Since that commit, the lambdas created
by subscripted functions have not been able to see the values of the
subscripts:
(%i3) g[n](x) := [n, x]$
(%i4) translate(g)$
warning: subscripted functions do not translate well: g[n](x):=[n,x]
(%i5) g[1](2);
(%o5) [n,2]
Now this commit fixes the behavior of translated subscripted functions
so they more closely match the behavior of their interpreted
counterparts:
(%i11) translate(g)$
(%i12) g[2](3);
(%o12) [2,3]
Like with commit 21ec6fc9, the implementation of this is different
compared to how it was done in Macsyma and (very) old Maxima. See
that commit for more on this (and the inconsistent behavior that was
in Macsyma).
No problems with the test suite, share test suite or rtest_translator.
New tests have been added to rtest_translator which compare the
translated and interpreted results for various cases.
transl: upward funargs no longer cause lisp errors due to free vars
The behavior of translated upward funargs were inconsistent in Macsyma
and have been broken in Maxima for decades. See below for more on the
inconsistent behavior in Macsyma.
Translated upward funargs would easily cause lisp errors:
(%i1) f(x) := lambda([], x)$
(%i2) translate(f)$
(%i3) f(5)();
<lisp error>
Now this commit fixes the behavior of translated upward funargs so they
more closely match the behavior of their interpreted counterparts:
(%i5) translate(f)$
(%i6) f(5)();
(%o6) x
The implementation of this is different compared to how it was done
in Macsyma and (very) old Maxima. You can find some old methods for
this in the code and comments for, say, Maxima 5.0.
In Macsyma the translated case was inconsistent with the interpreted
case. In the case of my function f above, f(5)() would yield x in the
interpreted case but it would yield 5 in the translated case.
We do not have this inconsistency now:
(%i12) zf(x) := lambda([a], [x, a])$
(%i13) translate(zf)$
(%i14) zf1 : zf(1)$
(%i15) block([x : 'ux], zf1(2));
(%o15) [ux,2]
Here %o15 matches the interpreted case, as it should. In Macsyma, this
would be [1,2] instead.
Since commit ce1ea1c1 subscripted functions can be translated again,
but they have suffered from this same problem as general upward funargs.
An upcoming commit will further fix subscripted functions so the lambdas
created remember values from the subscripts (without all lambdas
remembering too much, which was the cause of the inconsistent behavior
in Macsyma).
No problems with the test suite, share test suite or rtest_translator.
New tests have been added to rtest_translator which compare the
translated and interpreted results for various cases.
