second(), third(), ...



Agreed that we should start by making everything consistent.

Not sure what you mean about op of an atom -- that is currently an error;
are you proposing something else?


On Thu, Oct 3, 2013 at 4:02 PM, Robert Dodier <robert.dodier at gmail.com>wrote:

> On 2013-10-03, Stavros Macrakis <macrakis at alum.mit.edu> 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....
>
> First and foremost let's make part / length / args etc consistent --
> that they all agree as to what's an atom and what's nonatomic, and
> that they can be described as being expressible in terms of each other
> (e.g. op is identical to part 0, and args is identical to part 1 through
> length of the expression; op of an atom is always the type of the atom,
> or never, but we choose one or the other; etc).
>
> Whether there are some minor use cases supported by such operations is
> a secondary question -- first of all let's make these operations
> predictable.
>
> best
>
> Robert Dodier
>
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>