Re: is/equal for lists/matrices -- design note

Hello Stavros,

you wrote, in part:

> I do agree that 1==[2] and matrix([1,2,3],[4,5,6]) == 
> matrix([1,2],[3,4],[5,6]) and [1,2]==[1,2,3]
> can't be true under any reasonable interpretation, and that
> compar-patch doesn't handle those cases.  But I decided it 
> wasn't worth the trouble to code cases like that in the 
> absence of a coherent design which resolves the 
> truth/false/unknown status of 1==[1] and
> [1,2]==matrix([1,2])==matrix([1],[2]).

Well, my recommendation here is go ahead and return FALSE for
such cases. Ideally IS(EQUAL) would return TRUE or FALSE for
all comparable objects. Returning FALSE for cases as above 
gets us closer to that goal.

> I suppose we could simply decide pragmatically that 1 /= [1], that
> [1,2] == matrix([1],[2]) but /= matrix([1,2]), even though [1,2] 
> sometimes functions as a row matrix.  Or perhaps [] and matrix
> should never be ==? If that is the answer, that is easy enough
> to program, and I can do it.

I'd recommend instead that we cut down on questions raised by
type conversions, by having fewer user-level types (hiding
the programming types). I know this is a long-term project, at best.

[...]

> It don't think it would be hard to define memory arrays as
> a 'hint' on abstract arrays, though there are a few semantic issues.
> For example, Maxima's object semantics for matrices are not quite
> limpid. [...]

Hmm, it's hard to see what's the right behavior in the examples
you cited. I would guess that in general matrices should
work the same as, say, real or complex variables -- however these
act w.r.t. assignment, so should matrices. I have no idea if that's
desirable, feasible, or a fait accompli.

> And I suppose you could define matrices as lists-of-lists 
> constrained to be squared off (not ragged) -- but how do you
> express the constraint? 

Well, at present the MATRIX function looks at its arguments to
see if they're all the same length and barfs if they aren't.
Instead, when a list is constructed, it could be examined to
see if it "looks like a matrix" and a flag turned on if it does.
Then functions which want to see a matrix can check the flag.

What I'm getting at is that the user can construct whatever
they want. Whether that something can be used as if it were
a matrix, we can put off til it really matters.

> And it does seem ad hoc that they can be ragged in one 
> dimension, but not the other.  That is, what is the value of 
> transpose([1,[2,3]])?

Well, it's the list L2 such that L2[i][j] = L1[j][i] where L1
is the original list. That's well defined, is it not?

If implementation is a hassle, we can have transpose barf on 
ragged lists -- such a policy certainly has precedent.

> If they can be ragged at the right and the bottom, why not
> the left and the top?  Why not arbitrarily sparse? [...]

Sure, why not? I'm all for it. 

For what it's worth,
Robert Dodier

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/