there are a few more issues, like
length() or part calls ratdisrep if necessary. So selecting the
first part of a CRE can cascade into a time-consuming task.
I am of two minds as to whether a rational number should be
decomposable without the use of numerator and denominator
selectors. Do we also want to have floating point numbers
1.23d45 have 3 parts, namely 1, 23, and 45?
What other numbers are decomposable?
Using list operations on things that are not lists as such makes me
uncomfortable. At least compared to using selectors for operator and args
such that op(E) is sort of inpart(E,0) and args(E) is rest(E) as a list
Note that currently, args(1/2) is [1,2] rest(1/2) is a lisp error.
Regardless of setting inflag,
inpart(1/2,0) comes out "/".
My suggestion is to write in the documentation that for clarity, the user
should use args. Once on the expression. that way no repeated
ratdisreps, for example.
Then the equivalent of ?cadr with no checking except falling off the
end, is first, etc etc
But then args is the same as substinpart("[", E, 0).
Maybe makethat clear too.
Oh well.
RjF
, On 10/3/2013 10:37 AM, Stavros Macrakis wrote:
> 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 <mailto: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> <mailto: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> <mailto: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 <mailto:Maxima at math.utexas.edu>
> > > http://www.math.utexas.edu/mailman/listinfo/maxima
> > >
> > >
> >
> >
> >
>
>
>
>
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima