Mobile Web REDUCE
Fix the load failure for the defint package by including the misc
package, which defint requires. Also fix a typo in an error message
in "support/entry.red", which the defint problem showed up.
git-svn-id: https://svn.code.sf.net/p/reduce-algebra/code/trunk@6498 2bfe0521-f11c-4a00-b80e-6202646ff360
This commit changes printing so that (-1/2) [amd similar] gets rendered
-1 - 1
---- vs -----
and also to try to avoid some numeric output wnding up like
with a backslash and line break in a location I view as awkward. The
example "linelength 77; for i := 1:20 collect (-i^2);" is a concrete
example that triggered that behaviour. This causes quite a lot of the log
files to change and I am not installing updates to them in this checkin so
as to give a greater prospect that people look at what has changed and as
necessary complain! But log updates will follow in a day or so...
git-svn-id: https://svn.code.sf.net/p/reduce-algebra/code/trunk@6495 2bfe0521-f11c-4a00-b80e-6202646ff360
Definite integral of sqrt
The definite integral int(sqrt(x*(1-x)),x,0,1) evaluates to -pi/8 but
is obviously positive! The substitution x = (1 + sin theta)/2
facilitates evaluation by hand to +pi/8. REDUCE evaluates this
integral by indefinite integration to a complex-valued expression
involving logarithms, followed by substitution of the limits. Doing
this interactively gives the result (-i log i)/4. Noting that log is
multi-valued in the complex plane, the result can be expressed as pi/8
+ n pi/2 for any integer n, and choosing the principal branch gives
the correct result pi/8.
However, when REDUCE performs this calculation automatically, it calls
mkdint in "int/dint.red", which sets "off precise" to avoid ugly
results involving abs. Eventually, defint11s in "defint/defintx.red"
is called, which splits out any factor of the integrand that is
independent of the integration variable. For the integrand in
question, with "off precise", it splits out a factor of the imaginary
unit and changes the form of the integrand into a product of square
roots. I think it is this change to the integrand that leads to the
integral having the wrong sign.
One solution would be to set "on precise": doing so and then calling
defint0 by hand gives the correct result. However, this is likely to
lead to ugly results involving abs in similar but more complicated
cases. So the solution I have chosen is to test whether the factor of
the integrand that is independent of the integration variable is pure
imaginary, and if so ignore the factorization and pass the whole
integrand to the integrator via defint11.
I have also modified defint11 slighlty to avoid unnecessary
simplification of the integrand before passing it to simpint,
otherwise the fix to defint11s doesn't work.
The revised code runs the test file exactly as before, but also
evaluates the integral in question correctly, which I have added to
the test and log files.
git-svn-id: https://svn.code.sf.net/p/reduce-algebra/code/trunk@6492 2bfe0521-f11c-4a00-b80e-6202646ff360
The economise package now has a facility for renderiing reduce numeric
values as C or C++ hexadecimal floats as in
load_package economise; prinhexlit pi;
generates 0x1921fb54442d18p-51 with a hexadecimal mantissa and an exponent
indicating a power of 2. There are also facilities for generating the
"double-double" and "triple-double" schemes where slightly more precise
floating point values are worked with using two or three regular floats.
These may be relevant in the sort of circumstances one wants an economised
series expansion for a function of some sort...
git-svn-id: https://svn.code.sf.net/p/reduce-algebra/code/trunk@6491 2bfe0521-f11c-4a00-b80e-6202646ff360
More progress with mrvlimit.
The problems with OFF MCD described in r6486 turned out to be the Taylor package's fault.
With mcd off, and the rule log(ww) => -x in effect, the expansion of
f := log(log(x) + ww^(-1))^(-1);
with respect to ww used to return
2 2 3 3 4 -1
((log(x)*ww - log(x) /2*ww + log(x) /3*ww + O(ww )) + x)
i.e. with single +x that should be moved into the Taylor kernel.
With this commit, the correct result is
-1 2 2 3 2 3
x - log(x)/x *ww + (log(x) *(x + 2))/(2*x )*ww + O(ww )
git-svn-id: https://svn.code.sf.net/p/reduce-algebra/code/trunk@6490 2bfe0521-f11c-4a00-b80e-6202646ff360
CSL: On the Macintosh m1 but certainly not on some of the other platforms
merely creating an objkect of type std::basic_random seems to incur a serious
real time delay (presumably as it accumulates entropy). That led to running
arithtest on the Mac m1 (at least) to have an extreme real-time - much longer
than its cpu time. I have also tidied up a bit of code that I hope will let
a checksum used in arithtest to be gfot correct on 32-bit systems.
git-svn-id: https://svn.code.sf.net/p/reduce-algebra/code/trunk@6488 2bfe0521-f11c-4a00-b80e-6202646ff360