Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

CHB, Thank you! I had forgotten that discussion at the beginning of July [1].  Googling the list [2] also shows mention of PythonQL [3], which may point to use cases that can guide a Vectorization idea. [1] groupby discussion -

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Do take a look in the fairly recent archives of this list for a big discussion of groupby -- it kind of petered out but there were a couple options on the table. -CHB On Sun, Feb 10, 2019 at 9:23 PM Kyle Lahnakoski wrote: > > On 2019-02-10 18:30, Steven D'Aprano wrote: > > > > Can you post a

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-10 18:30, Steven D'Aprano wrote: > > Can you post a simplified example of how you would do it in SQL, > compared to what you would have to do in standard Python? Can I do the same in standard Python? If I did, then I would use Pandas: it has groupby, and some primitive joining, and

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 10, 2019 at 01:05:42PM -0500, Kyle Lahnakoski wrote: > I am interested in vector operations.  I have situations where I want to > perform some conceptually simple operations on a series of > not-defined-by-me objects to make a series of conclusions.  The > calculations can be done

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 10, 2019 at 10:06 AM Kyle Lahnakoski wrote: > but none of these are as elegant or readable as the vectorized syntax > > result = process.(vector .+ sequence) .* items > > I've a bit lost track of who is proposing what, but this looks like an extra set of operators: ".*", ".+"

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-02 18:11, Steven D'Aprano wrote: > We can improve that comprehension a tiny bit by splitting it into > multiple steps: > > temp1 = [d+e for d, e in zip(vector, sequence)] > temp2 = [process(c) for x in temp1] > result = [a*b for a, b in zip(temp2, items)] > > but none of

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Christopher Barker writes: > well, vectorization is kinda the *opposite* of matrix multiplication -- > matrix multiplication is treating the matrix as a whole, When I think of treating the matrix as a whole, I think of linear algebra. Matrix multiplication is repeated application of the inner

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Just a quick idea. Wouldn't an arrow operator -> be less of an eye sore? Em sex, 8 de fev de 2019 às 18:16, Christopher Barker escreveu: > On Thu, Feb 7, 2019 at 4:27 PM David Mertz wrote: > > > Actually, if I wanted an operator, I think that @ is more intuitive than > extra dots.

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Has anyone thought about my proposal yet? I think because it allows chained function calls to be stored, which is probably something that is a common; if imagine people turning the same series of chained functions into a lambda of its own once it’s used more than once in a program. Arguably,

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Fri, Feb 8, 2019 at 3:17 PM Christopher Barker wrote: > >vec_seq = Vector(seq) > >(vec_seq * 2).name.upper() > ># ... bunch more stuff > >seq = vec_seq.unwrap() > > what type would .unwrap() return? > The idea—and the current toy implementation/alpha—has .unwrap return

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Thu, Feb 7, 2019 at 4:27 PM David Mertz wrote: > Actually, if I wanted an operator, I think that @ is more intuitive than extra dots. Vectorization isn't matrix multiplication, but they are sort of in the same ballpark, so the iconography is not ruined. well, vectorization is kinda the

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Thu, Feb 7, 2019 at 6:48 PM Steven D'Aprano wrote: > I'm sorry, I did not see your comment that you thought new syntax was a > bad idea. If I had, I would have responded directly to that. > Well... I don't think it's the worst idea ever. But in general adding more operators is something I

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Thu, Feb 07, 2019 at 03:17:18PM -0500, David Mertz wrote: > Many apologies if people got one or more encrypted versions of this. > > On 2/7/19 12:13 AM, Steven D'Aprano wrote: > > It wasn't a concrete proposal, just food for thought. Unfortunately the > thinking seems to have missed the point

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Many apologies if people got one or more encrypted versions of this. On 2/7/19 12:13 AM, Steven D'Aprano wrote: It wasn't a concrete proposal, just food for thought. Unfortunately the thinking seems to have missed the point of the Julia syntax and run off with the idea of a wrapper class. I did

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Here are some alternate syntaxes. These are all equivalent to len(print(list)). (len | print)(list) (len |> print)(list) (print <| len)(list) print <| len << list list >> print <| len list >> len |> print ## Traditional argument order print <| len << list ## Stored functions print_lengths =

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-07 05:27, Chris Angelico wrote: On Thu, Feb 7, 2019 at 4:03 PM Steven D'Aprano wrote: At the risk of causing confusion^1, we could have a "vector call" syntax: # apply len to each element of obj, instead of obj itself len[obj] which has the advantage that it only requires

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Thu, Feb 7, 2019 at 4:03 PM Steven D'Aprano wrote: > At the risk of causing confusion^1, we could have a "vector call" > syntax: > > # apply len to each element of obj, instead of obj itself > len[obj] > > which has the advantage that it only requires that we give functions a >

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 03, 2019 at 09:46:44PM -0800, Christopher Barker wrote: > I've lost track if who is advocating what, but: Ironically, I started this sub-thread in response to your complaint that you didn't like having to explicitly write loops/maps. So I pointed out that in Julia, people can use

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Before I respond to a specific point below, I'd like to make a general observation. I changed the subject line of this sub-thread to discuss a feature of Julia, which allows one to write vectorized code in standard infix arithmetic notation, that applies to any array type, using any existing

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Hi, I'm not sure to understand the real purpose of Vector. Is that a new collection ? Is that a list with a builtin map() function ? Is it a  wrapper to other types ? Should it be iterable ? The clear need explained before is using fluent interface on a collection :

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Mon, Feb 4, 2019 at 7:14 AM Kirill Balunov wrote: > len(v) # -> 12 > > v[len] # -> > > > In this case you can apply any function, even custom_linked_list from > my_inhouse_module.py. > I think I really like this idea. Maybe as an extra spelling but still allow .apply() to do the same

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

