Each is useful, but in different cases:
Part is good interactively. You'd like to think of (a*b)/(c*d) as having a
numerator and a denominator, not as the length-4 multiplication
a*b*c^-1*d^-1.
Inpart is good programmatically.
But...
Distinguishing the inpart case with inflag for length/op is ugly.
Things like append(a/b,c*d), append(-a,-b), and reverse(1/b) are just
perverse (though arguably consistent), and I find it hard to believe that
they're useful to anyone.
-s
On Thu, Oct 3, 2013 at 2:51 PM, John Lapeyre <lapeyre.math122a at gmail.com>wrote:
>
> On 10/03/2013 08:28 PM, Stavros Macrakis wrote:
> > Maxima has supported length/first/rest etc. on non-lists forever. It may
> be a bad idea, but it is an old bad idea. The (potentially huge ***)
> overhead of reformatting with nformat is certainly an argument against it,
> but it is also an argument against using op/part/args with inflag=false.
> >
> > With inpart=false, treating the rational number 2/3 as different from
> the division a/3 is just torturing the poor user, who reasonably expects
> consistency. Functions like part are supposed to reflect the external form
> of the expression; after all, neither 2/3 ((rat) 2 3) nor a/3 ((mtimes) $a
> ((mexpt) 3 -1)) has op=mquotient internally.
> >
> > As for floats, TeX and wxMaxima do display them as 1.23*10^45, so it
> would make sense to treat decompose them that way; but other platforms
> don't....
> >
> > -s
> >
> > *** nformat reformats the whole expression (CRE or not), even if you're
> only looking at the top-level op; it would be a big efficiency gain if
> op/part/args/first/length only reformatted as much as necessary. But to do
> this well, the code for the incremental version and the batch version would
> have to be shared, to avoid divergent behavior.
> >
>
> I don't like the inpart flag idea. It would be so much easier to
> have inpart:true always, as with Mathematica. I don't think it causes
> problems for users there. In fact inpart and domain add confusion
> for me as both a user and hacker. I suppose that's a matter of
> taste, or better something to be tested by an experiment with
> a large number of users (not likely)
>
> Why should rationals be decomposable expressions, when other numbers
> are not? But isn't it too late?... unless one wants to have a new
> maxima version that breaks backwards compatibility.
>
> But what about complex numbers? They appear
> to be atoms in Mathematica.
>
> In Maxima, %i is, for some purposes, just another symbol
>
> a : %i + 7*%i + a + 4; --> a+24*%i+15
>
> You can get everything with part(), which is convenient.
>
> In Mathematica, the complex numbers are always formed as atoms and you
> can't get at the parts, except with Real, Imaginary.
>
> One could maybe change Maxima to do this, but it would be
> a huge project, and break compatibility, at least as much as
> with rationals.
>
>
> >
> > On Thu, Oct 3, 2013 at 2:07 PM, Richard Fateman <fateman at gmail.com><fateman at gmail.com>wrote:
> >
> > 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> <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
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Maxima mailing list
> >> Maxima at math.utexas.edu
> >> http://www.math.utexas.edu/mailman/listinfo/maxima
> >
> >
>
>
>