array questions



>>>>> "Camm" == Camm Maguire <camm at enhanced.com> writes:

    Camm> Greetings!
    Camm> Raymond Toy <raymond.toy at ericsson.com> writes:

    >> >>>>> "Camm" == Camm Maguire <camm at enhanced.com> writes:
    >> 
    Camm> Well, certain compiler optimizations are keyed to the 'array symbol.
    Camm> For example, all typing.  subtypep cannot deal with `(maxima::array
    Camm> fixnum *), it appears as an unknown type.
    >> 
    >> If maxima code does that and it's really a Lisp array, the code is
    >> probably wrong and should read cl:array instead.  We should fix
    >> these. 
    >> 

    Camm> OK, I can provide some eg. if helpful.

That would be helpful.  I'm pretty sure plot.lisp had this problem,
but I think those are fixed.

    >> This would make it significantly worse for cmucl and sbcl because the
    >> declaration is saying it's an array of unknown dimensions.  You might
    >> want to do
    >> 
    >> (aref (the (lisp::array ,ign ,(length dims)) ,array) . ,dims)),
    >> 

    Camm> This would be ok too.

    >> but that could still hurt cmucl/sbcl if the compiler actually knew the
    >> type of ,array before hand.  Say, for example that the array was
    >> actually a 1D simple-array of double-floats, with a known length.
    >> 

    Camm> Well, then the code should be in error (i.e. the arraycall
    Camm> invocation), no?  GCL doesn't need this necessarily either when the

I don't think so because a simple-array is a subtype of array.  But
the compiler will believe you and assume it is an array and not a
simple-array, and be forced to do a general array access instead of a
simple-array access.

    Camm> array is a lexical produced by make-array or the like, but there are
    Camm> several special variables with array bindings which are not declaimed:
    Camm> e.g. factor.lisp:

    Camm> (declare-top(special afixn fctcfixn invcfixn))

>From looking at factor.lisp, I think the right thing would be to
either use CL arrays and forget about arraycall or to leave arraycall
as is and declare them at the point of use.  But to get any real
improvement, the code probably has to be restructured because afixn
and friends are bound to NIL for some time before they're given an
array value.

Restructuring is good, but I wouldn't do it unless I had hard numbers
indicating that the use of afixn and friends was the actual
bottleneck.

Ray