[Python-ideas] Respectively and its unpacking sentence

[Franklin? Lee]

For personal use, I wrote a class. (Numpy takes a while to load on my machine.)

    vec = Vector([1,2,3])
    vec2 = vec + 5
    lst = vec2.tolist()


I also add attribute access.

    # creates a Vector of methods, which is then __call__'d
    vec_of_lengths = vec2.bit_length()


And multi-level indexing, similar to Numpy, though I think I might
want to remove indexing of the Vector itself for consistency.

   vec = Vector([{1:2}, {1:3}, {1,4}])

   values = vec[:, 1] # Vector([2,3,4])


And multiple versions of `.map()` (which have different ways of
interpreting the additional arguments).


But this is for personal use. Dirty scripting.


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:
>>
>> 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])

Is that really a _benefit_ of this design? "Explicit is better than implicit."


>> 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)
>
> It would be really complex to calculate such a thing with vectorize.

I think you misunderstand the way to use np.vectorize. You would write
a function, and then np.vectorize it.

    def some_name(yi, pi, xi):
        return str(len(yi * pi) + xi)

    r = np.vectorize(some_name)(y, p, x)


In terms of readability, it's probably better: you're describing an
action you would take, and then (by vectorizing it) saying that you'll
want to repeat that action multiple times.


>> * 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.

He's asking what benefit it has over using Numpy. You are proposing a
change, and must justify the additional code, API, programmer head
room, and maintenance burden. Why do you want this feature over the
existing options?


>> * 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.

That's very magical. Magic is typically bad. Have you considered the
cost to people learning to read Python?

I also hate that it doesn't have a type. I don't see

    a;b = f(x;y)

as readable (semicolons look sort of like commas to my weak eyes) or
useful (unlike the "$x = f($y)" case). Compare with

    a, b = map(f, (x, y))

Any vectorization syntax allows us to write vectorized expressions
without the extra semicolon syntax.

    a, b = f($[x, y])
    #or:
    $(a, b) = f($[x, y])

    a, b = f*(x, y)

    a, b, c = $(x1, y1, z1) + $(x2, y2, z2)

    two_dimensional_array = $(1, 2, 3) * $$(1, 2, 3)
    # == ((1, 2, 3),
    #     (2, 4, 6),
    #     (3, 6, 9))
    # (Though how would you vectorize over two dimensions? Syntax is hard.)


> innerProduct =0
> innerProduct += $a * $b

I don't like this at all. A single `=` or `+=` meaning an unbounded
number of assignments? This piece of code should really just use
sum().

With theoretical syntax:

    innerProduct = sum(^($a * $b))

where the ^ (placeholder symbol) will force collapse to a
list/tuple/iterator so that the vectorization doesn't "escape" and get
interpreted as

    innerProduct = [sum(ax * bx) for ax, bx in zip(a, b)]

Anyway, there's a lot to think about, and a lot of potential issues of
ambiguity to argue over. That's why I just put these kinds of ideas in
my notes about language designs, rather than try to think about how
they could fit into Python (or any existing language).

(Speaking of language design and syntax, vectorization syntax is
related to lambda literals: they need a way to make sure that
<something> doesn't escape. Arc Lisp uses square brackets instead of
the normal parentheses for lambdas, which bind the `_` parameter
symbol.)


P.S.: In the Gmail editor's bottom-right corner, click the triangle,
and set Plain Text Mode. You can also go to Settings -> General and
turn on "Reply All" as the default behavior, though this won't set it
for mobile.