[Python-ideas] Respectively and its unpacking sentence

[Mirmojtaba Gharibi]

On Thu, Jan 28, 2016 at 3:26 AM, Mirmojtaba Gharibi <
mojtaba.gharibi at gmail.com> wrote:

>
>
> On Wed, Jan 27, 2016 at 4:15 PM, Andrew Barnert <abarnert at yahoo.com>
> wrote:
>
>> On Jan 27, 2016, at 09:55, Mirmojtaba Gharibi <mojtaba.gharibi at gmail.com>
>> wrote:
>>
>> On Wed, Jan 27, 2016 at 2:29 AM, Andrew Barnert <abarnert at yahoo.com>
>> wrote:
>>
>>> On Jan 26, 2016, at 22:19, Mirmojtaba Gharibi <mojtaba.gharibi at gmail.com>
>>> 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.
>>>
>>>
>>> Yes, you can do it with numpy.
>>>
>>> Obviously you don't get the performance benefits when you aren't using
>>> "native" types (like int32) and operations that have vectorizes
>>> implementations (like adding two arrays of int32 or taking the dot product
>>> of float64 matrices), but you do still get the same elementwise operators,
>>> and even a way to apply arbitrary callables over arrays, or even other
>>> collections:
>>>
>>>     >>> firsts = ['John', 'Jane']
>>>     >>> lasts = ['Smith', 'Doe']
>>>     >>> np.vectorize('{1}, {0}'.format)(firsts, lasts)
>>>     array(['Smith, John', 'Doe, Jane'], dtype='<U11)
>>>
>>> I think the form I am suggesting is simpler and more readable.
>>
>>
>> But the form you're suggesting doesn't work for vectorizing arbitrary
>> functions, only for operator expressions (including simple function calls,
>> but that doesn't help for more general function calls). The fact that numpy
>> is a little harder to read for cases that your syntax can't handle at all
>> is hardly a strike against numpy.
>>
>
> I don't need to vectorize the functions. It's already being done.
> Consider the ; example below:
> a;b = f(x;y)
> it is equivalent to
> a=f(x)
> b=f(y)
> So in effect, in your terminology, it is already vectorized.
> Similar example only with $:
> a=[0,0,0,0]
> x=[1,2,3,4]
> $a=f($x)
> is equivalent to
> a=[0,0,0,0]
> x=[1,2,3,4]
> for i in range(len(a)):
> ...a[i]=f(x[i])
>
>
>
>>
>> And, as I already explained, for the cases where your form _does_ work,
>> numpy already does it, without all the sigils:
>>
>>     c = a + b
>>
>>     c = a*a + 2*a*b + b*b
>>
>>     c = (a * b).sum()
>>
>> It also works nicely over multiple dimensions. For example, if a and b
>> are both arrays of N 3-vectors instead of just being 3-vectors, you can
>> still elementwise-add them just with +; you can sum all of the results with
>> sum(axis=1); etc. How would you write any of those things with your
>> $-syntax?
>>
>> I'm happy you brought vectorize to my attention though. I think as soon
>> you make the statement just a bit complex, it would become really
>> complicated with vectorize.
>>
>>
>> For example lets say you have
>> x=[1,2,3,4,5,...]
>> y=['A','BB','CCC',...]
>> p=[2,3,4,6,6,...]
>> r=[]*n
>>
>> $r = str(len($y*$p)+$x)
>>
>>
>> As a side note, []*n is always just []. Maybe you meant [None for _ in
>> range(n)] or [None]*n? Also, where does n come from? It doesn't seem to
>> have anything to do with the lengths of x, y, and p. So, what happens if
>> it's shorter than them? Or longer? With numpy, of course, that isn't a
>> problem--there's no magic being attempted on the = operator (which is good,
>> because = isn't an operator in Python, and I'm not sure how you'd even
>> properly define your design, much less implement it); the operators just
>> create arrays of the right length.
>>
>> n I just meant symbolically to be len(x). So please replace n with
> len(x). I didn't mean to confuse you. sorry.
>
>
>> Anyway, that's still mostly just operators. You _could_ wrap up an
>> operator expression in a function to vectorize, but you almost never want
>> to. Just use the operators directly on the arrays.
>>
>> So, let's try a case that has even some minimal amount of logic, where
>> translating to operators would be clumsy at best:
>>
>>     @np.vectorize
>>     def sillyslice(y, x, p):
>>         if x < p: return y[x:p]
>>         return y[p:x]
>>
>>     r = sillyslice(y, x, p)
>>
>> Being a separate function provides all the usual benefits: sillyslice is
>> reusable, debuggable, unit-testable, usable as a first-class object, etc.
>> But forget that; how would you do this at all with your $-syntax?
>>
>> Since you didn't answer any of my other questions, I'll snip them and
>> repost shorter versions:
>>
>> * what's wrong with using numpy? Nothing. What's wrong even with for loop
>> or assembly for that matter? I didn't argue that it's not possible to
>> achieve these things with assembly.
>> * what's wrong with APL or J or MATLAB? Not sure how relevant it is to
>> our core of conversation. Skipping this.
>> * what's wrong with making the operators elementwise instead of wrapping
>> the objects in some magic thing? The fact that whenever you
>> * what is the type of that magic thing anyway? It has no type. I refer
>> you to my very first email. In that email I exactly explained what it
>> means. It's at best a psuedo macro or something like that. It exactly is
>> equivalent when you write
>>
> a;b=f(x;y)
> to
> a=f(x)
> b=f(y)
>
> In other words, if I could interpret my code before python interpreter
> interpret it, I would convert the first to the latter.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160128/f5fe58f4/attachment-0001.html>