MARRAYREF: fix an incorrectly constructed expression passed to ARRFIND
This is an ancient bug that was present in Macsyma.
When use_fast_arrays:false, MARRAYREF would pass an expression to
ARRFIND without the ARRAY flag in some cases. The header would
actually contain the symbol holding the array instead of the intended
ARRAY flag.
This bug affected various things, such as arrayapply, translated array
references and translated calls to subvar.
(%i1) array (a, complete, 5)$
(%i2) arrayapply (a, [3]);
(%o2) a(3)
No problems with the test suite or share test suite. New tests have
been added to rtest2 and rtest_translator.
170c6c1...
by
Robert Dodier <email address hidden>
Fix SF bug #3654 in eigen.mac a different way
(via local instead of (+foo)[i] workaround), essentially reverting commit a58e06
to eigen.mac and fixing it a different way.
This corrects a problem reported to the mailing list circa 2021-09-28,
that running run_testsuite(share_tests = true) reports that rtest_eigen
runs into a Maxima error ("cannot assign to" subscripted expression).
So the immediate problem is fixed, but the underlying problem is that
rules applied to MQAPPLY (as in rtest6 circa line 82) change the
way MQAPPLY expressions are simplified. I have opened a bug report,
SF #3870: "rules applied to MQAPPLY change default simplification"
Add alt_display functions for text, 1d and 2d output
In define_alt_display, define alt_display function so that output text
is automatically emitted by alt_display_text function; leave other
cases up to the function maker.
Add alt_display_text_prefix/suffix to customize the output of
alt_display_text.
Add an example, based on Eric Stemmler's requests, for multiple
printed output blocks.
Put the code that computes log10 and the code that fixes up bad format
output into their own flet so we can more easily change the
implementation if needed.
Add more comments as well, including an example of why we need the
fixup.
Curiously, the test makelist(sdowncase(sconcat(1.0*10^x)),x,-20,20)
expected incorrect results like 100.0e+7 instead of 1.0e+9. I've
updated these to be the correct values, even if eng format may not be
right. (But cmucl does get these all right.)
Due to round-off problems the computation of n = floor(log10(x)) where
x is the number to be printed is sometimes too small.
To solve this, we test if 10.0^n <= x < 10.0^n. If it fails, then the
exponent is too small by 1, so we increase n by 1. This takes care of
most cases.
However, that's not enough. Some lisps like ecl (20.4.24) end up
still printing a number that doesn't have the right exponent:
> (format t "~,v,,ve" 15 2 1d10)
100.00000000000000d+8
So we check that the printed exponent is a multiple of 3. If not, we
decrement the scale factor by 1 which seems to fix things. For ecl,
we get:
> (format t "~,v,,ve" 15 1 1d10)
10.000000000000000d+9
However, ccl64 1.12 on Linux, at least, is broken and we can't do
anything about it:
? (format t "~,v,,ve" 15 2 1d10)
10.00000000000000D+8
The printed result is off by a factor of 10; the exponent should be
9. Other lisps I tried (clisp, cmucl, gcl) print this correctly.
There may be other cases where things are wrong. I only used
