[Python-ideas] Respectively and its unpacking sentence

Wed Jan 27 12:12:07 EST 2016

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.

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
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160127/99a2e160/attachment.html>