Re: [Matlisp-users] m.*! not native?

[Jefferson P. <jp...@cs...>]

I'm not sure.  The short answer is that I would love to have it better
optmized, but if it's not a priority for you guys, I understand.

I looked into optimizing it further myself, but I don't know enough about
the lisp optimization to proceed.  I managed to get around it by changing my
algorithm so I don't need to call it as often, but that solution may be
sub-optimal for me in the long run.

However, I may end up reimplementing my stuff in C++ (with Guile bindings)
for other reasons.  I'm not sure...

Jeff



On 6/13/02 11:21 AM, "Raymond Toy" <to...@rt...> wrote:

>>>>>> "Tunc" == Tunc Simsek <si...@ee...> writes:
> 
>   Tunc> Hi Ray, Jefferson;
>   Tunc> I've played with Allegro 6.0 as follows (I asked it to explain
>   Tunc>  the compilation of m.*!):
> 
>   Tunc> (defmethod m.*! ((a real-matrix) (b real-matrix))
>   Tunc>   (let* ((nxm (number-of-elements b)))
>   Tunc>     (declare (type fixnum nxm)
>   Tunc>          (optimize (speed 3) (safety 0)))
> 
>   Tunc>     (dotimes (k nxm b)
>   Tunc>       (declare (type fixnum k))
>   Tunc>       (let ((a-val (matrix-ref a k))
>   Tunc>         (b-val (matrix-ref b k)))
>   Tunc>     (declare (type real-matrix-element-type a-val b-val)
>   Tunc>          (:explain :calls :types :boxing))
>   Tunc>     (setf (matrix-ref b k) (* a-val b-val))))))
> 
> Jefferson, do you still need this optimized?   I think Tunc's version
> is good enough when both matrices are real.  The complex-valued
> versions need to be done.
> 
> Ray
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -
> http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink
> 
> _______________________________________________
> Matlisp-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matlisp-users
>