вс, 3 февр. 2019 г. в 21:23, David Mertz : > > I think the principled thing to do here is add the minimal number of > methods to Vector itself, and have everything else pass through as > vectorized calls. Most of that minimal number are "magic method": > __len__(), __contains__(), __str__(),

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Mon, Feb 4, 2019, 12:47 AM Christopher Barker > I've lost track if who is advocating what, but: > Well, I made a toy implementation of a Vector class. I'm not sure what that means I advocate other than the existence of a module on GitHub. FWIW, I called the repo 'stringpy' as a start, so

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

I've lost track if who is advocating what, but: > >>> # Replace all "a" by "b" > >>> v.apply(lambda s: s.replace("a", "b")) >> > I do not get the point of this at all -- we already have map" map(v, lambda s s.replace()"a,", "b") these seem equally expressive an easy to me, and map doesn't

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

> I know, but if an element-wise operator is useful it would also be useful > for libraries like NumPy that already support the @ operator for matrix > multiplication. > A bit of history: A fair amount of inspiration (or at least experience) for numpy came from MATLAB. MATLAB has essentially

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

How would you spell these with funcoperators? v.replace("a","b").upper().count("B") vec1.replace("PLACEHOLDER", vec2) concat = vec1 + vec2 On Sun, Feb 3, 2019, 6:40 PM Robert Vanden Eynde > > On Sat, 2 Feb 2019, 21:46 Brendan Barnwell > Yeah, it's called pip install funcoperators : > >>

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 3, 2019, 6:36 PM Greg Ewing > But they only cover the special case of a function that takes > elements from just one input vector. What about one that takes > coresponding elements from two or more vectors? > What syntax would you like? Not necessarily new syntax per se, but what

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, 2 Feb 2019, 21:46 Brendan Barnwell some_list @ str.lower @ tokenize @ remove_stopwords > → some_list @ to(str.lower) @ to(tokenize) @ to(remove_stopwords) Where from funcoperators import postfix as to ___ Python-ideas mailing list

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Adrien Ricocotam wrote: >>> # Compute the length of each element of the Vector `v` >>> v.apply(len) >>> v @ len Another example with parameters >>> # Replace all "a" by "b" >>> v.apply(lambda s: s.replace("a", "b")) >>> v @ (lambda s: s.replace("a", "b")) My personal opinion is that the

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-03 22:58, David Mertz wrote: >>> len(v)  # Number of elements in the Vector `v` Agreed, this should definitely be the behavior.  So how do we get a vector of lengths of each element? >>> # Compute the length of each element of the Vector `v` >>> v.apply(len)

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Ronald Oussoren via Python-ideas wrote: On 3 Feb 2019, at 21:34, David Mertz > wrote: >> Using @ both for matrix multiplication and element-wise application could be made to work, but would be very confusing. The way @ is defined in numpy does actually work for

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

> > >>> len(v) # Number of elements in the Vector `v` > Agreed, this should definitely be the behavior. So how do we get a vector of lengths of each element? > >>> # Compute the length of each element of the Vector `v` > >>> v.apply(len) > >>> v @ len > Also possible is: v.len() We

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Adrien Ricocotam wrote: I honestly don’t understand what you don’t like the @ syntax. Another probkem with @ is that it already has an intended meaing, i.e. matrix multiplication. What if you have two vectors of matrices and you want to multiply corresponding ones? -- Greg

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

