I agree. To be consistent with part, with inpart:false, length(-1/4)
should be 1; length(1/4) should be 2. I would hope that that doesn't break
any user's code, but it's hard to know....
By the way, I'd suggest that when you discuss changes like this, you *
explicitly* describe the proposed new behavior at the Maxima level (as I
did above) rather than document the old behavior and the code change.
-s
On Thu, Oct 3, 2013 at 6:45 AM, John Lapeyre <lapeyre.math122a at gmail.com>wrote:
> Greetings:
>
> I've mentioned this a couple of times, but now I've made a change
> for my own use. As usual, I can make a patch and send it
> if anyone is interested in checking it out.
>
> It seems to me that length(), part(), are meant to work together
> conceptually (or were at some point in the past). (I'm not saying it
> is a good or bad idea, it just seems to be that way.)
>
> So, if length(expr) is n, then I can operate on,
> or access parts 0 through n. But I've seen only one case where
> this rule is not followed. (There may be more.)
>
> ------------------------------**---------------------
> (%i1) inflag;
> (%o1) false
> (%i2) length(-1/4);
> (%o2) 2
> (%i3) part(-1/4,2);
>
> part: fell off the end.
> -- an error. To debug this try: debugmode(true);
> ------------------------------**---------------------
>
> The change is to this line in the definition of length()
> in comm.lisp
>
> ((or $inflag (and (not (member (caar e) '(mtimes mexpt) :test #'eq))
> (not (and (eq 'rat (caar e)) (< (cadr e) 0))))) (length (margs e)))
>
> --John
>
> ______________________________**_________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/**mailman/listinfo/maxima<http://www.math.utexas.edu/mailman/listinfo/maxima>;
>