On Wed, 09 Aug 2000, Jeremy Howard wrote:
> Of course, if the user wants to overload this behaviour, we should let them.
> In the multiplication example, however, I would have thought that 'x' is a
> more suitable inner product operator...
And that seems to be where most of the critics of non-scalar arithmetic
and operator overloading have most of the problems. (Provided, of
course, that you're limited to operator overloading and not operator
creation, as I believe Smalltalk allows.)
DWIM is hardly ever DWYM.
For instance, two common uses for arrays are as vectors and sets - but
the operations for vectors and sets aren't congruent, and oftentimes
the cleanest symbology - given a limited set of symbols - will give
someone fits if applied to the wrong framework. And that's with each
other. There's also classic Perl to consider.
@b = qw/a b c d e f/; @c = qw/1 2 3 4 5/;
@a = @b . @c;
$a = @b . @c;
@a = @b x @c;
$a = @b x @c;
Not knowing what @b and @c really are to represent, what would the most
logic interpretation of the above statements be?
To the Perl purist (looking for parallel operations between scalars and
arrays), this could conceivably be the same as the following real Perl
expressions.
@a = (@b, @c); # @a = qw/a b c d e f 1 2 3 4 5/;
$a = scalar (@b, @c); # $a = 11;
@a = (@b) x scalar @c; # @a = qw/a b c d e f a b c d e f a b ..... f/;
$a = scalar ((@b) x scalar @c); # $a = 30;
But they're not. Which makes sense, if you know Perl, but doesn't (er,
may not), if you don't.
Instead, they're the same as this:
@a = ((scalar @b) . (scalar @c)); # @a = qw/65/;
$a = scalar @b . scalar @c; # $a = 65;
@a = (scalar @b x scalar @c); # @a = qw/66666/;
$a = scalar @b x scalar @c; # $a = 66666;
Of course, to someone trying to doing inner and outer products, or
union and intersection, none of the above are correct. (Yes, & and |
are probably better symbols for U and upside-down U. But you get the
drift.)
Perl could probably get away with better defining a strict (and
consistent) set of operations of vectors (vectors in a CS sense of the
word, vice a strictly math sense of the word) that behaved in a Perlish
way, and not necessary a mathematical way, but I think matrix
manipulation unadorned in bare Perl code will be difficult to make
consistent with the rest of the language, or even accurately
represented.
I like the work that PDL has done, and would like to see a way to make
(at least simple) matrix calculations more inline, but it may end up
too counter-intuitive (or obtrusive) to programmers using lists and
arrays in another context.
Hmm, maybe I should have changed the subject back to rambling....
--
Bryan C. Warnock
([EMAIL PROTECTED])