@David Mertz I think I can't explain well my ideas ^^. I'll try to be really detailed so I'm not sure I'm actually saying what I'm thinking. Let's consider the idea of that Vector class this way : Vectors are list of a defined type (may be immutable ?) and adds sugar syntaxing for vectorized

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

> On 3 Feb 2019, at 21:34, David Mertz wrote: > > On Sun, Feb 3, 2019 at 3:16 PM Ronald Oussoren > wrote: > The @ operator is meant for matrix multiplication (see PEP 465) and is > already used for that in NumPy. IMHO just that is a good enough reason for > not

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 3, 2019 at 3:16 PM Ronald Oussoren wrote: > The @ operator is meant for matrix multiplication (see PEP 465) and is > already used for that in NumPy. IMHO just that is a good enough reason for > not using @ as an elementwise application operator (ignoring if having an > such an

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

> On 3 Feb 2019, at 09:54, Adrien Ricocotam wrote: > > Nice that you implemented it ! > > I think all the issues you have right now would go of using another > operation. I proposed the @ notation that is clear and different from > everything else, > plus the operator is called "matmul" so

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 3, 2019 at 1:38 PM Adrien Ricocotam wrote: > I honestly don’t understand what you don’t like the @ syntax. > Can you show any single example that would work with the @ syntax that would not work in almost exactly the same way without it? I have not seen any yet, and none seem

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

I honestly don’t understand what you don’t like the @ syntax. My idea is using functions that takes on argument : an object of the type of the vector. That’s actually how map works. What I understood from your previous message is that there’s ambiguity when using magic functions on whether it’s

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 3, 2019 at 3:54 AM Adrien Ricocotam wrote: > I think all the issues you have right now would go of using another > operation. I proposed the @ notation that is clear and different from > everything else, > plus the operator is called "matmul" so it completely makes sense. The the >

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

There is no need for any of you to argue over this small point. Tolerate each other’s language. Sent from my iPhone > On Feb 2, 2019, at 3:58 AM, Steven D'Aprano wrote: > >> On Sat, Feb 02, 2019 at 05:10:14AM +, MRAB wrote: >>> On 2019-02-02 04:32, Steven D'Aprano wrote: >>> [snip] >>>

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Nice that you implemented it ! I think all the issues you have right now would go of using another operation. I proposed the @ notation that is clear and different from everything else, plus the operator is called "matmul" so it completely makes sense. The the examples would be : >>> l = "Jan

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

> > I think it should follow the pre-existing behaviour of list, set, tuple, > etc. > > >>> Vector("hello") > > I try to keep the underlying datatype of the wrapped collection as much as possible. Casting a string to a list changes that. >>> Vector(d) >>> Vector(tuple(d)) >>> Vector(set(d))

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 2, 2019 at 10:00 PM MRAB wrote: > Perhaps a reserved attribute that let's you refer to the vector itself > instead of its members, e.g. '.self'? > > >>> len(v) > > >>> len(v.self) > 12 > I like that! But I'm not sure if '.self' is misleading. I use an attribute called '._it'

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-03 02:03, David Mertz wrote: Slightly more on my initial behavior: >>> Vector({1:2,3:4}) TypeError: Ambiguity vectorizing a map, perhaps try it.keys(), it.values(), or it.items() >>> Vector(37) TypeError: Vector can only be initialized with an iterable

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Trying to make iterators behave in a semi-nice way also. I kinda like this (example remains silly, but it shows idea). >>> for n, mon in enumerate(vi.upper().replace('J','_').title()): ... print(mon) ... if n>3: break ... ... _An Feb Mar Apr May >>> vi > >>> list(vi) ['Jun', 'Jul', 'Aug',

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-03 01:54, David Mertz wrote: Here is a very toy proof-of-concept: >>> from vector import Vector >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() >>> v = Vector(l) >>> v >>> v.strip().lower().replace('a','X') >>> vt =

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Slightly more on my initial behavior: >>> Vector({1:2,3:4}) TypeError: Ambiguity vectorizing a map, perhaps try it.keys(), it.values(), or it.items() >>> Vector(37) TypeError: Vector can only be initialized with an iterable >>> Vector("hello") I'm wondering if maybe making a vector out of a

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Here is a very toy proof-of-concept: >>> from vector import Vector >>> l = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split() >>> v = Vector(l) >>> v >>> v.strip().lower().replace('a','X') >>> vt = Vector(tuple(l)) >>> vt >>> vt.lower().replace('o','X') My few lines are at

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

MRAB wrote: Well, if we were using an English prefix, wouldn't it be "unhomogeneous"? If we're sticking with Greek it would have to be something like "anhomogeneous". -- Greg ___ Python-ideas mailing list Python-ideas@python.org

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 2, 2019 at 3:31 PM Steven D'Aprano wrote: > The comprehension version isn't awful: > > [(a*2).name.upper() for a in seq] > > but not all vectorized operations can be written as a chain of calls on > a single sequence. > If they are strictly parallel (no dot products) and you

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

My double dot was a typo on my tablet, not borrowing Julia syntax, in this case. On Sat, Feb 2, 2019, 6:43 PM David Mertz On Sat, Feb 2, 2019, 6:23 PM Christopher Barker > >> a_list_of_strings.strip().lower().title() >> >> is a lot nicer than: >> >> [s.title() for s in (s.lower() for s in

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 3, 2019 at 10:36 AM Ben Rudiak-Gould wrote: > > On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker wrote: >> >> a_list_of_strings.strip().lower().title() >> >> is a lot nicer than: >> >> [s.title() for s in (s.lower() for s in [s.strip(s) for s in >> a_list_of_strings])] >> >> or >>

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 2, 2019, 6:23 PM Christopher Barker > a_list_of_strings.strip().lower().title() > > is a lot nicer than: > > [s.title() for s in (s.lower() for s in [s.strip(s) for s in > a_list_of_strings])] > > or > > list(map(str.title, (map(str.lower, (map(str.strip, a_list_of_strings > #

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 02, 2019 at 03:22:12PM -0800, Christopher Barker wrote: [This bit was me] > Even numpy supports inhomogeneous data: > > py> a = np.array([1, 'spam']) > > py> a > > array(['1', 'spam'], > > dtype='|S4') > > > well, no -- it doesn't -- look carefully, that is an array or type

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sun, Feb 3, 2019 at 10:31 AM Steven D'Aprano wrote: > The dot arguably fails the "syntax should not look like grit on Tim's > monitor" test (although attribute access already fails that test). I > think the double-dot syntax looks like a typo, which is unfortunate. Agreed, so I would like to

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 2, 2019 at 3:23 PM Christopher Barker wrote: > performance asside, I use numpy because: > > c = np.sqrt(a**2 + b**2) > > is a heck of a lot easer to read, write, and get correct than: > > c = list(map(math.sqrt, map(lambda x, y: x + y, map(lambda x: x**2, a), >

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 02, 2019 at 06:08:24PM -0500, David Mertz wrote: > In terms of other examples: > > map(str.upper, seq) uppercases each item > map(operator.attrgetter('name'), seq) gets the name attribute of each item > map(lambda a: a*2, seq) doubles each item Now compose those operations:

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Fri, Feb 1, 2019 at 5:00 PM David Mertz wrote: > is is certainly doable. But why would it be better than: >> > > map(str.lower, my_string_vector) > map(compute_grad, my_student_vector) > or [s.lower() for s in my_string_vector] Side note: It's really interesting to me that Python introduced

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 02, 2019 at 03:31:29PM -0500, David Mertz wrote: > I still haven't seen any examples that aren't already spelled 'map(fun, it)' You might be right. But then there's nothing that map() can do that couldn't be written as a comprehension, and nothing that you can't do with a

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

Beyond possibly saving 3-5 characters, I continue not to see anything different from map in this discussion. list(vector) applies list to the vector itself. > list.(vector) applies list to each component of vector. > In Python: list(seq) applies list to the sequence itself map(list, seq)

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 02, 2019 at 07:58:34PM +, Jeff Allen wrote: [MRAB asked] > >OK, here's another one: if you use 'list(...)' on a vector, does it > >apply to the vector itself or its members? With the Julia vectorization operator, there is no puzzle there. list(vector) applies list to the vector

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-02 12:31, David Mertz wrote: I still haven't seen any examples that aren't already spelled 'map(fun, it)' The problem with this is the same problem with having a function called "add" instead of an operator. There is little gain when you're applying ONE function, but if you're

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

I still haven't seen any examples that aren't already spelled 'map(fun, it)' On Sat, Feb 2, 2019, 3:17 PM Jeff Allen On 02/02/2019 18:44, MRAB wrote: > > On 2019-02-02 17:31, Adrien Ricocotam wrote: > > I personally would the first option to be the case. But then vectors > shouldn't be list-like

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 02/02/2019 18:44, MRAB wrote: On 2019-02-02 17:31, Adrien Ricocotam wrote: > I personally would the first option to be the case. But then vectors shouldn't be list-like but more generator like. > OK, here's another one: if you use 'list(...)' on a vector, does it apply to the vector itself

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

That's tough. I'd say conver the vector to a list. But : my_vector.list() Would apply list on each element of the vector. Globally, I'd say if the vector is used as an argument, it's a usual iterable, if you use a member function (or any other notation like @ or .. or whatever) it's like map.

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-02 17:31, Adrien Ricocotam wrote: > I personally would the first option to be the case. But then vectors shouldn't be list-like but more generator like. > OK, here's another one: if you use 'list(...)' on a vector, does it apply to the vector itself or its members? >>>

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

I personally would the first option to be the case. But then vectors shouldn't be list-like but more generator like. Le sam. 2 févr. 2019 à 19:26, MRAB a écrit : > On 2019-02-02 09:22, Kirill Balunov wrote: > > > > > > сб, 2 февр. 2019 г. в 07:33, Steven D'Aprano >

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-02 09:22, Kirill Balunov wrote: сб, 2 февр. 2019 г. в 07:33, Steven D'Aprano >: I didn't say anything about a vector type. I agree  you did not say. But since you started a new thread from the one where the vector type was a little discussed, it

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-02 08:58, Steven D'Aprano wrote: On Sat, Feb 02, 2019 at 05:10:14AM +, MRAB wrote: On 2019-02-02 04:32, Steven D'Aprano wrote: [snip] > >Of course it makes sense. Even numpy supports inhomogeneous data: > [snip] "inhomogeneous"? Who came up with that? I don't know, but it has

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

@D’aprano I think you’re misleading by what I said, sorry for not being crystal clear. I just read the link on Julia (which I didn’t do) and I get what you mean now and it’s not quite different from what I said. I proposed introducing a new type : « vector » A few steps have been made in Python

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

сб, 2 февр. 2019 г. в 07:33, Steven D'Aprano : > > I didn't say anything about a vector type. > > I agree you did not say. But since you started a new thread from the one where the vector type was a little discussed, it seemed to me that it is appropriate to mention it here. Sorry about that.

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 02, 2019 at 02:06:56AM -0500, Alex Walters wrote: > "Television" as a word must annoy you :) I mentally replaced > "inhomogeneous" with "heterogeneous" They don't mean the same thing. https://english.stackexchange.com/questions/194906/heterogeneous-vs-inhomogeneous -- Steven

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Sat, Feb 02, 2019 at 05:10:14AM +, MRAB wrote: > On 2019-02-02 04:32, Steven D'Aprano wrote: > [snip] > > > >Of course it makes sense. Even numpy supports inhomogeneous data: > > > [snip] > > "inhomogeneous"? Who came up with that? I don't know, but it has been used since at least the

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On 2019-02-02 04:32, Steven D'Aprano wrote: [snip] Of course it makes sense. Even numpy supports inhomogeneous data: [snip] "inhomogeneous"? Who came up with that? "in-" is a negative prefix in Latin words, but "homogeneous" comes from Greek, where the negative prefix is "a-" (or "an-"

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

On Fri, Feb 1, 2019, 6:16 PM Adrien Ricocotam A thing I thought about but I'm not satisfy is using the new > matrix-multiplication operator: > > my_string_vector @ str.lower > > def compute_grad(a_student): > return "you bad" > my_student_vector @ compute_grad > This is

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

I think the actual proposal is having a new type of list (ie : vectors) that works like numpy but for any data. Instead of a list where the user has to be sure all the data is the same type, vectors makes him-er sure it's full of the same data than can me processed using a particular function (as

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

пт, 1 февр. 2019 г. в 02:24, Steven D'Aprano : > On Thu, Jan 31, 2019 at 09:51:20AM -0800, Chris Barker via Python-ideas > wrote: > > > I do a lot of numerical programming, and used to use MATLAB and now > numpy a > > lot. So I am very used to "vectorization" -- i.e. having operations that > >

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

I love moredots ❤️ With pip install funcoperators, one can implement the *dotmul* iff dotmul can be implemented as a function. L *dotmul* 1 Would work. Or even a simple tweak to the library would allow L *dot* s to be [x*s for x in L] and L /dot/ s to be [x/s for x in L]" I'd implement

Re: [Python-ideas] Vectorization [was Re: Add list.join() please]

I accidentally replied only to Steven - sorry! - this is what I said, with a typo corrected: > a_list_of_strings..lower() > > str.lower.(a_list_of_strings) I much prefer this solution to any of the other things discussed so far. I wonder, though, would it be general enough to simply have this

[Python-ideas] Vectorization [was Re: Add list.join() please]

On Thu, Jan 31, 2019 at 09:51:20AM -0800, Chris Barker via Python-ideas wrote: > I do a lot of numerical programming, and used to use MATLAB and now numpy a > lot. So I am very used to "vectorization" -- i.e. having operations that > work on a whole collection of items at once. [...] > You can