I agree that it matters for rest(). Even better if the translator could
keep lists in Lisp form internally when possible, avoiding the cons of
(mlist simp) every time you call rest.... Doesn't sound trivial, but I
haven't looked at the internals.
-s
On Thu, Oct 3, 2013 at 1:24 PM, John Lapeyre <lapeyre.math122a at gmail.com>wrote:
> On 10/03/2013 05:25 PM, Stavros Macrakis wrote:
> > Just to be clear, I think it's a perfectly sensible implementation, but
> I think that there are other areas where Maxima could benefit much more
> from your talents. After all, second/third/etc. (as opposed to first) are
> almost always called on very short lists (e.g. argument lists, the value of
> arrayinfo, etc.).
> >
> > The 'translate' module, in particular, needs work. It has bugs, it often
> produces inefficient code, etc.
>
> I saw it by chance and made the quick change.
> Yes, improving the translator would be great.
>
> By the way, rest() has the same problem, it computes the length of the
> input expression. This might be more significant. I fixed it for
> myself and saw the expected O(n) speed-up for long lists (did not try
> on other expressions).
>
>
>
> >
> > -s
> >
> >
> >
> > On Thu, Oct 3, 2013 at 10:39 AM, John Lapeyre
> <lapeyre.math122a at gmail.com> <lapeyre.math122a at gmail.com> wrote:
> >
> > On 10/03/2013 02:33 PM, Stavros Macrakis wrote:
> > > Thanks for the improvement. I don't think you need to publish changes
> like this to the whole mailing list. This is an optimization which doesn't
> change the black-box behavior of the function.
> > >
> > > But since you have published it, I'll comment on it...: It's probably
> not worth your while to make nano-optimizations like this. Though having
> 'first' be fast on long lists (which it already is) is probably somewhat
> useful, saving 5mS on second(<long list>) is unlikely to matter to any real
> program.
> >
> > Maybe attaching a patch to a wishlist bug report (or low level bug or
> > whatever) is more appropriate? I'd be happy to take that approach.
> >
> > Now that I think about it: A while ago, I published a limit for a
> > special function. There's not much to talk about there. I could have
> > sent that via the bug page. But, I looked at the list and saw that
> > others had published patches, so I went ahead.
> >
> > But in the case at hand, I know that people have very different
> > opinions on optimization. So maybe it's useful for the
> > proposal to be visible.
> >
> > --John
> >
> >
> > >
> > > -s
> > >
> > >
> > > On Thu, Oct 3, 2013 at 5:19 AM, John Lapeyre
> <lapeyre.math122a at gmail.com> <lapeyre.math122a at gmail.com> wrote:
> > >
> > > Greetings,
> > >
> > > second(), third(), etc. traverse the entire expression. But, they
> > > don't need to. Here is a change that fixes that.
> > >
> > > Example:
> > >
> > > a:create_list(i,i,1,10^6)$
> > >
> > > before change:
> > >
> > > for i:1 thru 100 do second(a);
> > > Evaluation took 0.4900 seconds (0.4860 elapsed)
> > >
> > > after change:
> > >
> > > for i:1 thru 100 do second(a);
> > > Evaluation took 0.0000 seconds (0.0000 elapsed)
> > >
> > > If it is decided that it should be applied, I can
> > > make the patch. But someone else can do it, too.
> > > Note especially that
> > > (make-nth second 2)
> > > was changed to
> > > (make-nth second 1), etc.
> > >
> > > --------
> > >
> > > (macrolet ((make-nth (si i)
> > > (let ((sim (intern (concatenate 'string "$" (symbol-name si)))))
> > > `(defmfun ,sim (e)
> > > (atomchk (setq e (format1 e)) ',sim nil)
> > > (handler-case
> > > (elt (margs e) ,i)
> > > (error ()
> > > (merror (intl:gettext "~:M: no such element in ~M") ',sim e)))))))
> > > ; (if (< (length (margs e)) ,i)
> > > ; (merror (intl:gettext "~:M: no such element in ~M") ',sim e))
> > > ; (,si (margs e))))))
> > >
> > > (make-nth second 1)
> > > (make-nth third 2)
> > > (make-nth fourth 3)
> > > (make-nth fifth 4)
> > > (make-nth sixth 5)
> > > (make-nth seventh 6)
> > > (make-nth eighth 7)
> > > (make-nth ninth 8)
> > > (make-nth tenth 9))
> > >
> > > _______________________________________________
> > > Maxima mailing list
> > > Maxima at math.utexas.edu
> > > http://www.math.utexas.edu/mailman/listinfo/maxima
> > >
> > >
> >
> >
> >
>
>
>