matrix implementation, was: patch for $addrow needed?

I suggest that anyone proposing to change this admittedly messy
situation look at the corresponding situations in Maple, Mathematica,
and commercial Macsyma.  If were easy to clean this up,
you would think that one of them would have done so.  
I suspect, though I am not sure, that these other programs have
similar (messy) semantics.
RJF

----- Original Message ----- 
From: "Stavros Macrakis" <macrakis at gmail.com>
To: "Robert Dodier" <robert.dodier at gmail.com>
Cc: <Maxima at math.utexas.edu>
Sent: Friday, April 21, 2006 8:30 AM
Subject: Re: [Maxima] matrix implementation, was: patch for $addrow needed?


>> I'm quite optimistic that we can clean up messy stuff
>> in Maxima. We have a lot of talented developers and
>> there are a lot of interested outsiders.
> 
> I certainly agree that it would be a *good thing* to clean up messy
> stuff. Some of that is fairly straightforward -- e.g. make sure that
> all functions treat CREs and aggregates (lists and sets) in reasonable
> ways.  In this particular case, the issue is not just implementation;
> it is mostly specification.
> 
>> There are some simple things we can do right away.
>> Specifically addrow should copy its input data.
>> There may be a couple of other functions which can be
>> fixed in a similar way.
> 
> That may well be a reasonable specification.  But I disagree with your
> characterization of it as a "fix", as though the current behavior were
> a bug.  The proposed behavior is different, and perhaps better, but
> not a "fix".
> 
>> > I am not sure what the right answer is, but I hope I've shown that
>> > "just" making everything immutable, or "just" using deep value copies
>> > rather than reference
>>
>> I haven't advocated immutable objects, and I don't
>> think deep copy implies immutable, so I don't understand
>> why you're arguing against immutable objects.
> 
> If I understood the earlier emails correctly, there were two
> alternatives being proposed: immutability and deep-copy.  I did not
> say that one implies the other.  In fact, quite the contrary: I said
> that immutability would make deep-copy unnecessary, and vice versa.
> 
> The goal was apparently to avoid the situation where assigning to part
> of one list or array changes the value of another list or array
> (anti-aliasing).  My main problem with that is that side-effect
> semantics may be *desirable*, at least for some applications.  My
> secondary problem is that it is not clear how you would implement both
> mutable arrays (where you can modify elements or subarrays) and
> anti-aliasing in an efficient way.
> 
>> As an implementation detail, I would certainly want to
>> optimize copy semantics so that the copying happens only
>> when needed. This addresses efficiency problems
>> to some extent.
> 
> Well, let's hear your proposals for (a) the user-visible semantics you
> want and (b) the efficient implementation mechanism to support them.
> 
>            -s
> 
> _______________________________________________
> Maxima mailing list
> Maxima at math.utexas.edu
> http://www.math.utexas.edu/mailman/listinfo/maxima
>