On Monday, June 13, 2016 at 6:56:07 AM UTC+12, Fillmore wrote:
> I then need to run a program that loads the whole forest in the form of a
> dict() where each item will point to a dynamically loaded tree.
Store it in JSON form?
I like language-neutral solutions.
--
https://mail.python.org/mailma
Fillmore writes:
> Hi, problem for today. I have a batch file that creates "trees of data".
> I can save these trees in the form of python code or serialize them with
> something
> like pickle.
>
> I then need to run a program that loads the whole forest in the form
ht tree for
> further processing.
>
How do you determine which tree is suitable? Does it require knowledge of
the whole tree? How big are the trees? How long does pickle take to load
those trees? How frequently does data arrive? How long does it take you to
determine the tree? How long is acceptabl
Hi, problem for today. I have a batch file that creates "trees of data".
I can save these trees in the form of python code or serialize them with
something
like pickle.
I then need to run a program that loads the whole forest in the form of a dict()
where each item will point to a d
On Thursday, January 22, 2015 at 12:46:22 PM UTC+5:30, Paul Rubin wrote:
> Ian Kelly writes:
> > How do you create a tree containing an even number of elements under
> > this constraint?
>
> That's a good point, I've usually seen different definitions of trees,
&g
Ian Kelly writes:
> How do you create a tree containing an even number of elements under
> this constraint?
That's a good point, I've usually seen different definitions of trees,
e.g.
data Tree a = Leaf | Branch a (Tree a) (Tree a)
so a Leaf node doesn't have a val
I would
suggest that an empty tree should be the real base case, since what is
a leaf node but a node where both of its children are empty trees?
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Jan 21, 2015 at 11:56 PM, Ian Kelly wrote:
> Since each element is associated with a node, the question could
> equally be phrased as "How do you create a tree containing an even
> number of elements under this constraint?"
Of course I meant to write "nodes" there, not "elements".
--
htt
On Thursday, January 22, 2015 at 4:25:03 AM UTC+5:30, Ian wrote:
> On Tue, Jan 20, 2015 at 6:23 PM, Rustom Mody wrote:
> > The Haskell is bullseye¹ in capturing the essense of a tree because
> > conceptually a tree of type t is recursive in the sense that it can contain
> > 2 subtrees -- (B x lst r
at; and out of reach of those who think only imperatively
PS
1. Ive not tried it
2. For n-ary trees its neater
3. In my imaginary language with first-class sets, bags, lists it would be
neater still
--
https://mail.python.org/mailman/listinfo/python-list
On Tue, Jan 20, 2015 at 6:23 PM, Rustom Mody wrote:
> The Haskell is bullseye¹ in capturing the essense of a tree because
> conceptually a tree of type t is recursive in the sense that it can contain
> 2 subtrees -- (B x lst rst) -- or its a base case -- L x.
How do you create a tree containing a
Rustom Mody writes:
> Thats not bfs. That's inorder traversal
Oops, you're right. How's this:
bfs x = go [x] where
go [] = []
go (L x:ts) = x:go ts
go (B x lst rst:ts) = x : go (ts ++ [lst, rst])
*Main> bfs t
[6,2,8,1,4,7,9,3,5]
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Jan 21, 2015 at 9:15 AM, Ian Kelly wrote:
> class MultiSet(MutableSet):
In retrospect this probably shouldn't derive from MutableSet, since
that carries the expectation that all elements are unique (much like
how bool shouldn't be subclassed). For instance, collections.Set
includes some o
On Wed, Jan 21, 2015 at 7:47 AM, Steven D'Aprano
wrote:
>> More irksome that for the second we've to preface with
>>
>> from collections import Counter
>>
>> And still more a PITA that a straightforward standard name like bag (or
>> multiset) is called by such an ungoogleable misleading name as co
On Wednesday, January 21, 2015 at 6:06:06 PM UTC+5:30, Chris Angelico wrote:
> On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody wrote:
> > I would like a set to be {1,2,3} or at worst ⦃1,2,3⦄
> > and a bag to be ⟅1,2,3⟆
> >
> > Apart from the unicode niceness that Ive described here
> > http://blog.l
Rustom Mody wrote:
> On Wednesday, January 21, 2015 at 1:27:39 PM UTC+5:30, Stephen Hansen
> wrote:
[...]
> Among my teachers of CS, there were two – both brilliant — one taught me
> Numerical Analysis, the other taught me programming.
I wonder just how brilliant the Numerical Analysis guy really
On Thu, Jan 22, 2015 at 1:26 AM, Tim Chase
wrote:
> While 2.0 is certainly antiquated, Red Hat Enterprise Linux (RHEL) is
> often considered the best definition of what's considered "oldest
> supported production environment". RHEL v4 ships with Py2.3 and one
> can still obtain extended support f
On 2015-01-22 00:01, Chris Angelico wrote:
> On Wed, Jan 21, 2015 at 11:55 PM, Tim Chase
>>> Looks like {1,2,3} works for me.
>>
>> That hasn't always worked:
>
> the argument's still fairly weak when it's alongside a pipe-dream
> desire to use specific mathematical Unicode characters in source
>
Hello Terry,
It is not play with words. A tree is a recursive - nested -
hierachical
data structure with the restriction of no cycles or alternate
pathways.
Python collections whose members are general objects, including
collections, can be nested. The resulting structures *are* tree
structures
On Wed, Jan 21, 2015 at 11:55 PM, Tim Chase
wrote:
> On 2015-01-21 23:35, Chris Angelico wrote:
>> On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody wrote
>> > Its a bit of a nuisance that we have to write set([1,2,3]) for
>> > the first
>>
>> Looks like {1,2,3} works for me.
>
> That hasn't always wo
On 2015-01-21 23:35, Chris Angelico wrote:
> On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody wrote
> > Its a bit of a nuisance that we have to write set([1,2,3]) for
> > the first
>
> Wait, what?
>
> rosuav@sikorsky:~$ python
> Python 2.7.3 (default, Mar 13 2014, 11:03:55)
> [GCC 4.7.2] on linux2
>
On Wed, Jan 21, 2015 at 11:09 PM, Rustom Mody wrote:
> I would like a set to be {1,2,3} or at worst ⦃1,2,3⦄
> and a bag to be ⟅1,2,3⟆
>
> Apart from the unicode niceness that Ive described here
> http://blog.languager.org/2014/04/unicoded-python.html
>
> Its a bit of a nuisance that we have to wri
On Wednesday, January 21, 2015 at 1:27:39 PM UTC+5:30, Stephen Hansen wrote:
> On Tue, Jan 20, 2015 at 1:45 AM, Marko Rauhamaa wrote:
> Terry Reedy :
>
>
>
> > Others have answered as to why other special-purpose
>
> > constrained-structure trees hav
Stephen Hansen :
> On Tue, Jan 20, 2015 at 1:45 AM, Marko Rauhamaa wrote:
>> Terry Reedy :
>> > Others have answered as to why other special-purpose
>> > constrained-structure trees have not been added to the stdlib.
>>
>> Ordered O(log n) mappings are n
and a
library (even the standard library) doesn't have to expose which one
was picked as long as the performance is good.
-- Devin
On Tue, Jan 20, 2015 at 12:15 PM, Ken Seehart wrote:
Exactly. There are over 23,000 different kinds of trees. There's no way you
could get all of them to f
On Tue, Jan 20, 2015 at 1:45 AM, Marko Rauhamaa wrote:
> Terry Reedy :
>
> > Others have answered as to why other special-purpose
> > constrained-structure trees have not been added to the stdlib.
>
> Ordered O(log n) mappings are not special-purpose data structures. I&#x
On Tue, Jan 20, 2015 at 5:22 PM, Joshua Landau wrote:
> On 20 January 2015 at 04:21, Dan Stromberg wrote:
>> On Mon, Jan 19, 2015 at 6:46 PM, Mark Lawrence
>> wrote:
>>>
>>> I don't know if you've seen this http://kmike.ru/python-data-structures/ but
>>> maybe of interest.
>>
>> I've seen it. I
On 21/01/2015 01:22, Joshua Landau wrote:
On 20 January 2015 at 04:21, Dan Stromberg wrote:
On Mon, Jan 19, 2015 at 6:46 PM, Mark Lawrence wrote:
I don't know if you've seen this http://kmike.ru/python-data-structures/ but
maybe of interest.
I've seen it. It's a nice page.
I attempted to
On 1/20/2015 4:47 PM, Mario wrote:
In article ,
rustompm...@gmail.com says...
Yeah python has trees alright.
Heres' some simple tree-code
Didn't you just demonstrate that Python has no trees and instead you
have to implement them yourself (or use a third-party implementation)?
I
On Wednesday, January 21, 2015 at 7:19:39 AM UTC+5:30, Paul Rubin wrote:
> Rustom Mody writes:
> > ## The depth first algorithm
> > dfs (L x) = [x]
> > dfs (B x lst rst) = [x] ++ dfs lst ++ dfs rst
>
> Cute. I can't resist posting the similar breadth first algorithm:
>
> bfs (L x) = [x]
Rustom Mody writes:
> ## The depth first algorithm
> dfs (L x) = [x]
> dfs (B x lst rst) = [x] ++ dfs lst ++ dfs rst
Cute. I can't resist posting the similar breadth first algorithm:
bfs (L x) = [x]
bfs (B x lst rst) = bfs lst ++ [x] ++ bfs rst
> *Main> dfs t
> [6,2,1,4,3,5,8,7,9]
*
On Wednesday, January 21, 2015 at 3:18:03 AM UTC+5:30, Mario wrote:
> rustompmody says...
> >
> > Yeah python has trees alright.
> >
> > Heres' some simple tree-code
>
> Didn't you just demonstrate that Python has no trees and instead you
> have to
On 20 January 2015 at 04:21, Dan Stromberg wrote:
> On Mon, Jan 19, 2015 at 6:46 PM, Mark Lawrence
> wrote:
>>
>> I don't know if you've seen this http://kmike.ru/python-data-structures/ but
>> maybe of interest.
>
> I've seen it. It's a nice page.
>
> I attempted to get my treap port in there s
On 20/01/15 01:49, Dan Stromberg wrote:
I think probably the most common need for a tree is implementing a
cache,
That is probably true, at least if you're a squirrel.
--
https://mail.python.org/mailman/listinfo/python-list
In article ,
rustompm...@gmail.com says...
>
> Yeah python has trees alright.
>
> Heres' some simple tree-code
Didn't you just demonstrate that Python has no trees and instead you
have to implement them yourself (or use a third-party implementation)?
I don't know w
Paul Rubin :
> You could look up the "timer wheel" approach used by the Linux kernel
> and by Erlang. It's less general than an ordered map, but probably
> faster in practice.
>
> https://lkml.org/lkml/2005/10/19/46
>
> Has some info. I think the kernel uses a different method now though.
I
Paul Rubin :
> Marko Rauhamaa writes:
>> So in my Python software (both at work and at home) needs, I use a
>> Python AVL tree implementation of my own. My use case is timers. (GvR
>> uses heapq for the purpose.)
>
> Have you benchmarked your version against heapq or even the builtin
> sorting fu
On Wed, Jan 21, 2015 at 7:15 AM, Ken Seehart wrote:
> Exactly. There are over 23,000 different kinds of trees. There's no way you
> could get all of them to fit in a library, especially a standard one.
> Instead, we prefer to provide people with the tools they need to grow their
>
ce is good.
-- Devin
On Tue, Jan 20, 2015 at 12:15 PM, Ken Seehart wrote:
> Exactly. There are over 23,000 different kinds of trees. There's no way you
> could get all of them to fit in a library, especially a standard one.
> Instead, we prefer to provide people with the tools they
Exactly. There are over 23,000 different kinds of trees. There's no way
you could get all of them to fit in a library, especially a standard
one. Instead, we prefer to provide people with the tools they need to
grow their own trees.
http://caseytrees.org/programs/planting/ctp/
On Tuesday, January 20, 2015 at 11:46:11 PM UTC+5:30, Rustom Mody wrote:
> On Tuesday, January 20, 2015 at 10:51:13 PM UTC+5:30, Ian wrote:
> > On Tue, Jan 20, 2015 at 6:33 AM, Rustom Mody wrote:
> > > # Converting to generators is trivial
> > > =
> >
> > :-)
>
> Less trivial
Marko Rauhamaa writes:
> As I said, I use ordered mappings to implement timers... The downside
> of heapq is that canceled timers often flood the heapq structure...,
> GvR mentioned a periodic "garbage collection" as a potentially
> effective solution.
You could look up the "timer wheel" approac
elf): return self.name
> >
> > I = TreeTag.I
> > L = TreeTag.L
>
> Explicitly tagging nodes as internal or leaves is kind of ugly and
> also prone to getting out of sync with the reality, which is that a
> node is a leaf if it doesn't have any other nodes hanging off of
is immutable and you insert
or delete nodes in O(log n) operations, by creating new trees that share
almost all their data with the old tree. Once you release the old root,
garbage collection frees any nodes that were in the old tree but not the
new one.
Use case inspired by Haskell's Happst
Marko Rauhamaa writes:
> So in my Python software (both at work and at home) needs, I use a
> Python AVL tree implementation of my own. My use case is timers. (GvR
> uses heapq for the purpose.)
Have you benchmarked your version against heapq or even the builtin
sorting functions?
--
https://mai
On Tue, Jan 20, 2015 at 6:33 AM, Rustom Mody wrote:
> from enum import Enum
> class TreeTag(Enum):
> I = 0 # An internal node
> L = 1 # A leaf node
> def __repr__(self): return self.name
>
> I = TreeTag.I
> L = TreeTag.L
Explicitly tagging nodes as internal or leaves is kind of ugl
On Tuesday, January 20, 2015 at 7:46:02 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
>
> > Yeah python has trees alright.
>
> Does Python balance them for you?
No
Does python support a menagerie of lists like C
- singly linked, doubly linked, with header, without head
On 20/01/2015 05:19, Marko Rauhamaa wrote:
Mark Lawrence :
On 19/01/2015 22:06, Zachary Gilmartin wrote:
Why aren't there trees in the python standard library?
Probably because you'd never get agreement as to which specific tree
and which specific implementation was the most su
Rustom Mody :
> Yeah python has trees alright.
Does Python balance them for you?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Jan 19, 2015 at 6:46 PM, Mark Lawrence
wrote:
> I don't know if you've seen this http://kmike.ru/python-data-structures/
> but maybe of interest.
>
I haven't read but also possibly of interest:
Data Structures and Algorithms in Python by Michael T. Goodrich, Roberto
Tamassia, Michael H.
On Tuesday, January 20, 2015 at 7:03:56 PM UTC+5:30, Rustom Mody wrote:
> On Tuesday, January 20, 2015 at 11:38:27 AM UTC+5:30, Terry Reedy wrote:
> > On 1/19/2015 5:06 PM, Zachary Gilmartin wrote:
> > > Why aren't there trees in the python standard library?
> >
On Tuesday, January 20, 2015 at 11:38:27 AM UTC+5:30, Terry Reedy wrote:
> On 1/19/2015 5:06 PM, Zachary Gilmartin wrote:
> > Why aren't there trees in the python standard library?
>
> Sequences nested withing sequences can be regarded as trees, and Python
> has these.
Terry Reedy :
> Others have answered as to why other special-purpose
> constrained-structure trees have not been added to the stdlib.
Ordered O(log n) mappings are not special-purpose data structures. I'd
say strings and floats are much more special-purpose than ordered
mappings, and
On Mon, Jan 19, 2015 at 11:52 PM, Devin Jeanpierre
wrote:
> On Mon, Jan 19, 2015 at 3:08 PM, Steven D'Aprano
> wrote:
>> Zachary Gilmartin wrote:
>>
>>> Why aren't there trees in the python standard library?
>>
>> Possibly because they aren'
On 1/19/2015 5:06 PM, Zachary Gilmartin wrote:
Why aren't there trees in the python standard library?
Sequences nested withing sequences can be regarded as trees, and Python
has these. I regard Lisp as a tree processing languages, as it must be
to manipulate, for example, code with n
Mark Lawrence :
> On 19/01/2015 22:06, Zachary Gilmartin wrote:
>> Why aren't there trees in the python standard library?
>
> Probably because you'd never get agreement as to which specific tree
> and which specific implementation was the most suitable for inclusion.
PM, Zachary Gilmartin
> >> wrote:
> >>>
> >>> Why aren't there trees in the python standard library?
> >>
> >>
> >> Trees are kind of specialized datastructures; no one type of tree
> >> solves all tree-related problems suita
On Mon, Jan 19, 2015 at 6:46 PM, Mark Lawrence wrote:
> On 20/01/2015 00:49, Dan Stromberg wrote:
>>
>> On Mon, Jan 19, 2015 at 2:06 PM, Zachary Gilmartin
>> wrote:
>>>
>>> Why aren't there trees in the python standard library?
>>
>>
>
On 20/01/2015 00:49, Dan Stromberg wrote:
On Mon, Jan 19, 2015 at 2:06 PM, Zachary Gilmartin
wrote:
Why aren't there trees in the python standard library?
Trees are kind of specialized datastructures; no one type of tree
solves all tree-related problems suitably well.
I think probabl
On Mon, Jan 19, 2015 at 2:06 PM, Zachary Gilmartin
wrote:
> Why aren't there trees in the python standard library?
Trees are kind of specialized datastructures; no one type of tree
solves all tree-related problems suitably well.
I think probably the most common need for a tree is implem
In article ,
zacharygilmar...@gmail.com says...
>
> Why aren't there trees in the python standard library?
I don't know much about python development process and strategies, but I
suspect it shouldn't be much different from any other language I know
of. So here's
On 2015-01-19 16:19, Michael Torrie wrote:
> On 01/19/2015 04:08 PM, Steven D'Aprano wrote:
> > Zachary Gilmartin wrote:
> >> Why aren't there trees in the python standard library?
> >
> > Possibly because they aren't needed? Under what circumstances
On Mon, Jan 19, 2015 at 3:08 PM, Steven D'Aprano
wrote:
> Zachary Gilmartin wrote:
>
>> Why aren't there trees in the python standard library?
>
> Possibly because they aren't needed? Under what circumstances would you use
> a tree instead of a list or a dic
On 01/19/2015 04:08 PM, Steven D'Aprano wrote:
> Zachary Gilmartin wrote:
>
>> Why aren't there trees in the python standard library?
>
> Possibly because they aren't needed? Under what circumstances would you use
> a tree instead of a list or a dict or co
Zachary Gilmartin wrote:
> Why aren't there trees in the python standard library?
Possibly because they aren't needed? Under what circumstances would you use
a tree instead of a list or a dict or combination of both?
That's not a rhetorical question. I am genuinely curious
On 19/01/2015 22:06, Zachary Gilmartin wrote:
Why aren't there trees in the python standard library?
Probably because you'd never get agreement as to which specific tree and
which specific implementation was the most suitable for inclusion.
--
My fellow Pythonistas, ask no
On Tue, Jan 20, 2015 at 9:16 AM, Ben Finney wrote:
> If you're asking because you think all data structures magically appear
> in the standard library by wishing it so, I think you over-estimate the
> powers of the standard library maintainers.
Oh come on Ben. Guido has a time machine; TimSort is
Zachary Gilmartin writes:
> Why aren't there trees in the python standard library?
What sort of answer are you looking for? There are many ways that
question could be intended.
If you're asking about what could be keeping a particular tree
implementation out of the standard
Why aren't there trees in the python standard library?
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Mar 19, 2014 at 7:16 PM, Rhodri James wrote:
> 65536 is a suspiciously round number. You might want to double-
> check that there's no 16-bit overflow causing something unexpected.
It's because I'm using powers of 2. All the numbers in the report are
round in hex.
--
https://mail.pytho
On Tue, 18 Mar 2014 21:45:52 -, Dan Stromberg
wrote:
blist.sorteddict was able to do 65536 operations on a dictionary
before taking more than 120 seconds to complete - it took 77.3
seconds to do 65536 operations.
65536 is a suspiciously round number. You might want to double-
check th
structure.
How about this test program:
I used to do essentially this, but it was time-prohibitive and produced
harder-to-read graphs - harder to read because the enormous values of
the bad trees were dwarfing the values of the good trees.
A log graph may be the solution to that: graph the log o
d?
Those are obviously not random, and using them as a keys in a balanced
tree would give you sub-optimum performance.
This is not a hypothetical scenario. Songza uses MongoDB as our
database. The indexes are balanced trees. One of our biggest
collections has a multi-component key, one of th
Steven D'Aprano :
> Please re-read what I wrote. I didn't say "if your data comes to you
> fully randomized". I said "if you are in a position to randomize the
> data before storing it". In other words, if you actively randomize the
> data yourself.
Yes, you could implement a "hash table" that wa
nerate
performance than the worst-case poor performance.
> In fact, Dan himself said unbalanced trees performed so badly he
> couldn't test them satisfactorily.
You're misrepresenting what Dan said. What he actually said was that
unbalanced trees perform second only to dicts with
ty of
worst-case ordering.
In fact, Dan himself said unbalanced trees performed so badly he
couldn't test them satisfactorily.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
>
>> How about this test program:
>
> I used to do essentially this, but it was time-prohibitive and produced
> harder-to-read graphs - harder to read because the enormous values of
> the bad trees were dwarfing the values of the good trees.
A log graph may be the solution to tha
On Wed, 19 Mar 2014 01:11:33 +0200, Marko Rauhamaa wrote:
> Dan Stromberg :
>> Rather than throw out unbalanced binary tree altogether, it makes more
>> sense to run it until it gets "too slow".
>
> I disagree strongly. You should throw out unbalanced binary t
>
> On Tue, Mar 18, 2014 at 1:55 PM, Marko Rauhamaa wrote:
>
Dan Stromberg :
>> > The results are at
>> >
>> http://stromberg.dnsalias.org/~strombrg/python-tree-and-heap-comparison/2014-03/
>
>
Size: 1048576, duration: 75.3, dictionary type: dict
> [...]
> Size: 262144, duration: 66.
t; I used to do essentially this, but it was time-prohibitive and
> produced harder-to-read graphs - harder to read because the enormous
> values of the bad trees were dwarfing the values of the good trees.
>
> Imagine doing 1 operation tests for the unbalanced binary
> tree. Fo
time-prohibitive and
produced harder-to-read graphs - harder to read because the enormous
values of the bad trees were dwarfing the values of the good trees.
Imagine doing 1 operation tests for the unbalanced binary
tree. For a series of random keys, it would do quite well (probably
second only
Dan Stromberg :
> dict was able to do 1048576 operations on a dictionary before taking
> more than 120 seconds to complete - it took 75.3 seconds to do 1048576
> operations.
>
> AVL_tree was able to do 262144 operations on a dictionary before
> taking more than 120 seconds to complete - it took 66
re half adding key, value
pairs; and half lookups of values by keys we know are in the
dictionary.
I used to run all the dictionaries for as long as it took to do 4
million operations, but for (EG) unbalanced binary trees, that would
take far too long in the ordered tests, so I changed the code to try a
g
Dan Stromberg :
> The results are at
> http://stromberg.dnsalias.org/~strombrg/python-tree-and-heap-comparison/2014-03/
Unfortunately I'm having a hard time understanding the results.
The 50/50 get/set ratio is most interesting to me.
I'm seeing (under cpython-3.3):
Size: 1048576, duratio
On Mon, Mar 17, 2014 at 3:05 PM, Marko Rauhamaa wrote:
> Joshua Landau :
>
>> The thing we really need is for the blist containers to become stdlib
>> (but not to replace the current list implementation).
>
> Very interesting. Downloaded blist but didn't compile it yet. It *could*
> be the missing
On 18 March 2014 01:01, Daniel Stutzbach wrote:
> I would love to have include macro-benchmarks. I keep waiting for the PyPy
> benchmark suite to get ported to Python 3...
*grins*
>> "Delete a slice" is fudged from its inclusion of multiplication, which
>> is far faster on blists. I admit that
On 17 March 2014 21:16, Daniel Stutzbach wrote:
> On Fri, Mar 14, 2014 at 6:13 PM, Joshua Landau wrote:
>>
>> Now, I understand there are downsides to blist. Particularly, I've
>> looked through the "benchmarks" and they seem untruthful.
>
> I worked hard to make those benchmarks as fair as possi
while (src >= stop)
*dst-- = *src--;
Personally, I find it a bit odd to place lists at the center of the
proposal and have trees come out as a side effect. I would rather see it
the other way round: sorteddict -> sortedset et al.
> * It reduces demand for trees:
I would hope it woul
less significant.
This is very useful when considering usage as a multi-purpose data
structure, and removes demand for explicit linked lists (which have
foolishly been reimplemented loads of times).
* It reduces demand for trees:
* There are efficient implementations of sortedlist, sortedset
This is very useful when considering usage as a multi-purpose data
structure, and removes demand for explicit linked lists (which have
foolishly been reimplemented loads of times).
* It reduces demand for trees:
* There are efficient implementations of sortedlist, sortedset and
sorteddict.
*
On Thu, 13 Mar 2014 20:12:41 -0700, Dan Stromberg wrote:
> Sorting the same (slightly tweaked) data inside of a tight loop is
> rarely a good idea - despite the fact that the "sort" itself tends to be
> O(n) with Python's rather awesome builtin sorting algorithm. This is
> because sorting inside
On Thu, Mar 13, 2014 at 4:57 PM, Steven D'Aprano
wrote:
> On Mon, 10 Mar 2014 19:34:48 +0200, Marko Rauhamaa wrote:
>
>>> With a high level language like Python, using the provided hash table
>>> will almost always cream any hand-built tree, no matter how
>>> advantageous the data is to the tree.
On Mon, 10 Mar 2014 19:34:48 +0200, Marko Rauhamaa wrote:
>> With a high level language like Python, using the provided hash table
>> will almost always cream any hand-built tree, no matter how
>> advantageous the data is to the tree.
>
> The main thing is there are use cases where order is essen
On Mon, Mar 10, 2014 at 11:34 AM, Marko Rauhamaa wrote:
> The main thing is there are use cases where order is essential. That's
> why I have had to implement the AVL tree in Python myself. No biggie,
> but a C implementation would probably be much faster. Also, a standard
> version would likely b
Op 11-03-14 00:24, Roy Smith schreef:
> In article <8761nmrnfk@elektro.pacujo.net>,
> Marko Rauhamaa wrote:
>
>> Anyway, this whole debate is rather unnecessary since every developer is
>> supposed to have both weapons in their arsenal.
> The problem with having a choice is that it opens up
On 11/03/2014 8:12 PM, Marko Rauhamaa wrote:
Python should let skilled professionals do their work. Thankfully, for
the most part, it does.
Skilled professionals don't solely rely on the standard library, either.
If you know you need a balanced tree, you'll also know where to find an
implemen
On Tue, 11 Mar 2014 04:28:25 -, Chris Angelico
wrote:
On Tue, Mar 11, 2014 at 2:38 PM, Ian Kelly wrote:
On Mon, Mar 10, 2014 at 7:45 PM, Chris Angelico
wrote:
No no,
I could make this so much better by using the 80x86 "REP MOVSW"
command (or commands, depending on your point of view)
Steven D'Aprano :
> On Mon, 10 Mar 2014 19:24:07 -0400, Roy Smith wrote:
>
>> In article <8761nmrnfk@elektro.pacujo.net>,
>> Marko Rauhamaa wrote:
>>
>>> Anyway, this whole debate is rather unnecessary since every developer
>>> is supposed to have both weapons in their arsenal.
>>
>> The p
On Mon, 10 Mar 2014 19:24:07 -0400, Roy Smith wrote:
> In article <8761nmrnfk@elektro.pacujo.net>,
> Marko Rauhamaa wrote:
>
>> Anyway, this whole debate is rather unnecessary since every developer
>> is supposed to have both weapons in their arsenal.
>
> The problem with having a choice i
On Tue, Mar 11, 2014 at 1:20 PM, Roy Smith wrote:
> In article <531e6eca$0$29994$c3e8da3$54964...@news.astraweb.com>,
> Steven D'Aprano wrote:
>
>> There's only so much matter in the
>> universe, so talking about limits as the amount of data approaches
>> infinity is nonsense. Where would you st
1 - 100 of 314 matches
Mail list logo
