1
KNOWN BUGS AND PROBLEMS IN REDUCE 3.3
----- ---- --- -------- -- ------ --15
July 1987
This document contains an account of every known bug and problem in
version
3.3 of REDUCE. We would appreciate suggestions from the user community
on
possible corrections to any of these problems. Most of the system
dependent
problems require changes to the relevant LISP interpreter, which because
of
resource limitations we are however unable to consider at the present
time.
PARSING, etc.
------- --* It is not possible at present to use non-scalar quantities such as
arrays and matrices as locally defined objects, or arguments or values
of procedures.
* Duplicate variables in a FOR statement (e.g., FOR I := ... DO FOR I
:=)
are not diagnosed.
* x**+2+5 is treated as x**7, rather than x**2 + 5.
SIMPLIFICATION, etc
-------------- --* The inversion of matrices with floating point coefficients can
sometimes
result in a catastrophic error (division failed). This is because the
algorithm currently used for matrix inversion depends on exact division.
Since floating point numbers are not exact, this can lead to a failure
of
this algorithm.
* Expressions involving floating point numbers do not always match
against
rules set up for equivalent integers. E.g., sin(0.5*pi) remains
unchanged
when float is on, whereas it returns 1 in integer mode.
* Arbitrary precision integers or reals are not converted into single
precision reals if the mode is changed to FLOAT.
* If you turn off the bigfloat switch, expressions containing arbitrary
precision reals may not always reduce to lowest terms.
* It is not possible at present to set non-scalar quantities such as
arrays, matrices or high energy physics vectors to common values such as
0, 1, etc. by a direct assignment. However, the difference of two equal
matrices or high energy physics vectors is now returned as a zero matrix
or vector, rather than as a scalar zero as previously.
* For efficiency reasons, whenever a term of a product is found to be
zero, the whole product is replaced by zero without looking at the rest
of
the terms. If one of these happens to have a zero denominator, an error
should result, but this doesn't happen. An example of this is the
sequence a := x; b := 1/x; x := 0; a*b;
* REDUCE currently simplifies expressions involving surds by a number of
different heuristic techniques, rather than by a complete algorithmic
approach. Consequently such expressions are not always reduced to
lowest
terms. For example, the expressions e**(3*x/2) - e**x*e**(x/2) and
e^(3a/b)-e^(2a/b)*e^(a/b) do not reduce to zero, and expressions like
sqrt(15)/sqrt(5) do not simplify further.
* The functions ERF and TANH do not evaluate when NUMVAL is on.
* OFF RESUBS, described in the REDUCE 3.2 and earlier user's manuals,
does
not work properly with several classes of substitutions including
powers.
For example, the statements
off resubs; for all n let x^n=x^(n+1)/(n+1); x^2;
result in an infinite loop. Given the contorted nature of the current
simplification process, it is almost impossible to guarantee that this
switch will ever work properly. As a result, it is not described in the
current user's manual.
LET, ASSIGNMENTS, etc.
--- ----------- --* Rules like x**a*x**b=x**(a+b) are accepted by the system, but because
they interfere with the internal simplification procedures, lead to
infinite loops either during their definition or during simplification
of
expressions involving such products.
* Some rules that are outside the scope of the LET mechanism are not
trapped (e.g., a rule like for all x,y such that not ordp(x,y) let
(x:=y)
= (y:=x))
INPUT, OUTPUT, etc
----- ------ ---
* It is not currently possible to input an arbitrary precision real
number, or an integer longer than one line (unless in the latter case
the
implementation supports end of line hyphenation). Furthermore,
arbitrary
precision reals or long integers are not truncated appropriately when
output with FORT on.
* Arbitrary precision reals are sometimes broken across lines even those
that can fit easily in one line.
* The WRITE statement can output a differing number of end-of-line
characters in symbolic as opposed to algebraic mode. For consistency,
it
would be better if the format was the same in each mode.
* With ECHO on, spacing is not always consistent, reflecting differences
in the underlying LISP system's handling of this. Furthermore, in
several
systems, "on echo" in interactive mode does not cause input from a
terminal to be echoed.
* If a CONTinue from a pause imbedded in an IN file is pending, the
return
from an inner nested IN file returns to the top level, instead of just
to
the next higher IN file level.
ASYMPTOTIC CALCULATIONS
---------- -----------* A variable which has been given a weight cannot then be used in
another
weight statement or used anywhere where a kernel is expected, such as in
the left-hand-side of an equation in a SUB statement, or as the
differentiation variable in a DF expression. Either results in an error
message like "x invalid as kernel".
SOLVE PACKAGE
------------* The solve package does not work properly if the switches exp, factor
or
mcd are not at their default settings.
DOCUMENTATION
------------* Many of the documentation files use <control>H for underlining, as
opposed to a carriage return followed by underlining in the correct
position used in the rest.
printers
(nor does the latter!)
The former method doesn't work on all
SYSTEM-RELATED
------ ------* If there is insufficient memory (either for binary programs or in the
expression heap) for the complete load of a compiled module, the system
is usually left in a corrupted state after the error.
IBM SPECIFIC
--- -------* The property list model in the IBM SLISP system is wrong.
example,
the sequence
For
put('x,'a,'b); put('x,'c,'d); get('x,'d);
results in the value A rather than NIL.
* The use of system fluid variables as parameters can lead to incorrect
results. Most of these variables contain an asterisk, and the manual
requests that users don't casually use such variables. Unfortunately,
the
integrator uses several fluids with alphanumeric names, so a clash can
occur. "Variable" is an example of such a variable, so that the
procedure
defined by
procedure test1;
begin scalar variable;
write "int(",x,",",x,") = ",int(x,x);
return
end;
prints a zero value for the integral.
* In the IBM SLISP system, you cannot read a file while another is open.
* In SLISP itself (as opposed to RLISP or REDUCE), '() gives an infinite
loop, whereas 'NIL works fine.
* FIX of a floating point number with absolute value larger than
2.684354E8 is zero. This relates to the interface between single and
arbitrary precision integers.
* Floating point numbers are sometimes returned inaccurately rounded
down.
E.g., 123456.7 is returned as 1.234566E5.
* When reading a file with the IN command under TSO, a blank line is
displayed after each COMMENT text line. A blank line also appears
following any wrap around from long lines in the input. The setting of
INT or ECHO does not affect the problem. It is apparently caused either
by the interpreter sensing BATCHP, or by the LRECL 133 wrap around under
TSO.
* The statement "in lib(xxx)" fails if xxx is a statement keyword (e.g.,
FACTOR).
* With the current assembler, the code for a given function cannot be
more
that 4096 words long. However, at the present time, all functions in
the
distributed source compile within that limit.
* Some space management commands cannot be used from within REDUCE.
BPSMOVE generally results in a PSW trap. RESTORE does not reinitialize
the session correctly.
* The characters {, ^ and } (HEX codes 8B, 8F, 9B) which are used in the
some of the source files are not supported in all systems.
* The characters with HEX codes AD, BD, 8B, 9B and 2F, which appear in
the
documentation, are not supported in all systems.
* Under CMS, if XEDIT is invoked from a virtual machine larger than the
machine size specified when XEDIT was initially installed in the shared
text segment, LISP will blow up, typically with a system abend.
* Under CMS, the LRECL value is wrong for interactive use, but is
overriden
by the VM console support. The interpreter should set BATCHP, then set
the
LISPOUT LRECL.
* Under CMS, ID table overflow can result in a PROTECTION EXCEPTION
abend,
if sufficient space has not been made available with the R= parameter
when LISP is invoked. See Memory Requirements in the User Guide.
* Recovery from errors in space management can be incomplete. Typically
processing will continue for a few statements then an irrecoverable
error
occurs as per the following table:
Initial Error Condition
----------------------BPS FULL
PDS (pushdown stack) OVERFLOW
RESTORE after PDS OVERFLOW
FREE STORAGE EXHAUSTED during
load of a module
Subsequent Terminal Error
------------------------PSW loop
0C4
0C4
0C4
PSL SPECIFIC
--- -------* If one turns INT off from a terminal, the last numbered prompt is then
printed before every subsequent command.
* The definition of a macro leads to a message saying that the macro
name
is redefined.
* In principle, the DEL character can be used for interrupting a REDUCE
calculation and returning you to the top level. However, at present its
action is difficult to explain to the casual user. (For the reader
familiar
with LISP: DEL takes you back to the last active ERRORSET, and since
there
can be several of these between the point the calculation has reached
and
the top level, it's impossible to describe what just one DEL will do.)
However, a sequence of DEL's will eventually bring about the required
interrupt.
* At the moment, one cannot use EDITDEF on a function once it has been
traced (and even untraced later). This relates to the way in which PSL
stores the original definition of such functions.