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@gmail.com> wrote:

On Wed, Jan 27, 2016 at 4:15 PM, Andrew Barnert <abarnert@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.

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@gmail.com> wrote:

On Wed, Jan 27, 2016 at 4:15 PM, Andrew Barnert <abarnert@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.