Re: Need max values in list of tuples, based on position

On 11/13/2022 7:37 AM, Pancho wrote: On 11/11/2022 19:56, DFS wrote: Edit: found a solution online: - x = [(11,1,1),(1,41,2),(9,3,12)] maxvals = [0]*len(x[0]) for e in x:  maxvals = [max(w,int(c)) for w,c in zip(maxvals,e)] pri

Re: Need max values in list of tuples, based on position

On 11/11/2022 19:56, DFS wrote: Edit: found a solution online: - x = [(11,1,1),(1,41,2),(9,3,12)] maxvals = [0]*len(x[0]) for e in x: maxvals = [max(w,int(c)) for w,c in zip(maxvals,e)] print(maxvals) [11,41,12] ---

Re: Need max values in list of tuples, based on position

On Sat, 12 Nov 2022 13:24:37 -0500, Dennis Lee Bieber declaimed the following: > Granted, this will NOT work with "select *" unless one does the select >*/fetchall first, AND extracts the names from the cursor description -- >then run a loop to create the select max(length(col)), ... state

Re: Need max values in list of tuples, based on position

On Fri, 11 Nov 2022 21:20:10 -0500, DFS declaimed the following: >Yeah, I don't know why cursor.description doesn't work with SQLite; all >their columns are basically varchars. > If you read PEP 249 (the general DB-API), everything except column name and data type code are optional. And

Re: Need max values in list of tuples, based on position

type checking in addition to the dyunamic typing. > From: Python-list on > behalf of Pancho via Python-list > Date: Friday, November 11, 2022 at 6:28 PM > To: python-list@python.org > Subject: Re: Need max values in list of tuples, based on position > > That was one of the thing

Re: Need max values in list of tuples, based on position

Types are available if you want to use them. https://www.pythontutorial.net/python-basics/python-type-hints/ From: Python-list on behalf of Pancho via Python-list Date: Friday, November 11, 2022 at 6:28 PM To: python-list@python.org Subject: Re: Need max values in list of tuples, based on

Re: Need max values in list of tuples, based on position

On 11/11/2022 7:04 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 15:03:49 -0500, DFS declaimed the following: Thanks for looking at it. I'm trying to determine the maximum length of each column result in a SQL query. Normally you can use the 3rd value of the cursor.description object (se

Re: Need max values in list of tuples, based on position

On Fri, 11 Nov 2022 15:03:49 -0500, DFS declaimed the following: >Thanks for looking at it. I'm trying to determine the maximum length of >each column result in a SQL query. Normally you can use the 3rd value >of the cursor.description object (see the DB-API spec), but apparently >not with

Re: Need max values in list of tuples, based on position

On 11/11/2022 20:58, Thomas Passin wrote: On 11/11/2022 2:22 PM, Pancho via Python-list wrote: On 11/11/2022 18:53, DFS wrote: On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1),  (2,1),   (0,1) , (1,41), (2,2),

Re: Need max values in list of tuples, based on position

On 11/11/2022 2:22 PM, Pancho wrote: On 11/11/2022 18:53, DFS wrote: On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1),  (2,1),   (0,1) , (1,41), (2,2),   (0,9) , (1,3),  (2,12)] The set of values in elements[0]

Re: Need max values in list of tuples, based on position

, and present it in the order of those rows? Your data list does not distinguish the rows from the tuples, so that information must come from somewhere else. Could it sometimes be different from 3? How are we supposed to know? Also, as has already been noted in this thread, the result cannot

Re: Need max values in list of tuples, based on position

On 11/11/2022 2:22 PM, Pancho via Python-list wrote: On 11/11/2022 18:53, DFS wrote: On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1),  (2,1),   (0,1) , (1,41), (2,2),   (0,9) , (1,3),  (2,12)] The set of value

Re: Need max values in list of tuples, based on position

On 11/11/2022 7:50 AM, Stefan Ram wrote: Pancho writes: def build_max_dict( tups): dict = {} for (a,b) in tups: if (a in dict): if (b>dict[a]): dict[a]=b else: dict[a]=b return(sorted(dict.values())) Or, import it

