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> 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> 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> 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> 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
>
>