On 9/22/2013 12:05 PM, Robert Dodier wrote:
> On 2013-09-22, John Lapeyre <lapeyre.math122a at gmail.com> wrote:
>
>> (%i1) tex(make_array(fixnum,2));
>> $$
>> Maxima encountered a Lisp error:
>>
>> The value #(0 0) is not of type SYMBOL.
>
OK, I looked at this some more. This does not seem to be only a tex()
error, but a
design disagreement
about how to format the result of make_array.
For instance, for h:make_array(any, 2) wxmaxima says
Lisp array [2]
but command line maxima says
{Lisp Array: #(nil nil )}
you can change elements e.g. h[1]:x^2,
and then wxmaxima still says Lisp array [2]
but command line says (nil ((mexpt simp) $x 2))
which is not cool.
It appears to me that what needs to be changed is
(a) the format program in file nformat.lisp
(b) corresponding changes (unless $tex calls format, which it might for
mysterious cases) in the tex program.
If it doesn't happen now, it may be advantageous to patch tex so that in
cases
that it really doesn't understand, it runs stuff through format() and
tries again.
I suggest one solution would be to display near the line number some
indication that an object is a Lisp Array, and then format/display it as
though it were a vector, a matrix, or whatever we might do for n>2
dimensions.
e.g.
(%o7) /lisp array/ 1 2
3 4
Alternatively, I suppose we could use the wxmaxima style: the
mysterious Lisp Array [2]
and point out in documentation that to see the elements, one should
write
for i:0 thru 1 do display(h[i]). Which prints...
h[0]=0
h[1]=0
But then length(h) should return 2.
not a lisp error, the current behavior. What, though, is the length of
make_array(any, 2,3) ?
perhaps [2,3] ?
Cheers
RJF