Re: Need max values in list of tuples, based on position

On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: > >[(0,11), (1,1), (2,1), > (0,1) , (1,41), (2,2), > (0,9) , (1,3), (2,12)] > >The set of values in elements[0] is {0,1,2} > >I want the set of max values in elements[1]: {11,41,12} Do they have to be IN THAT OR

Re: Need max values in list of tuples, based on position

On 11/11/2022 07:22, DFS wrote: [(0,11), (1,1),  (2,1),  (0,1) , (1,41), (2,2),  (0,9) , (1,3),  (2,12)] The set of values in elements[0] is {0,1,2} I want the set of max values in elements[1]: {11,41,12} def build_max_dict( tups): dict = {} for (a,b) in tups: if (a in di

Re: Need max values in list of tuples, based on position

On 11/11/2022 18:53, DFS wrote: On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1),  (2,1),   (0,1) , (1,41), (2,2),   (0,9) , (1,3),  (2,12)] The set of values in elements[0] is {0,1,2} I want the set of max val

Need max values in list of tuples, based on position

[(0,11), (1,1), (2,1), (0,1) , (1,41), (2,2), (0,9) , (1,3), (2,12)] The set of values in elements[0] is {0,1,2} I want the set of max values in elements[1]: {11,41,12} -- https://mail.python.org/mailman/listinfo/python-list

Re: Need max values in list of tuples, based on position

On 11/11/2022 12:49 PM, Dennis Lee Bieber wrote: On Fri, 11 Nov 2022 02:22:34 -0500, DFS declaimed the following: [(0,11), (1,1), (2,1), (0,1) , (1,41), (2,2), (0,9) , (1,3), (2,12)] The set of values in elements[0] is {0,1,2} I want the set of max values in elements[1]: {11,41,12}

Re: Friday Finking: initialising values and implied tuples

On Tue, Apr 6, 2021 at 5:36 AM Rob Cliffe via Python-list wrote: > > > > On 05/04/2021 18:33, Chris Angelico wrote: > > > > Firstly, anything with any variable at all can involve a lookup, which > > can trigger arbitrary code (so "variables which do not occur on the > > LHS" is not sufficient). >

Re: Friday Finking: initialising values and implied tuples

On 05/04/2021 18:33, Chris Angelico wrote: Firstly, anything with any variable at all can involve a lookup, which can trigger arbitrary code (so "variables which do not occur on the LHS" is not sufficient). Interesting.  I was going to ask: How could you make a variable lookup trigger arbitra

Re: Friday Finking: initialising values and implied tuples

0 LOAD_CONST 1 ((1, 2)) > >> 2 UNPACK_SEQUENCE 2 > >> 4 STORE_FAST 0 (x) > >> 6 STORE_FAST 1 (y) > >> 8 LOAD_CONST 0 (None) &

Re: Friday Finking: initialising values and implied tuples

On 05/04/2021 17:52, Chris Angelico wrote: I don't understand.  What semantic difference could there be between     x = { 1: 2 }    ;    y = [3, 4]   ;   z = (5, 6) and     x, y, z = { 1:2 }, [3, 4], (5, 6) ?  Why is it not safe to convert the latter to the former? But I withdraw "set" from my "

Re: Friday Finking: initialising values and implied tuples

(1, 2)) 2 UNPACK_SEQUENCE 2 4 STORE_FAST 0 (x) 6 STORE_FAST 1 (y) 8 LOAD_CONST 0 (None) 10 RETURN_VALUE Thinking some more about this, this (removing the tuples) is

Re: Friday Finking: initialising values and implied tuples

0 LOAD_CONST 1 ((1, 2)) >2 UNPACK_SEQUENCE 2 >4 STORE_FAST 0 (x) >6 STORE_FAST 1 (y) >8 LOAD_CONST 0 (None) > 10 RETURN_VALUE > Thinkin

Re: Friday Finking: initialising values and implied tuples

.  (It would be kinda nice if the compiler could optimise the tuples away, for those of us who are paranoid about performance.) I think I've read that the compiler is smart-enough to realise that the RHS 'literal-tuples'?'tuple-literals' are being used as a 'mechanism&#x

