Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
[EMAIL PROTECTED] wrote: I disagree. You end up with a situation where some @a * @b; are in scalar context, some not. No, everything would be in a scalar context. If you used tie() to specially tie a variable, then you might be able to overload +, *, -, etc, but this is no different from overloading other objects, which you can do currently. And what happens when you say @a = (1,2,2); @b = tie Matrix (1,2,3); @a*@b; Who wins? There are already well-established precedence rules on operator overloading; check out the Camel-3 chapter on it. The methods proposed in RFC 159 would follow these same rules, although this should probably be explicitly stated in the RFC. -Nate
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
Nathan Torkington wrote:
Actually, the only refinement I'd like to see is that boolean operators
(==, , ||) be excepted from the distributive rule.
This is to permit:
if (@a == @b) # shallow comparison
and
@a = @b || @c;# @a=@b or @a=@c; # ish
Yeah, I agree completely with this sentiment. This is far more useful to
me than having them element-wise.
My main fear is that while this RFC seems really good for math ops, but
seems too array- and PDL-specific. Here are some examples of mixed
contexts; how would these be handled under the RFC?
@user_data = @empty || $user;
%files = scalar(get_files()) || @DEFAULT;
$total = @items + $MIN_VALUE;
@full_names = @first_names . "Smith";
What I'd like to see is Perl to really DWIM (especially in that last
one). But to do so you have to redo the rules of the RFC:
Op Type Default homogenous context Mixed context
--- --
--
Math opselement-wise forced to scalar
Boolean ops whole entity forced to list
String ops element-wise forced to list
With these rules, the above examples now work as I'd expect (or at least
want) them to:
@user_data = @empty || $user; # @user_data =
($user);
%files = scalar(get_files()) || @DEFAULT; # %files =
(@DEFAULT);
$total = @items + $MIN_VALUE; # $total = 5 + 2;
@full_names = @first_names . "Smith"; # @full_names = ("Bob
Smith", "Jim Smith");
True, this opens a whole other can of worms, but I think it's closer to
what people would want to use the ops for, and it's also more usable to
us non-PDLers. Note there's a lot of inherent want()-like behavior built
in there.
-Nate
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
Nathan Torkington wrote: Jeremy Howard writes: No, there's no arbitrary decision. *Every* operator is component wise on lists. It is internally consistent, and consistent with most other languages that provide array/list operators. It's easy to get stuck on the '*' example, because different mathematicians have different feelings about what matrix operation should map to '*'. However, there is no consistant and meaningful definition of array operations (for _all_ operators) other than that defined in RFC 82. Actually, the only refinement I'd like to see is that boolean operators (==, , ||) be excepted from the distributive rule. This is to permit: if (@a == @b) # shallow comparison Already works under the RFC (scalar context). and @a = @b || @c; # @a=@b or @a=@c; # ish Doesn't work in P5 (try it!) The math operations are fine to apply to each element. I have no problem with those being distributive, but I think || for default values and == for comparison are too ingrained and they'd be too useful (as opposed to a distributive || or , which is much less useful). == is applied in a scalar context--fine. || as you show it can not be ingrained because it doesn't currently work this way!
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
"NT" == Nathan Torkington [EMAIL PROTECTED] writes: NT Actually, the only refinement I'd like to see is that boolean operators NT (==, , ||) be excepted from the distributive rule. NT This is to permit: NT if (@a == @b) # shallow comparison NT and NT @a = @b || @c;# @a=@b or @a=@c; # ish NT The math operations are fine to apply to each element. I have no NT problem with those being distributive, but I think || for default NT values and == for comparison are too ingrained and they'd be too NT useful (as opposed to a distributive || or , which is much less NT useful). Then how would one get the distributed effect? An apply operator? chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
Nathan Wiger wrote: what people would want to use the ops for, and it's also more usable to us non-PDLers. I'd like to suggest that it is not a very good idea to start dividing the world into PDLers and non-PDLers. There are a multitude of reasons but I am not keen to go into details. Christian
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
Nathan Wiger wrote: This RFC proposes that operators in a list context should be applied element-wise to the elements of their arguments: @d = @b * @c; # Returns (2,8,18) If the lists are not of equal length, an error is raised. I've been watching this RFC for a while. I would hesitate to change the default behavior of * and other operators in so radical a sense, especially since it would create unexpected error conditions. I think these operations should remain scalar. I disagree. You end up with a situation where some @a * @b; are in scalar context, some not. And what happens when you say @a = (1,2,2); @b = tie Matrix (1,2,3); @a*@b; Who wins? From the user point of view a 1D multi-dim array will look just the same as a normal perl list in *all* respects in a would-be perl6. I bet money that users will be highly confused if some arrays enforce scalar context in such operations, others don't. It is *much* clearer to have a clear break with perl5 in this respect (even if code needs to be rewritten). A p52p6 could replace all occurences of @a*@b with scalar(@a)*scalar(@b). Christian
Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context
[EMAIL PROTECTED] Nathan Wiger wrote: This RFC proposes that operators in a list context should be applied element-wise to the elements of their arguments: @d = @b * @c; # Returns (2,8,18) If the lists are not of equal length, an error is raised. I've been watching this RFC for a while. I would hesitate to change the default behavior of * and other operators in so radical a sense, especially since it would create unexpected error conditions. I think these operations should remain scalar. I disagree. So do I. ... The idea would be operator and data overloading is completely integrated with tie, based on the concept of polymorphic objects. As such, you could create native PDL classes that would allow @a * @b to do what you want. Not only do you lose consistency here (as Christian already pointed out), but also speed. Array functions and operations would be tightly optimised loops, and furthermore multiple operations would avoid redundant loops and copies. Good luck finding a way of getting Ctie to do this, RFC 200 notwithstanding. Otherwise, you have to decide if @a * @b should be element-wise, a cross-product, a vector, or ??? I just think it's a can of worms that's going to result in a set of arbitrary decisions, which in the the end makes less sense than having these contexts remain scalar by default. No, there's no arbitrary decision. *Every* operator is component wise on lists. It is internally consistent, and consistent with most other languages that provide array/list operators. It's easy to get stuck on the '*' example, because different mathematicians have different feelings about what matrix operation should map to '*'. However, there is no consistant and meaningful definition of array operations (for _all_ operators) other than that defined in RFC 82. This RFC is absolutely fundamental to providing numeric programming capabilities in Perl 6, and it happens to make a lot of other stuff simpler besides (e.g. the text processing examples in the RFC). It would improve the speed and clarity of code, and Perl 5 scripts can be converted with a simple Cscalar. I can't really see the argument for not doing this.
