Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
Bart Lateur [EMAIL PROTECTED] writes: On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote: @foo = @bar * @baz; Given that the default action of the multiply routine for an array in non-scalar context would be to die, allowing user-overrides of the functions would probably be a good idea... :) [Is this still -internals? Or should we stop CC'ing?] One problem: overloading requires objects, or at least one. Objects are (currently) scalars. You can't make an array into an object. We are thinking of adding "objects" in the implementation of perl. i.e. perl's primitive "things" (scalars, arrays, hashes) will have 'vtables' (table of functions that do the work). So in that sense an array as in @foo can be an "object" at some level of meaning while not being an "object" at the perl level. -- Nick Ing-Simmons
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
At 04:06 PM 8/9/00 +, Ed Mills wrote: In keeping with Larry's design philosophy that the language should "not just sit there -do something!" I agree that there should be a number of vector/matrix manipulations available, performed in a psuedo-scalar context (not in a loop). That would be list context. (Or perhaps array or hash context, and yes I know we don't have those right now) Just to name a few: [Snip] etc. etc. This kind of functionality would attract a whole new category of users from mathematics and other areas, as well as giving us optimized solutions to operations that many of us do regularly in loop contexts. I expect it would make other things interesting as well, not just math things. (Running a substitution on an array would be keen, for example) On the other hand one can argue all of these belong in CPAN under a matrix:: library or something like that, but to me if would make Perl a powertool to build these kinds of functions into the language syntax. In many cases these can be treated as overloading scalar ops for a non-scalar context. While I'm firmly of the opinion the code to actually Do Something should be elsewhere (at least to start), support definitely needs to be in the core to notice what that something is--you won't get very far with: @a * @b if perl does a scalar on both arrays before doing the multiplication... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
At 11:13 PM 8/9/00 +0200, Bart Lateur wrote: On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote: @foo = @bar * @baz; Given that the default action of the multiply routine for an array in non-scalar context would be to die, allowing user-overrides of the functions would probably be a good idea... :) [Is this still -internals? Or should we stop CC'ing?] Nope, and we should stop. One problem: overloading requires objects, or at least one. Objects are (currently) scalars. You can't make an array into an object. s/object\./object right now./; If the current plan goes through, arrays and hashes will be typeable, and therefore overloadable. (Think of it as a lightweight object--no method calls, just overloading) but a problem is: @copy = @ary; which only copies the items by value, as a list, and thus ignores the blessing. @copy is a plain array. Well... What happens depends on the type of @copy, and what we decide to do with whole-container assignments. It's reasonable to make @copy the same type as @ary. And if @copy's not a generic scalar array (and is, instead, an integer array, say) some sort of conversion might take place. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
Bart Lateur wrote: If you're talking about matrix manipulations, I should immediately hold you back. Perl arrays are pretty bad as is for representing matrices. Don't let anybody tell you otherwise: Perl data structures are one-dimensionaly by nature. A lazily evaluated slicing operator would make arrays look like matrices and tensors (an RFC for this should be appearing RSN). Of course this would have to be implemented efficiently by Perl, which Dan has already talked about doing. For vector manipulation, I can understand that, *in principle*, but not really. I remember that a few functional language extensions have been proposed, including "apply a function (code block) to each combination of item i from the first list with item i of the second list, for each i". You can easily roll your own. It will do what you want, not what the implementors thought useful. For example: vector multiplication. What will @foo*@bar do? Will it return the scalar product (abs(@foo)*abs(@bar)*cos(angle), the vector product (returning a vector orthogonal to both others), or a matrix multiplication? If you roll your own, you can choose. It should provide a component-wise multiplication by default. This would provide consistency amongst all operators applied to a list in list context (and many functions could provide this behaviour too--like chomp(), as Bryan Warnock mentioned earlier). 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...
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
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/6/; $a = scalar @b x scalar @c; # $a = 6; 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])
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
Bryan C.Warnock wrote: 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.) Actually, I think we're in agreement (this comment about 'x' was really an aside--I'm not proposing about putting that into the core... just make sure we can overload it). ... 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. Exactly. Let's make sure that: - ...'@a op @b' in a list context always does a component-wise operation - ...that this can be overload - ...that Perl functions in a list context apply themselves to each element of the list (where it makes sense for them to do so) I'm happy to expand this into an RFC, if there's no major objections. 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. I think that's OK. Perl should like like Perl, not like Mathematica. But we can still provide the power of the notation and inlined calculations. It's like when Perl OO was introduced in Perl 5--it didn't look much like OO to C++ programmers, but it was Perlish, and it was OO.
vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
On Wed, 09 Aug 2000 09:41:22 -0400, Dan Sugalski wrote:
@foo = @bar * 12;
@foo = map { $_ * 12 } @bar;
I don't see the need for a new notation.
Well, compactness for one. With a scalar on one side it's less odd (it was
a bad example). When funkier, though:
@foo = @bar * @baz;
the expansion becomes less obvious and quite a bit larger, especially if
the arrays are multidimensional.
(Isn't this becoming a "language" issue? -language CC'ed.)
If you're talking about matrix manipulations, I should immediately hold
you back. Perl arrays are pretty bad as is for representing matrices.
Don't let anybody tell you otherwise: Perl data structures are
one-dimensionaly by nature.
For vector manipulation, I can understand that, *in principle*, but not
really. I remember that a few functional language extensions have been
proposed, including "apply a function (code block) to each combination
of item i from the first list with item i of the second list, for each
i". You can easily roll your own. It will do what you want, not what the
implementors thought useful. For example: vector multiplication. What
will @foo*@bar do? Will it return the scalar product
(abs(@foo)*abs(@bar)*cos(angle), the vector product (returning a vector
orthogonal to both others), or a matrix multiplication? If you roll your
own, you can choose.
No, I am more in favor of solid yet flexible overloading mechanism, so
that you can use the appropriate module, which does the multiplication
of your choice, and which still allows you to use something like the
above notation. $foo and $bar will then be (vector or matrix) objects,
instead of plain Perl arrays. Much like BigInt now.
--
Bart.
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
On Wed, 09 Aug 2000 12:46:32 -0400, Dan Sugalski wrote: @foo = @bar * @baz; Given that the default action of the multiply routine for an array in non-scalar context would be to die, allowing user-overrides of the functions would probably be a good idea... :) [Is this still -internals? Or should we stop CC'ing?] One problem: overloading requires objects, or at least one. Objects are (currently) scalars. You can't make an array into an object. Well, you can try: bless \@ary, 'Vector'; print ref \@ary; which says: Vector so you COULD get there in the end. A nicer syntax would be along the proposed syntax of my Vector @ary; but a problem is: @copy = @ary; which only copies the items by value, as a list, and thus ignores the blessing. @copy is a plain array. -- Bart.
Re: vector and matrix calculations in core? (was: Re: Ramblings on base class for SV etc.)
At 05:39 PM 8/9/00 +0200, Bart Lateur wrote:
On Wed, 09 Aug 2000 09:41:22 -0400, Dan Sugalski wrote:
@foo = @bar * 12;
@foo = map { $_ * 12 } @bar;
I don't see the need for a new notation.
Well, compactness for one. With a scalar on one side it's less odd (it was
a bad example). When funkier, though:
@foo = @bar * @baz;
the expansion becomes less obvious and quite a bit larger, especially if
the arrays are multidimensional.
(Isn't this becoming a "language" issue? -language CC'ed.)
Good call.
If you're talking about matrix manipulations, I should immediately hold
you back. Perl arrays are pretty bad as is for representing matrices.
Don't let anybody tell you otherwise: Perl data structures are
one-dimensionaly by nature.
That doesn't necessarily have to remain the case.
For vector manipulation, I can understand that, *in principle*, but not
really. I remember that a few functional language extensions have been
proposed, including "apply a function (code block) to each combination
of item i from the first list with item i of the second list, for each
i". You can easily roll your own. It will do what you want, not what the
implementors thought useful. For example: vector multiplication. What
will @foo*@bar do? Will it return the scalar product
(abs(@foo)*abs(@bar)*cos(angle), the vector product (returning a vector
orthogonal to both others), or a matrix multiplication? If you roll your
own, you can choose.
Choosing is a good thing, yep.
No, I am more in favor of solid yet flexible overloading mechanism, so
that you can use the appropriate module, which does the multiplication
of your choice, and which still allows you to use something like the
above notation. $foo and $bar will then be (vector or matrix) objects,
instead of plain Perl arrays. Much like BigInt now.
Given that the default action of the multiply routine for an array in
non-scalar context would be to die, allowing user-overrides of the
functions would probably be a good idea... :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
