[Python-ideas] Respectively and its unpacking sentence

Wed Jan 27 13:13:18 EST 2016

On Jan 27, 2016, at 09:12, Mirmojtaba Gharibi <mojtaba.gharibi at gmail.com> wrote:
> 
> 
> I think the component-wise operation is the biggest benefit and a more compact and understandable syntax. 
> For example, 
> 
> innerProduct = sum(map(operator.mul, a, b))
> is much more complex than
> innerProduct += $a * $b
> 
> MATLAB has a built-in easy way of achieving component-wise operation and I think Python would benefit from that without use of libraries such as numpy.

Why? What's wrong with using numpy?

It seems like only problem in your initial post was that you thought numpy can't do what you want, when in fact it can, and trivially so. Adding the same amount of complexity to the base language wouldn't make it any more discoverable--it would just mean that _all_ Python users now have the potential to be confused, rather than only Python+numpy users, which sounds like a step backward.

Also, this is going to sound like a rhetorical, or even baited, question, but it's not intended that way: what's wrong with APL, or J, or MATLAB, and what makes you want to use Python instead? I'll bet that, directly or indirectly, the reason is the simplicity, consistency, and readability of Python. If you make Python more cryptic and dense, there's a very good chance it'll end up less readable than J rather than more, which would defeat the entire purpose.

Also, while we're at it, if you want the same features as APL and MATLAB, why invent a very different syntax instead of just using their syntax? Most proposals for adding elementwise computation to the base language suggest adding array operators like .+ that work the same way on all types, not adding object-wrapping operators that turn a list or a bunch of separate objects into some hidden type that overloads the normal + operator to be elementwise. What's the rationale for doing it your way instead of the usual way? (I can see one pretty good answer--consistency with numpy--but I don't think it's what you have in mind.)