Re: Friday Finking: initialising values and implied tuples

On 2021-04-05 at 11:47:53 +1200, dn via Python-list wrote: > Did you spot how various contributors identified when they prefer one > method in a specific situation, but reach for another under differing > circumstances! What? Use cases matter? I'm *shocked*. :-/ Of all the methodologies I us

Re: Friday Finking: initialising values and implied tuples

On 5/04/21 11:47 am, dn wrote: I think I've read that the compiler is smart-enough to realise that the RHS 'literal-tuples'?'tuple-literals' are being used as a 'mechanism', and thus the inits are in-lined. It does indeed seem to do this in some cases: >

Re: Friday Finking: initialising values and implied tuples

) = (43,  3, 10) >> (x2, y2, z2) = (41, 12,  9) >> (x3, y3, z3) = ( 8,  8, 10) > Agreed, that is even easier to read.  (It would be kinda nice if the > compiler could optimise the tuples away, for those of us who are > paranoid about performance.) I think I'

Re: Friday Finking: initialising values and implied tuples

On 03/04/2021 11.25, Marco Ippolito wrote: >> (a) basic linear presentation: >> >> resource = "Oil" >> time = 1 >> crude = 2 >> residue = 3 >> my_list = "long" >> >> (b) using explicit tuples: >> >> ( resou

Re: Friday Finking: initialising values and implied tuples

but if you must see that structure, then go all in: (x1, y1, z1) = (43, 3, 10) (x2, y2, z2) = (41, 12, 9) (x3, y3, z3) = ( 8, 8, 10) Agreed, that is even easier to read.  (It would be kinda nice if the compiler could optimise the tuples away, for those of us who are paranoid ab

Re: Friday Finking: initialising values and implied tuples

On 2021-04-03 at 02:41:59 +0100, Rob Cliffe via Python-list wrote: >     x1 = 42; y1 =  3;  z1 = 10 >     x2 = 41; y2 = 12; z2 = 9 >     x3 =  8;  y3 =  8;  z3 = 10 > (please imagine it's in a fixed font with everything neatly vertically > aligned). > This has see-at-a-glance STRUCTURE: the lette

Re: Friday Finking: initialising values and implied tuples

list = "long" In production code I'd almost always go with this one. It's the only option that both keeps the variable and value together and allows me to add an explanatory comment if necessary. > (e) implicit tuples: > > resource, time, crude, residue, my_list = "O

Re: Friday Finking: initialising values and implied tuples

On 02/04/2021 23:10, dn via Python-list wrote: (f) the space-saver: resource = "Oil"; time = 1; crude = 2; residue = 3; my_list = "long" IMO This can be OK when the number of items is VERY small (like 2) and not expected to increase (or decrease).  Especially if there are multiple simil

Re: Friday Finking: initialising values and implied tuples

On 2021-04-02 at 19:25:07 -0300, Marco Ippolito wrote: > > (a) basic linear presentation: > > > > resource = "Oil" > > time = 1 > > crude = 2 > > residue = 3 > > my_list = "long" > > > > (b) using explicit tuples: >

Re: Friday Finking: initialising values and implied tuples

> (a) basic linear presentation: > > resource = "Oil" > time = 1 > crude = 2 > residue = 3 > my_list = "long" > > (b) using explicit tuples: > > ( resource, time, crude, residue, my_list ) = ( "Oil", 1, 2, 3, "long"

Friday Finking: initialising values and implied tuples

The essence is to apply various values to a series of objects. Simple? Using tuples can have its advantages, but as their length increases humans have difficulties with the positional nature/relationship. Here are a couple of ways that you may/not have seen, to express the need (and perhaps

Re: Puzzling difference between lists and tuples

On Mon, Sep 21, 2020 at 10:14 PM Serhiy Storchaka wrote: > > 18.09.20 03:55, Chris Angelico пише: > > On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards > > wrote: > >> Yea, the syntax for tuple literals has always been a bit of an ugly > >> spot in Python. If ASCII had only had one more set of open

Re: Puzzling difference between lists and tuples

18.09.20 03:55, Chris Angelico пише: > On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards > wrote: >> Yea, the syntax for tuple literals has always been a bit of an ugly >> spot in Python. If ASCII had only had one more set of open/close >> brackets... > > ... then I'd prefer them to be used for set

Re: Puzzling difference between lists and tuples

On 20Sep2020 20:33, Avi Gross wrote: >('M','R','A','B') is correct. I appreciate the correction. I did not look to >see the content of what I created, just the type! > a = tuple("first") a >('f', 'i', 'r', 's', 't') type(a) > > >But I thought adding a comma would help and it does no

RE: Puzzling difference between lists and tuples

iterator is iterating at a different level. >>> d = ["first"] >>> tuple(d) ('first',) >>> tuple(["first"]) ('first',) I understand the design choice and can imagine there may be another function that initializes a tuple more directly in

Re: Puzzling difference between lists and tuples

On 21/09/20 10:59 am, Avi Gross wrote: a=tuple("first") type(a) That seems more explicit than adding a trailing comma. It doesn't do what you want, though: >>> a = tuple("first") >>> print(a) ('f', 'i', 'r', 's', 't') If you really want to use tuple() to create a 1-tuple without using a tr

Re: Puzzling difference between lists and tuples

On 2020-09-20 23:59, Avi Gross via Python-list wrote: There is a simple and obvious way to make sure you have a tuple by invoking the keyword/function in making it: a=('first') type(a) a=("first",) type(a) a=tuple("first") type(a) That seems more explicit than adding a trailing comm

RE: Puzzling difference between lists and tuples

t seems more explicit than adding a trailing comma. It also is a simple way to make an empty tuple but is there any penalty for using the function tuple()? -Original Message- From: Python-list On Behalf Of "???" Sent: Saturday, September 19, 2020 11:39 PM To: python-list

sorry for typo (Was: Re: Puzzling difference between lists and tuples)

> #+BEGIN_SRC: python > for n in ('first',): > print n > #+BEGIN_SRC The last 'BEGIN_SRC' should be 'END_SRC' so sorry ;;; -- ^고맙습니다 _救濟蒼生_ 감사합니다_^))// -- https://mail.python.org/mailman/listinfo/python-list

Re: Puzzling difference between lists and tuples

William Pearson writes: > ... > for n in ('first'): > print n > > > ... but "f","i","r","s","t" in the second. #+BEGIN_SRC: python for n in ('first',): print n #+BEGIN_SRC Then, that will print 'first'. And please use Python3... Sincerely, Byung-Hee -- ^고맙습니다 _救濟蒼生_ 감사합니다_^))// -- h

Re: Puzzling difference between lists and tuples

On 19/09/20 6:49 am, Grant Edwards wrote: There must be a few more sets of brackets in Unicode... Quite a lot, actually. The character browser in MacOSX is currently showing me 17, not including the ones that are built up from multiple characters. Some of them could be easily confused with no

Re: Puzzling difference between lists and tuples

On 2020-09-18, Chris Angelico wrote: > On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards > wrote: >> >> On 2020-09-17, MRAB wrote: >> >> The only time the parentheses are required for tuple building is when >> >> they would otherwise not be interpreted that way: >> >> >> > They're needed for the emp

Re: Puzzling difference between lists and tuples

On Fri, Sep 18, 2020 at 10:53 AM Grant Edwards wrote: > > On 2020-09-17, MRAB wrote: > >> The only time the parentheses are required for tuple building is when > >> they would otherwise not be interpreted that way: > >> > > They're needed for the empty tuple, which doesn't have a comma. > > > >>

Re: Puzzling difference between lists and tuples

On 2020-09-17, MRAB wrote: >> The only time the parentheses are required for tuple building is when >> they would otherwise not be interpreted that way: >> > They're needed for the empty tuple, which doesn't have a comma. > >> some_func('first', 'second') # some_func called with two str args >>

Re: Puzzling difference between lists and tuples

On 9/17/20 10:43 AM, MRAB wrote: On 2020-09-17 17:47, Ethan Furman wrote: The only time the parentheses are required for tuple building is when they would otherwise not be interpreted that way: They're needed for the empty tuple, which doesn't have a comma. Ah, right. Thanks. -- ~Ethan~

Re: Puzzling difference between lists and tuples

On 2020-09-17 17:47, Ethan Furman wrote: On 9/17/20 8:24 AM, William Pearson wrote: I am puzzled by the reason for this difference between lists and tuples. A list of with multiple strings can be reduced to a list with one string with the expected results: for n in ['first']:

Re: Puzzling difference between lists and tuples

On 9/17/20 11:24 AM, William Pearson wrote: > I am puzzled by the reason for this difference between lists and tuples. > > A list of with multiple strings can be reduced to a list with one string with > the expected results: > > for n in ['first','second'

Re: Puzzling difference between lists and tuples

On 9/17/20 8:24 AM, William Pearson wrote: I am puzzled by the reason for this difference between lists and tuples. A list of with multiple strings can be reduced to a list with one string with the expected results: for n in ['first']: print n ['first'] is a list

Re: Puzzling difference between lists and tuples

On 2020-09-17 at 09:24:57 -0600, William Pearson wrote: > for n in ('first'): That's not a tuple. That's a string. Try it this way: for n in ('first',): # note the trailing comma print n Dan -- https://mail.python.org/mailman/listinfo/python-list

Puzzling difference between lists and tuples

I am puzzled by the reason for this difference between lists and tuples. A list of with multiple strings can be reduced to a list with one string with the expected results: for n in ['first','second']: print n for n in ['first']: print n The first loop

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On Thu, 19 Mar 2020 at 16:46, Peter J. Holzer wrote: > This is similar to algebraic expressions: Have you ever tried to read a > mathematical paper from before the time the current notation (which we > Long, convoluted > sentences instead of what can now be written as a short formula. ...yes, and

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 2020-03-19 15:17, Musbur wrote: Hello, either it's me or everybody else who's missing the point. I understand the OP's proposal like this: dict[set] == {k: dict[k] for k in set} list[iterable] == [list[i] for i in iterable] Am I right? "Iterable" is too broad b

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 19/03/2020 14:47, Peter J. Holzer wrote: On 2020-03-19 14:24:35 +, Rhodri James wrote: On 19/03/2020 13:00, Peter J. Holzer wrote: It's more compact, especially, if "d" isn't a one-character variable, but an expression: fname, lname = db[people].employee.object.get(pk=1234)[['firs

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On Fri, Mar 20, 2020 at 2:46 AM Peter J. Holzer wrote: > > A good language has a small core and extensibility via > > libraries. > > This would actually be a feature of the (standard) library. I think the line kinda blurs here. This would be a feature of a core data type, and in CPython, it would

RE: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

For dictionaries it'd even be more useful: d = { 'first_name': 'Frances', 'last_name': 'Allen', 'email': 'fal...@ibm.com' } fname, lname = d[['first_name', 'last_name']] Why not do this? import operator first_last = operator.itemgetter("first_name", "last_name"

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On Fri, Mar 20, 2020 at 2:37 AM Terry Reedy wrote: > > On 3/18/2020 10:28 PM, Santiago Basulto wrote: > > > For dictionaries it'd even be more useful: > > d = { > > 'first_name': 'Frances', > > 'last_name': 'Allen', > > 'email': 'fal...@ibm.com' > > } > >

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 2020-03-19 08:05:18 -0700, Dan Stromberg wrote: > On Thu, Mar 19, 2020 at 7:47 AM Peter J. Holzer wrote: > > On 2020-03-19 14:24:35 +, Rhodri James wrote: > > > On 19/03/2020 13:00, Peter J. Holzer wrote: > > > > It's more compact, especially, if "d" isn't a one-character variable, > > > >

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 03/19/2020 02:09 AM, Terry Reedy wrote: On 3/18/2020 10:28 PM, Santiago Basulto wrote: For dictionaries it'd even be more useful: d = { 'first_name': 'Frances', 'last_name': 'Allen', 'email': 'fal...@ibm.com' } fname, lname = d[['first_name', 'last_n

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 3/18/2020 10:28 PM, Santiago Basulto wrote: For dictionaries it'd even be more useful: d = { 'first_name': 'Frances', 'last_name': 'Allen', 'email': 'fal...@ibm.com' } fname, lname = d[['first_name', 'last_name']] Insert ordered dicts make this sort

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

Hello, either it's me or everybody else who's missing the point. I understand the OP's proposal like this: dict[set] == {k: dict[k] for k in set} list[iterable] == [list[i] for i in iterable] Am I right? -- https://mail.python.org/mailman/listinfo/python-list

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

Py? I think multi indexing > alone would be huge addition. A few examples: > > For lists and tuples: > >>> l = ['a', 'b', 'c'] > >>> l[[0, -1]] > ['a', 'c'] > > For dictionaries it&#

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On Thu, Mar 19, 2020 at 7:47 AM Peter J. Holzer wrote: > On 2020-03-19 14:24:35 +, Rhodri James wrote: > > On 19/03/2020 13:00, Peter J. Holzer wrote: > > > It's more compact, especially, if "d" isn't a one-character variable, > > > but an expression: > > > > > > fname, lname = > db[peop

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 2020-03-19 14:24:35 +, Rhodri James wrote: > On 19/03/2020 13:00, Peter J. Holzer wrote: > > It's more compact, especially, if "d" isn't a one-character variable, > > but an expression: > > > > fname, lname = db[people].employee.object.get(pk=1234)[['first_name', > > 'last_name']] > >

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

On 19/03/2020 13:00, Peter J. Holzer wrote: On 2020-03-19 18:22:34 +1300, DL Neil via Python-list wrote: On 19/03/20 3:28 PM, Santiago Basulto wrote: myself missing A LOT features from NumPy, like fancy indexing or boolean arrays. So, has it ever been considered to bake into Python's builtin li

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

t and > > dictionary types functionality inspired by NumPy? I think multi indexing > > alone would be huge addition. A few examples: > > For lists and tuples: > > >>> l = ['a', 'b', 'c'] > > >>> l[[0, -1]] &g

Re: PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

be huge addition. A few examples: For lists and tuples: >>> l = ['a', 'b', 'c'] >>> l[[0, -1]] ['a', 'c'] For dictionaries it'd even be more useful: d = { 'first_name': 'Frances&

PEP Idea: Multi-get for lists/tuples and dictionaries (inspired in NumPy)

lists and tuples: >>> l = ['a', 'b', 'c'] >>> l[[0, -1]] ['a', 'c'] For dictionaries it'd even be more useful: d = { 'first_name': 'Frances', 'last_name': 'Allen

Re: Enumerating all 3-tuples

On 21/03/2018 05:14, Steven D'Aprano wrote: On Tue, 13 Mar 2018 23:56:37 +0100, Denis Kasak wrote: [...] The triples can be viewed as a pair of a pair and a natural number: (1,1),1 (1,1),2 (1,1),3 ... (2,1),1 (2,1),2 (2,1),3 ... (1,2),1 (1,2),2 (1,2),3 ... [...] This leads fairly naturally

Re: Enumerating all 3-tuples

On Tue, 13 Mar 2018 23:56:37 +0100, Denis Kasak wrote: [...] > The triples can be viewed as a pair of a pair and a natural number: > > (1,1),1 (1,1),2 (1,1),3 ... > (2,1),1 (2,1),2 (2,1),3 ... > (1,2),1 (1,2),2 (1,2),3 ... [...] > This leads fairly naturally to the implementation. > > from

Re: Enumerating all 3-tuples

numbers were put (in their usual ordering) on the horizontal axis and the 2-tuples given by the pairing function on the vertical axis. However, diagonalizing this grid allows us to enumerate the Cartesian product itself, which means we can repeat the process by using this enumeration

Re: Enumerating all 3-tuples (Posting On Python-List Prohibited)

writes: >>>> >>>> The original problem -- triples of natural numbers -- is >>>> not particularly hard, but the general problem -- enumerating n-tuples >>>> of some sequence -- is more interesting because it is a bit harder. >>> >>> It

Re: Enumerating all 3-tuples (Posting On Python-List Prohibited)

Lawrence D’Oliveiro writes: > On Wednesday, March 14, 2018 at 2:18:24 PM UTC+13, Ben Bacarisse wrote: >> Lawrence D’Oliveiro writes: >> >> The original problem -- triples of natural numbers -- is >> not particularly hard, but the general problem -- enumerating n-tuple

Re: Enumerating all 3-tuples

On 2018-03-10 02:13, Steven D'Aprano wrote: But I've stared at this for an hour and I can't see how to extend the result to three coordinates. I can lay out a grid in the order I want: 1,1,1 1,1,2 1,1,3 1,1,4 ... 2,1,1 2,1,2 2,1,3 2,1,4 ... 1,2,1 1,2,2 1,2,3 1,2,4 ... 3,

Re: Enumerating all 3-tuples (Posting On Python-List Prohibited)

Lawrence D’Oliveiro writes: > On Tuesday, March 13, 2018 at 1:58:48 PM UTC+13, Ben Bacarisse wrote: >> Of course you can always generate n-tuples of N and then map these to >> n-tuples of the intended sequence but that seems inelegant. > > This whole discussion seems to be

Re: Enumerating all 3-tuples

On 13/03/2018 11:14, Steven D'Aprano wrote: On Mon, 12 Mar 2018 13:17:15 +, Robin Becker wrote: It's possible to generalize the cantor pairing function to triples, but that may not give you what you want. Effectively you can generate an arbitrary number of triples using an iterative method.

Re: Enumerating all 3-tuples

On 10-03-18 02:13, Steven D'Aprano wrote: > I am trying to enumerate all the three-tuples (x, y, z) where each of x, > y, z can range from 1 to ∞ (infinity). > > This is clearly unhelpful: > > for x in itertools.count(1): > for y in itertools.count(1): >

Re: Enumerating all 3-tuples

On 13 March 2018 at 11:01, Steven D'Aprano wrote: > On Sat, 10 Mar 2018 11:15:49 +, Paul Moore wrote: > >> On 10 March 2018 at 02:18, MRAB wrote: > [...] >>> This might help, although the order they come out might not be what you >>> want: >>> >>> def triples(): >>> for total in itertools

Re: Enumerating all 3-tuples

On Mon, 12 Mar 2018 13:17:15 +, Robin Becker wrote: > It's possible to generalize the cantor pairing function to triples, but > that may not give you what you want. Effectively you can generate an > arbitrary number of triples using an iterative method. My sample code > looked like this > >

Re: Enumerating all 3-tuples (Posting On Python-List Prohibited)

On Sun, 11 Mar 2018 01:40:01 +, Ben Bacarisse wrote: > I'm sure deep recursion is not needed, it's just tricky translating from > a lazy language when one is not familiar with all the iterator > facilities in Python. For example, I couldn't find an append operation > that returns an iterable.

Re: Enumerating all 3-tuples

On Sat, 10 Mar 2018 11:15:49 +, Paul Moore wrote: > On 10 March 2018 at 02:18, MRAB wrote: [...] >> This might help, although the order they come out might not be what you >> want: >> >> def triples(): >> for total in itertools.count(1): >> for i in range(1, total): >>

Re: Enumerating all 3-tuples

On 12/03/2018 18:05, Chris Angelico wrote: On Tue, Mar 13, 2018 at 2:54 AM, Robin Becker wrote: On 12/03/2018 13:17, Robin Becker wrote: An alternative approach gives more orderly sequences using a variable base number construction 4 (0, 0, 1) 9 (0, 0, 1) 18 (0, 0, 2) 32 (0, 0, 2) I spy dup

Re: Enumerating all 3-tuples (Posting On Python-List Prohibited)

course you can always generate n-tuples of N and then map these to n-tuples of the intended sequence but that seems inelegant. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list

Re: Enumerating all 3-tuples

On Tue, Mar 13, 2018 at 5:42 AM, Skip Montanaro wrote: 4 (0, 0, 1) 9 (0, 0, 1) 18 (0, 0, 2) 32 (0, 0, 2) >> >> I spy duplicates. > > I didn't realize we'd started playing "I Spy." > We're actually playing Calvinball, but don't tell the others. ChrisA -- https://mail.python.

Re: Enumerating all 3-tuples

>>> 4 (0, 0, 1) >>> 9 (0, 0, 1) >>> 18 (0, 0, 2) >>> 32 (0, 0, 2) > > I spy duplicates. I didn't realize we'd started playing "I Spy ." ​ ​ Skip -- https://mail.python.org/mailman/listinfo/python-list

Re: Enumerating all 3-tuples

On Tue, Mar 13, 2018 at 2:54 AM, Robin Becker wrote: > On 12/03/2018 13:17, Robin Becker wrote: > An alternative approach gives more orderly sequences using a variable base > number construction > >> 4 (0, 0, 1) >> 9 (0, 0, 1) >> 18 (0, 0, 2) >> 32 (0, 0, 2) I spy duplicates. ChrisA -- https://

Re: Enumerating all 3-tuples

On 12/03/2018 13:17, Robin Becker wrote: It's possible to generalize the cantor pairing function to triples, but that may not give you what you want. Effectively you can generate an arbitrary number of triples using an iterative method. My sample code looked like this ct mapping of non-negat

Re: Enumerating all 3-tuples

On 10 Mar 2018, Paul Moore wrote (in article): > On 10 March 2018 at 02:18, MRAB wrote: > > On 2018-03-10 01:13, Steven D'Aprano wrote: > > > > > > I am trying to enumerate all the three-tuples (x, y, z) where each of x, > > > y, z can range from 1 to

Re: Enumerating all 3-tuples

It's possible to generalize the cantor pairing function to triples, but that may not give you what you want. Effectively you can generate an arbitrary number of triples using an iterative method. My sample code looked like this import math def cantor_pair(k1,k2): return (((k1+k2)*(k1+k

Re: Enumerating all 3-tuples (Posting On Python-List Prohibited)

to a depth equal to the length of > the tuples. The ordering is done based on the maximum value of any > element of the tuple. I'm sure deep recursion is not needed, it's just tricky translating from a lazy language when one is not familiar with all the iterator facilities in

Re: Enumerating all 3-tuples

bartc writes: > On 10/03/2018 20:06, Ben Bacarisse wrote: >>> On 10/03/2018 14:23, Ben Bacarisse wrote: Off topic: I knocked up this Haskell version as a proof-of-concept: import Data.List pn n l = pn' n (map (:[]) l) where pn' n lists | n == 1

Re: Enumerating all 3-tuples

On 10/03/2018 20:06, Ben Bacarisse wrote: bartc writes: [repost as original seems to have gone to email; my newsreader has somehow acquired a 'Reply' button where 'Followup' normally goes.] [I thought it was intended but my reply bounced.] On 10/03/2018 14:23, Ben Bacarisse wrote: Ben Bac

Re: Enumerating all 3-tuples

bartc writes: > [repost as original seems to have gone to email; my newsreader has > somehow acquired a 'Reply' button where 'Followup' normally goes.] [I thought it was intended but my reply bounced.] > On 10/03/2018 14:23, Ben Bacarisse wrote: >> Ben Bacarisse writes: > >> Off topic: I knock

Re: Enumerating all 3-tuples

[repost as original seems to have gone to email; my newsreader has somehow acquired a 'Reply' button where 'Followup' normally goes.] On 10/03/2018 14:23, Ben Bacarisse wrote: Ben Bacarisse writes: Off topic: I knocked up this Haskell version as a proof-of-concept: import Data.List

Re: Enumerating all 3-tuples

Sorry for following up to myself again... Ben Bacarisse writes: >> ... But I think that is an easier way (no code yet though!) unless >> you are set on one particular enumeration: consider the triple as a pair >> one element of which runs over the enumeration of pairs you already >> have. Thi

Re: Enumerating all 3-tuples

Ben Bacarisse writes: > Steven D'Aprano writes: > >> I am trying to enumerate all the three-tuples (x, y, z) where each of x, >> y, z can range from 1 to ∞ (infinity). > ... But I think that is an easier way (no code yet though!) unless > you are set on one par

  1   2   3   4   5   6   7   8   9   10   >