Diez B. Roggisch wrote:
>> For sets, I presume they are built on top of or like dicts, and
>> there is nothing crazy in the low level implementation so that I can
>> be guaranteed that if I don't alter the set, then the order,
>> although arbitrary, will be maintained in successive iterations over
Suresh Pillai wrote:
> On Mon, 28 Jul 2008 16:48:28 +0200, Suresh Pillai wrote:
>
>> Okay, please consider this my one absolutely stupid post for the year.
>> I'd like to pretend it never happened but unfortunately the web doesn't
>> allow that. Having never used sets, I unfort read something th
On Mon, 28 Jul 2008 16:48:28 +0200, Suresh Pillai wrote:
> Okay, please consider this my one absolutely stupid post for the year.
> I'd like to pretend it never happened but unfortunately the web doesn't
> allow that. Having never used sets, I unfort read something that lead
> to it, but ...
Oka
On Mon, 28 Jul 2008 15:04:43 +0200, Suresh Pillai wrote:
> On Mon, 28 Jul 2008 10:44:18 +0200, Suresh Pillai wrote:
>
>> Since I am doing A LOT of loops over the nodes and the number of nodes
>> is also huge, my concern using sets is that in order to iterate over
>> the set in each step of my sim
On Mon, 28 Jul 2008 15:04:43 +0200, Suresh Pillai wrote:
> I could of course use the old trick of using a dictionary with 'None'
> values and then using iterkeys(). But I thought sets were supposed to
> replace this. So maybe I should be asking a more basic question: is
> there any way to iterat
Suresh Pillai <[EMAIL PROTECTED]> wrote:
> [ ... ] is
>there any way to iterate over the items in a set other than converting to
>a list or using the pop() method.
Er, how about directly iterating over the set?
--
\S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/
"Frankly I have no
On Mon, 28 Jul 2008 10:44:18 +0200, Suresh Pillai wrote:
> Since I am doing A LOT of loops over the nodes and the number of nodes
> is also huge, my concern using sets is that in order to iterate over the
> set in each step of my simulation, the set items need to be converted to
> a list every tim
Suresh Pillai:
> Or 4, since the order of my nodes doesn't matter: swap the node to be
> deleted with the last node in the list and then remove the last node of
> the list. This is the fastest to date, if using native structures, for
> low number nodes being deleted per cycle (def if only deletin
On Fri, 25 Jul 2008 17:05:27 -0400, Terry Reedy wrote:
> If the nodes do not have to be processed in any particular order, then
> you could keep them either in a dict, with the value being either On or
> Off (True,False)(plus connection data) or a pair of sets, one for On and
> one for Off. The a
On Fri, 25 Jul 2008 05:46:56 -0700, Iain King wrote:
> or 3. build a new list every iteration intead of deleting from the old
> one:
>
> while processing:
> new_off_list = []
> for x in off_list:
> if goes_on(x):
> on_list.append(x)
> else:
> new_of
On Fri, 25 Jul 2008 09:22:06 -0600, Matthew Fitzgibbons wrote:
> As for different data structures, it largely depends on how you need to
> access the data. If you don't need to index the data, just loop through
> it, you might try a linked list. The performance hit in (2) is coming
> from the list
On Fri, 25 Jul 2008 08:08:57 -0700, Iain King wrote:
> On Jul 25, 3:39 pm, Suresh Pillai <[EMAIL PROTECTED]> wrote:
>> That's a good comparison for the general question I posed. Thanks.
>> Although I do believe lists are less than ideal here and a different
>> data structure should be used.
>>
>>
> The number of nodes is very large: millions for sure, maybe tens
> of millions. If considering (2), take note of my BOLD text above, which
> means I can't remove nodes as I iterate through them in the main loop.
Since your use of 'node' is pretty vague and I don't have a good sense
of what test
Suresh Pillai wrote:
I am performing simulations on networks (graphs). I have a question on
speed of execution (assuming very ample memory for now). I simplify the
details of my simulation below, as the question I ask applies more
generally than my specific case. I would greatly appreciate
Iain King wrote:
On Jul 25, 4:22 pm, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote:
It seems like the probability calculation applies to all three equally,
and can therefore be ignored for the simulations.
The probability affects (1) more. My reasoning for this being: as
probability gets low
2008/7/25 Suresh Pillai <[EMAIL PROTECTED]>:
> ...
> I naturally started coding with (2), but couldn't decide on the best data
> structure for python. A set seemed ideal for speedy removal, but then I
> can't iterate through them with out popping. An ordered list? Some
> creative solution wi
On Jul 25, 4:22 pm, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote:
> It seems like the probability calculation applies to all three equally,
> and can therefore be ignored for the simulations.
The probability affects (1) more. My reasoning for this being: as
probability gets lower the number of
Suresh Pillai wrote:
That's a good comparison for the general question I posed. Thanks.
Although I do believe lists are less than ideal here and a different data
structure should be used.
To be more specific to my case:
As mentioned in my original post, I also have the specific condition tha
On Jul 25, 3:39 pm, Suresh Pillai <[EMAIL PROTECTED]> wrote:
> That's a good comparison for the general question I posed. Thanks.
> Although I do believe lists are less than ideal here and a different data
> structure should be used.
>
> To be more specific to my case:
> As mentioned in my origina
On Fri, 25 Jul 2008 16:51:42 +0200, Fredrik Lundh wrote:
> Unless I'm missing something, your example keeps going until it's
> flagged *all* nodes as "on", which, obviously, kills performance for the
> first version as the probability goes down. The OP's question was about
> a single pass (but he
Iain King wrote:
I think (2)'s poor performance is being amplified by how python
handles lists and list deletions; the effect may be stymied in other
languages
Delete is O(n) (or "O(n/2) on average", if you prefer), while append is
amortized O(1).
Unless I'm missing something, your example
That's a good comparison for the general question I posed. Thanks.
Although I do believe lists are less than ideal here and a different data
structure should be used.
To be more specific to my case:
As mentioned in my original post, I also have the specific condition that
one does not know wh
On Jul 25, 9:54 pm, Jeff <[EMAIL PROTECTED]> wrote:
> Look at using reduce(). You can collect information about all of the
> nodes without necessarily building a large, intermediate list in the
> process.
>From the OP's description, I assumed there'd be a list of all nodes,
from which he wishes t
On Jul 25, 1:46 pm, Iain King <[EMAIL PROTECTED]> wrote:
> On Jul 25, 10:57 am, Suresh Pillai <[EMAIL PROTECTED]> wrote:
>
>
>
> > I am performing simulations on networks (graphs). I have a question on
> > speed of execution (assuming very ample memory for now). I simplify the
> > details of my s
On Jul 25, 10:57 am, Suresh Pillai <[EMAIL PROTECTED]> wrote:
> I am performing simulations on networks (graphs). I have a question on
> speed of execution (assuming very ample memory for now). I simplify the
> details of my simulation below, as the question I ask applies more
> generally than my
> I'd recommend using 'filter' and list comprehensions.
Look at using reduce(). You can collect information about all of the
nodes without necessarily building a large, intermediate list in the
process.
You might get some ideas from here [http://en.wikipedia.org/wiki/
Antiobjects].
--
http://ma
On Jul 25, 7:57 pm, Suresh Pillai <[EMAIL PROTECTED]> wrote:
> The nodes in my network may be ON or OFF. The network starts off with
> all nodes in the OFF state. I loop through the nodes. For each node
> that is OFF, I consider some probability of it turning ON based on the
> states of its neig
I am performing simulations on networks (graphs). I have a question on
speed of execution (assuming very ample memory for now). I simplify the
details of my simulation below, as the question I ask applies more
generally than my specific case. I would greatly appreciate general
feedback in te
28 matches
Mail list logo