> Regarding your question about the difference between 
> innerProduct += $a * $b
> and
> innerProduct = $innerProduct + $a * $b
> 
> The second statement returns error. I mentioned in my initial email that $ applies to a list or a tuple.
> Here I explicitly set my innerProduct=0 initially which you omitted in your example.
> 
> innerProduct += $a * $b
> is equivalent to
> for i in len(range(a)):
> ...innerProduct +=a[i]*b[i]
> 
> 
> 
> 
> 
>> On Wed, Jan 27, 2016 at 2:30 AM, Sjoerd Job Postmus <sjoerdjob at sjec.nl> wrote:
>> On Wed, Jan 27, 2016 at 01:19:56AM -0500, Mirmojtaba Gharibi wrote:
>> > Yes, I'm aware sequence unpacking.
>> > There is an overlap like you mentioned, but there are things that can't be
>> > done with sequence unpacking, but can be done here.
>> >
>> > For example, let's say you're given two lists that are not necessarily
>> > numbers, so you can't use numpy, but you want to apply some component-wise
>> > operator between each component. This is something you can't do with
>> > sequence unpacking or with numpy. For example:
>> >
>> > $StudentFullName = $FirstName + " " + $LastName
>> >
>> > So, in effect, I think one big part of is component wise operations.
>> >
>> > Another thing that can't be achieved with sequence unpacking is:
>> > f($x)
>> > i.e. applying f for each component of x.
>> 
>> map(f, x)
>> 
>> >
>> > About your question above, it's not ambiguous here either:
>> >  a; b = x1;a + x2;5
>> > is exactly "Equivalent" to
>> > a = x1+x2
>> > b = a + 5
>> 
>> Now that's confusing, that it differs from sequence unpacking.
>> 
>> >
>> > Also, there is a difference in style in sequence unpacking, and here.
>> > In sequence unpacking, you have to pair up the right variables and repeat
>> > the operator, for example:
>> > x,y,z = x1+x2 , y1+y2, z1+z2
>> > Here you don't have to repeat it and pair up the right variables, i.e.
>> > x;y;z = x1;y1;z1 + x2;y2;z2
>> > It's I think good that you (kind of) don't break the encapsulation-ish
>> > thing we have for the three values here. Also, you don't risk, making a
>> > mistake in the operator for one of the values by centralizing the operator
>> > use. For example you could make the mistake:
>> > x,y,z = x1+x2, y1-y2, z1+z2
>> >
>> > Also there are all sort of other things that are less of a motivation for
>> > me but that cannot be done with sequence unpacking.
>> > For instance:
>> > add ; prod = a +;* y  (This one I'm not sure how can be achieved without
>> > ambiguity)
>> > x;y = f;g (a;b)
>> >
>> >
>> > On Wed, Jan 27, 2016 at 12:57 AM, Sjoerd Job Postmus <sjoerdjob at sjec.nl>
>> > wrote:
>> >
>> > > On Wed, Jan 27, 2016 at 12:25:05AM -0500, Mirmojtaba Gharibi wrote:
>> > > > Hello,
>> > > >
>> > > > I'm thinking of this idea that we have a pseudo-operator called
>> > > > "Respectively" and shown maybe with ;
>> > >
>> > > Hopefully, you're already aware of sequence unpacking? Search for
>> > > 'unpacking' at https://docs.python.org/2/tutorial/datastructures.html .
>> > > Unfortunately, it does not have its own section I can directly link to.
>> > >
>> > >     x, y = 3, 5
>> > >
>> > > would give the same result as
>> > >
>> > >     x = 3
>> > >     y = 5
>> > >
>> > > But it's more robust, as it can also deal with things like
>> > >
>> > >     x, y = y + 1, x + 4
>> > > >
>> > > > Some examples first:
>> > > >
>> > > > a;b;c = x1;y1;z1 + x2;y2;z2
>> > > > is equivalent to
>> > > > a=x1+x2
>> > > > b=y1+y2
>> > > > c=z1+z2
>> > >
>> > > So what would happen with the following?
>> > >
>> > >     a; b = x1;a + x2;5
>> > >
>> > > >
>> > > > So it means for each position in the statement, do something like
>> > > > respectively. It's like what I call a vertical expansion, i.e. running
>> > > > statements one by one.
>> > > > Then there is another unpacking operator which maybe we can show with $
>> > > > sign and it operates on lists and tuples and creates the "Respectively"
>> > > > version of them.
>> > > > So for instance,
>> > > > vec=[]*10
>> > > > $vec = $u + $v
>> > > > will add two 10-dimensional vectors to each other and put the result in
>> > > vec.
>> > > >
>> > > > I think this is a syntax that can make many things more concise plus it
>> > > > makes component wise operation on a list done one by one easy.
>> > > >
>> > > > For example, we can calculate the inner product between two vectors like
>> > > > follows (inner product is the sum of component wise multiplication of two
>> > > > vectors):
>> > > >
>> > > > innerProduct =0
>> > > > innerProduct += $a * $b
>> > > >
>> > > > which is equivalent to
>> > > > innerProduct=0
>> > > > for i in range(len(a)):
>> > > > ...innerProduct += a[i]+b[i]
>> > > >
>> 
>> Thinking about this some more:
>> 
>> How do you know if this is going to return a list of products, or the
>> sum of those products?
>> 
>> That is, why is `innerProduct += $a * $b` not equivalent to
>> `innerProduct = $innerProduct + $a * $b`? Or is it? Not quite sure.
>> 
>> A clearer solution would be
>> 
>>     innerProduct = sum(map(operator.mul, a, b))
>> 
>> But that's current-Python syntax.
>> 
>> To be honest, I still haven't seen an added benefit that the new syntax
>> would gain. Maybe you could expand on that?
>> 
>> > >
>> > > From what I can see, it would be very beneficial for you to look into
>> > > numpy: http://www.numpy.org/ . It already provides inner product, sums
>> > > of arrays and such. I myself am not very familiar with it, but I think
>> > > it provides what you need.
>> > >
>> > > >
>> > > > For example, let's say we want to apply a function to all element in a
>> > > > list, we can do:
>> > > > f($a)
>> > > >
>> > > > The $ and ; take precedence over anything except ().
>> > > >
>> > > > Also, an important thing is that whenever, we don't have the respectively
>> > > > operator, such as for example in the statement above on the left hand
>> > > side,
>> > > > we basically use the same variable or value or operator for each
>> > > statement
>> > > > or you can equivalently think we have repeated that whole thing with
>> > > ;;;;.
>> > > > Such as:
>> > > > s=0
>> > > > s;s;s += a;b;c; * d;e;f
>> > > > which result in s being a*d+b,c*e+d*f
>> > > >
>> > > > Also, I didn't spot (at least for now any ambiguity).
>> > > > For example one might think what if we do this recursively, such as in:
>> > > > x;y;z + (a;b;c);(d;e;f);(g;h;i)
>> > > > using the formula above this is equivalent to
>> > > > (x;x;x);(y;y;y);(z;z;z)+(a;b;c);(d;e;f);(g;h;i)
>> > > > if we apply print on the statement above, the result will be:
>> > > > x+a
>> > > > x+b
>> > > > x+c
>> > > > y+d
>> > > > y+e
>> > > > y+f
>> > > > z+g
>> > > > z+h
>> > > > z+i
>> > > >
>> > > > Beware that in all of these ; or $ does not create a new list. Rather,
>> > > they
>> > > > are like creating new lines in the program and executing those lines one
>> > > by
>> > > > one( in the case of $, to be more accurate, we create for loops).
>> > > >
>> > > > I'll appreciate your time and looking forward to hearing your thoughts.
>> > >
>> > > Again, probably you should use numpy. I'm not really sure it warrants a
>> > > change to the language, because it seems like it would really only be
>> > > beneficial to those working with matrices. Numpy already supports it,
>> > > and I'm suspecting that the use case for `a;b = c;d + e;f` can already
>> > > be satisfied by `a, b = c + e, d + f`, and it already has clearly
>> > > documented semantics and still works fine when one of the names on the
>> > > left also appears on the right: First all the calculations on the right
>> > > are performed, then they are assigned to the names on the left.
>> > >
>> > > >
>> > > > Cheers,
>> > > > Moj
>> > >
>> > > Kind regards,
>> > > Sjoerd Job
>> > >
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160127/b9bcdf16/attachment-0001.html>