save dictionary to a file without brackets.

Discussion in 'Python' started by giuseppe.amatulli@gmail.com, Aug 9, 2012.

  1. Guest

    Hi,
    I have a dict() unique
    like this
    {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    4 5 1
    5 4 1
    4 4 2
    2 3 1
    4 3 2
    Any ideas?
    Thanks in advance
    Giuseppe
     
    , Aug 9, 2012
    #1
    1. Advertising

  2. for key in dict:
    print key[0], key[1], dict[key]

    10.08.2012, × 0:11, ÎÁÐÉÓÁÌ(Á):

    > Hi,
    > I have a dict() unique
    > like this
    > {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    > and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    > 4 5 1
    > 5 4 1
    > 4 4 2
    > 2 3 1
    > 4 3 2
    > Any ideas?
    > Thanks in advance
    > Giuseppe
    > --
    > http://mail.python.org/mailman/listinfo/python-list
     
    Roman Vashkevich, Aug 9, 2012
    #2
    1. Advertising

  3. Tim Chase Guest

    On 08/09/12 15:22, Roman Vashkevich wrote:
    >> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >> and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    >> 4 5 1
    >> 5 4 1
    >> 4 4 2
    >> 2 3 1
    >> 4 3 2

    >
    > for key in dict:
    > print key[0], key[1], dict[key]


    This might read more cleanly with tuple unpacking:

    for (edge1, edge2), cost in d.iteritems(): # or .items()
    print edge1, edge2, cost

    (I'm making the assumption that this is a edge/cost graph...use
    appropriate names according to what they actually mean)

    -tkc
     
    Tim Chase, Aug 9, 2012
    #3
  4. Gelonida N Guest

    On 08/09/2012 10:11 PM, wrote:
    > Hi,
    > I have a dict() unique
    > like this
    > {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    > and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    > 4 5 1
    > 5 4 1
    > 4 4 2
    > 2 3 1
    > 4 3 2
    > Any ideas?
    > Thanks in advance
    > Giuseppe
    >

    Boring explicit solution:

    d = {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    for key, val in d.items():
    v1,v2 = key
    fout.write("%d %d %d\n" % (v1, v2, val))
     
    Gelonida N, Aug 9, 2012
    #4
  5. thanks for the fast replies
    my testing were very closed to yours but i did not know how

    On 9 August 2012 15:25, Oscar Benjamin <> wrote:
    >
    > On Aug 9, 2012 9:17 PM, <> wrote:
    >>
    >> Hi,
    >> I have a dict() unique
    >> like this
    >> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >> and i want to print to a file without the brackets comas and semicolon in
    >> order to obtain something like this?
    >> 4 5 1
    >> 5 4 1
    >> 4 4 2
    >> 2 3 1
    >> 4 3 2
    >> Any ideas?
    >> Thanks in advance

    >
    > How's this?
    >
    > from __future__ import print_function
    >
    > output = open("out.txt", "w")
    >
    > for (a, b), c in d.items():
    > print(a, b, c, file=output)
    >
    > output.close()
    >
    > Oscar.
    >> --
    >> http://mail.python.org/mailman/listinfo/python-list




    --
    Giuseppe Amatulli
    Web: www.spatial-ecology.net
     
    Giuseppe Amatulli, Aug 9, 2012
    #5
  6. thanks for the fast replies
    my testing were very closed to yours but i did not know how to print
    the the number after the semicolon!
    thanks!


    On 9 August 2012 15:25, Oscar Benjamin <> wrote:
    >
    > On Aug 9, 2012 9:17 PM, <> wrote:
    >>
    >> Hi,
    >> I have a dict() unique
    >> like this
    >> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >> and i want to print to a file without the brackets comas and semicolon in
    >> order to obtain something like this?
    >> 4 5 1
    >> 5 4 1
    >> 4 4 2
    >> 2 3 1
    >> 4 3 2
    >> Any ideas?
    >> Thanks in advance

    >
    > How's this?
    >
    > from __future__ import print_function
    >
    > output = open("out.txt", "w")
    >
    > for (a, b), c in d.items():
    > print(a, b, c, file=output)
    >
    > output.close()
    >
    > Oscar.
    >> --
    >> http://mail.python.org/mailman/listinfo/python-list




    --
    Giuseppe Amatulli
    Web: www.spatial-ecology.net
     
    Giuseppe Amatulli, Aug 9, 2012
    #6
  7. dict.items() is a list - linear access time whereas with 'for key in dict:' access time is constant: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#use-in-where-possible-1

    10.08.2012, × 0:35, Tim Chase ÎÁÐÉÓÁÌ(Á):

    > On 08/09/12 15:22, Roman Vashkevich wrote:
    >>> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >>> and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    >>> 4 5 1
    >>> 5 4 1
    >>> 4 4 2
    >>> 2 3 1
    >>> 4 3 2

    >>
    >> for key in dict:
    >> print key[0], key[1], dict[key]

    >
    > This might read more cleanly with tuple unpacking:
    >
    > for (edge1, edge2), cost in d.iteritems(): # or .items()
    > print edge1, edge2, cost
    >
    > (I'm making the assumption that this is a edge/cost graph...use
    > appropriate names according to what they actually mean)
    >
    > -tkc
    >
    >
    >
     
    Roman Vashkevich, Aug 9, 2012
    #7
  8. On 09/08/2012 21:41, Roman Vashkevich wrote:
    > dict.items() is a list - linear access time whereas with 'for key in dict:' access time is constant: http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#use-in-where-possible-1
    >
    > 10.08.2012, × 0:35, Tim Chase ÎÁÐÉÓÁÌ(Á):
    >
    >> On 08/09/12 15:22, Roman Vashkevich wrote:
    >>>> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >>>> and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    >>>> 4 5 1
    >>>> 5 4 1
    >>>> 4 4 2
    >>>> 2 3 1
    >>>> 4 3 2
    >>>
    >>> for key in dict:
    >>> print key[0], key[1], dict[key]

    >>
    >> This might read more cleanly with tuple unpacking:
    >>
    >> for (edge1, edge2), cost in d.iteritems(): # or .items()
    >> print edge1, edge2, cost
    >>
    >> (I'm making the assumption that this is a edge/cost graph...use
    >> appropriate names according to what they actually mean)
    >>
    >> -tkc
    >>
    >>
    >>

    >


    I'm impressed, the OP gives a dict with five entries and already we're
    optimising, a cunning plan if ever there was one. Hum, I think I'll
    start on the blast proof ferro-concrete bunker tonight just in case
    WWIII starts tomorrow.

    --
    Cheers.

    Mark Lawrence.
     
    Mark Lawrence, Aug 9, 2012
    #8
  9. Tim Chase Guest

    On 08/09/12 15:41, Roman Vashkevich wrote:
    > 10.08.2012, × 0:35, Tim Chase ÎÁÐÉÓÁÌ(Á):
    >> On 08/09/12 15:22, Roman Vashkevich wrote:
    >>>> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >>>> and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    >>>> 4 5 1
    >>>> 5 4 1
    >>>> 4 4 2
    >>>> 2 3 1
    >>>> 4 3 2
    >>>
    >>> for key in dict:
    >>> print key[0], key[1], dict[key]

    >>
    >> This might read more cleanly with tuple unpacking:
    >>
    >> for (edge1, edge2), cost in d.iteritems(): # or .items()
    >> print edge1, edge2, cost
    >>
    >> (I'm making the assumption that this is a edge/cost graph...use
    >> appropriate names according to what they actually mean)

    >
    > dict.items() is a list - linear access time whereas with 'for
    > key in dict:' access time is constant:
    > http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#use-in-where-possible-1


    That link doesn't actually discuss dict.{iter}items()

    Both are O(N) because you have to touch each item in the dict--you
    can't iterate over N entries in less than O(N) time. For small
    data-sets, building the list and then iterating over it may be
    faster faster; for larger data-sets, the cost of building the list
    overshadows the (minor) overhead of a generator. Either way, the
    iterate-and-fetch-the-associated-value of .items() & .iteritems()
    can (should?) be optimized in Python's internals to the point I
    wouldn't think twice about using the more readable version.

    -tkc
     
    Tim Chase, Aug 9, 2012
    #9
  10. Actually, they are different.
    Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    Dict uses hashing to get a value from the dict and this is why it's O(1).

    10.08.2012, × 1:21, Tim Chase ÎÁÐÉÓÁÌ(Á):

    > On 08/09/12 15:41, Roman Vashkevich wrote:
    >> 10.08.2012, × 0:35, Tim Chase ÎÁÐÉÓÁÌ(Á):
    >>> On 08/09/12 15:22, Roman Vashkevich wrote:
    >>>>> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >>>>> and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    >>>>> 4 5 1
    >>>>> 5 4 1
    >>>>> 4 4 2
    >>>>> 2 3 1
    >>>>> 4 3 2
    >>>>
    >>>> for key in dict:
    >>>> print key[0], key[1], dict[key]
    >>>
    >>> This might read more cleanly with tuple unpacking:
    >>>
    >>> for (edge1, edge2), cost in d.iteritems(): # or .items()
    >>> print edge1, edge2, cost
    >>>
    >>> (I'm making the assumption that this is a edge/cost graph...use
    >>> appropriate names according to what they actually mean)

    >>
    >> dict.items() is a list - linear access time whereas with 'for
    >> key in dict:' access time is constant:
    >> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#use-in-where-possible-1

    >
    > That link doesn't actually discuss dict.{iter}items()
    >
    > Both are O(N) because you have to touch each item in the dict--you
    > can't iterate over N entries in less than O(N) time. For small
    > data-sets, building the list and then iterating over it may be
    > faster faster; for larger data-sets, the cost of building the list
    > overshadows the (minor) overhead of a generator. Either way, the
    > iterate-and-fetch-the-associated-value of .items() & .iteritems()
    > can (should?) be optimized in Python's internals to the point I
    > wouldn't think twice about using the more readable version.
    >
    > -tkc
    >
    >
     
    Roman Vashkevich, Aug 9, 2012
    #10
  11. Terry Reedy Guest

    On 8/9/2012 5:21 PM, Tim Chase wrote:
    > On 08/09/12 15:41, Roman Vashkevich wrote:
    >> 10.08.2012, в 0:35, Tim Chase напиÑал(а):
    >>> On 08/09/12 15:22, Roman Vashkevich wrote:
    >>>>> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >>>>> and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    >>>>> 4 5 1
    >>>>> 5 4 1
    >>>>> 4 4 2
    >>>>> 2 3 1
    >>>>> 4 3 2
    >>>>
    >>>> for key in dict:
    >>>> print key[0], key[1], dict[key]
    >>>
    >>> This might read more cleanly with tuple unpacking:
    >>>
    >>> for (edge1, edge2), cost in d.iteritems(): # or .items()
    >>> print edge1, edge2, cost
    >>>
    >>> (I'm making the assumption that this is a edge/cost graph...use
    >>> appropriate names according to what they actually mean)

    >>
    >> dict.items() is a list - linear access time whereas with 'for
    >> key in dict:' access time is constant:
    >> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#use-in-where-possible-1

    >
    > That link doesn't actually discuss dict.{iter}items()
    >
    > Both are O(N) because you have to touch each item in the dict--you
    > can't iterate over N entries in less than O(N) time. For small
    > data-sets, building the list and then iterating over it may be
    > faster faster; for larger data-sets, the cost of building the list
    > overshadows the (minor) overhead of a generator. Either way, the
    > iterate-and-fetch-the-associated-value of .items() & .iteritems()
    > can (should?) be optimized in Python's internals to the point I
    > wouldn't think twice about using the more readable version.


    In 3.x, .keys, .values, and .items are set-like read-only views
    specifically designed for iteration. So in 3.x they are THE way to do so
    for whichever alternative is appropriate. Iterating by keys and then
    looking up values instead of yielding the values at the same time is
    extra work.

    --
    Terry Jan Reedy
     
    Terry Reedy, Aug 9, 2012
    #11
  12. Dave Angel Guest

    On 08/09/2012 05:34 PM, Roman Vashkevich wrote:
    > Actually, they are different.
    > Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    > Dict uses hashing to get a value from the dict and this is why it's O(1).


    Sure, that's why

    for key in dict:
    print key[0], key[1], dict[key]

    is probably slower than

    for (edge1, edge2), cost in d.iteritems(): # or .items()
    print edge1, edge2, cost


    So, the latter is both faster and easier to read. Why are you arguing against it?

    Also, please stop top-posting. It's impolite here, and makes it much harder to figure out who is saying what, in what order.



    --

    DaveA
     
    Dave Angel, Aug 9, 2012
    #12
  13. Chris Kaynor Guest

    On Thu, Aug 9, 2012 at 2:34 PM, Roman Vashkevich <> wrote:
    >
    > Actually, they are different.
    > Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    > Dict uses hashing to get a value from the dict and this is why it's O(1).
    >


    Using "in" as an operator such as: "if key in dict" or "result = key
    in dict" is O(1) as you say. Iterating on the dictionary requires
    touching every item, and so is O(n), even though it also using "in" in
    the command.

    Here are a few quick timing tests I just ran with Python 2.6:

    >>> timeit.timeit('for i in d: pass', 'd=dict.fromkeys(range(1))')

    0.078683853332734088
    >>> timeit.timeit('for i in d: pass', 'd=dict.fromkeys(range(10))')

    0.17451784110969015
    >>> timeit.timeit('for i in d: pass', 'd=dict.fromkeys(range(100))')

    1.1708168159579486

    >>> timeit.timeit('for i in d.iteritems(): pass', 'd=dict.fromkeys(range(1))')

    0.14186911440299355
    >>> timeit.timeit('for i in d.iteritems(): pass', 'd=dict.fromkeys(range(10))')

    0.33836512561802579
    >>> timeit.timeit('for i in d.iteritems(): pass', 'd=dict.fromkeys(range(100))')

    2.2544262854249268

    >>> timeit.timeit('for i in d: v=d', 'd=dict.fromkeys(range(1))')

    0.10009793211446549
    >>> timeit.timeit('for i in d: v=d', 'd=dict.fromkeys(range(10))')

    0.38825072496723578
    >>> timeit.timeit('for i in d: v=d', 'd=dict.fromkeys(range(100))')

    3.3020098061049339


    As can be seen here, a 1-item dictionary iterated in 0.07 seconds, 10
    items in 0.17 seconds, and 100 items in 1.17 seconds. That is fairly
    close to linear, especially when considering the overhead of a
    complete no-op

    Using iteritems, it appears to actually scale slightly better than
    linear, though it is slower than just the plain iteration.

    Doing a plain iteration, then looking up the keys to get the values
    also appears to be linear, and is even slower than iteritems.
     
    Chris Kaynor, Aug 9, 2012
    #13
  14. Chris Kaynor Guest

    I realized, I should have done 10, 100, 1000 rather than 1, 10, 100
    for better results, so here are the results for 1000 items. It still
    maintains the same pattern:

    >>> timeit.timeit('for i in d: pass', 'd=dict.fromkeys(range(1000))')

    10.166595947685153
    >>> timeit.timeit('for i in d.iteritems(): pass', 'd=dict.fromkeys(range(1000))')

    19.922474218828711
    >>> timeit.timeit('for i in d: v=d', 'd=dict.fromkeys(range(1000))')

    31.007666660415282

    Chris

    On Thu, Aug 9, 2012 at 2:49 PM, Chris Kaynor <> wrote:
    > On Thu, Aug 9, 2012 at 2:34 PM, Roman Vashkevich <> wrote:
    >>
    >> Actually, they are different.
    >> Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    >> Dict uses hashing to get a value from the dict and this is why it's O(1).
    >>

    >
    > Using "in" as an operator such as: "if key in dict" or "result = key
    > in dict" is O(1) as you say. Iterating on the dictionary requires
    > touching every item, and so is O(n), even though it also using "in" in
    > the command.
    >
    > Here are a few quick timing tests I just ran with Python 2.6:
    >
    >>>> timeit.timeit('for i in d: pass', 'd=dict.fromkeys(range(1))')

    > 0.078683853332734088
    >>>> timeit.timeit('for i in d: pass', 'd=dict.fromkeys(range(10))')

    > 0.17451784110969015
    >>>> timeit.timeit('for i in d: pass', 'd=dict.fromkeys(range(100))')

    > 1.1708168159579486
    >
    >>>> timeit.timeit('for i in d.iteritems(): pass', 'd=dict.fromkeys(range(1))')

    > 0.14186911440299355
    >>>> timeit.timeit('for i in d.iteritems(): pass', 'd=dict.fromkeys(range(10))')

    > 0.33836512561802579
    >>>> timeit.timeit('for i in d.iteritems(): pass', 'd=dict.fromkeys(range(100))')

    > 2.2544262854249268
    >
    >>>> timeit.timeit('for i in d: v=d', 'd=dict.fromkeys(range(1))')

    > 0.10009793211446549
    >>>> timeit.timeit('for i in d: v=d', 'd=dict.fromkeys(range(10))')

    > 0.38825072496723578
    >>>> timeit.timeit('for i in d: v=d', 'd=dict.fromkeys(range(100))')

    > 3.3020098061049339
    >
    >
    > As can be seen here, a 1-item dictionary iterated in 0.07 seconds, 10
    > items in 0.17 seconds, and 100 items in 1.17 seconds. That is fairly
    > close to linear, especially when considering the overhead of a
    > complete no-op
    >
    > Using iteritems, it appears to actually scale slightly better than
    > linear, though it is slower than just the plain iteration.
    >
    > Doing a plain iteration, then looking up the keys to get the values
    > also appears to be linear, and is even slower than iteritems.
     
    Chris Kaynor, Aug 9, 2012
    #14
  15. Thanks a lot for the clarification.
    Actually my problem is giving to raster dataset in geo-tif format find out
    unique pair combination, count the number of observation
    unique combination in rast1, count the number of observation
    unique combination in rast2, count the number of observation

    I try different solution and this seems to me the faster


    Rast00=dsRast00.GetRasterBand(1).ReadAsArray()
    Rast10=dsRast10.GetRasterBand(1).ReadAsArray()

    mask=( Rast00 != 0 ) & ( Rast10 != 0 ) # may be this masking
    operation can be included in the for loop

    Rast00_mask= Rast00[mask] # may be this masking
    operation can be included in the for loop
    Rast10_mask= Rast10[mask] # may be this masking
    operation can be included in the for loop

    array2D = np.array(zip( Rast00_mask,Rast10_mask))

    unique_u=dict()
    unique_k1=dict()
    unique_k2=dict()

    for key1,key2 in array2D :
    row = tuple((key1,key2))
    if row in unique_u:
    unique_u[row] += 1
    else:
    unique_u[row] = 1
    if key1 in unique_k1:
    unique_k1[key1] += 1
    else:
    unique_k1[key1] = 1
    if key2 in unique_k2:
    unique_k2[key2] += 1
    else:
    unique_k2[key2] = 1

    output = open(dst_file_rast0010, "w")
    for (a, b), c in unique_u.items():
    print(a, b, c, file=output)
    output.close()

    output = open(dst_file_rast00, "w")
    for (a), b in unique_k1.items():
    print(a, b, file=output)
    output.close()

    output = open(dst_file_rast10, "w")
    for (a), b in unique_k2.items():
    print(a, b, file=output)
    output.close()

    What do you think? is there a way to speed up the process?
    Thanks
    Giuseppe





    On 9 August 2012 16:34, Roman Vashkevich <> wrote:
    > Actually, they are different.
    > Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    > Dict uses hashing to get a value from the dict and this is why it's O(1).
    >
    > 10.08.2012, в 1:21, Tim Chase напиÑал(а):
    >
    >> On 08/09/12 15:41, Roman Vashkevich wrote:
    >>> 10.08.2012, в 0:35, Tim Chase напиÑал(а):
    >>>> On 08/09/12 15:22, Roman Vashkevich wrote:
    >>>>>> {(4, 5): 1, (5, 4): 1, (4, 4): 2, (2, 3): 1, (4, 3): 2}
    >>>>>> and i want to print to a file without the brackets comas and semicolon in order to obtain something like this?
    >>>>>> 4 5 1
    >>>>>> 5 4 1
    >>>>>> 4 4 2
    >>>>>> 2 3 1
    >>>>>> 4 3 2
    >>>>>
    >>>>> for key in dict:
    >>>>> print key[0], key[1], dict[key]
    >>>>
    >>>> This might read more cleanly with tuple unpacking:
    >>>>
    >>>> for (edge1, edge2), cost in d.iteritems(): # or .items()
    >>>> print edge1, edge2, cost
    >>>>
    >>>> (I'm making the assumption that this is a edge/cost graph...use
    >>>> appropriate names according to what they actually mean)
    >>>
    >>> dict.items() is a list - linear access time whereas with 'for
    >>> key in dict:' access time is constant:
    >>> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#use-in-where-possible-1

    >>
    >> That link doesn't actually discuss dict.{iter}items()
    >>
    >> Both are O(N) because you have to touch each item in the dict--you
    >> can't iterate over N entries in less than O(N) time. For small
    >> data-sets, building the list and then iterating over it may be
    >> faster faster; for larger data-sets, the cost of building the list
    >> overshadows the (minor) overhead of a generator. Either way, the
    >> iterate-and-fetch-the-associated-value of .items() & .iteritems()
    >> can (should?) be optimized in Python's internals to the point I
    >> wouldn't think twice about using the more readable version.
    >>
    >> -tkc
    >>
    >>

    >




    --
    Giuseppe Amatulli
    Web: www.spatial-ecology.net
     
    Giuseppe Amatulli, Aug 9, 2012
    #15
  16. 10.08.2012, × 1:47, Dave Angel ÎÁÐÉÓÁÌ(Á):

    > On 08/09/2012 05:34 PM, Roman Vashkevich wrote:
    >> Actually, they are different.
    >> Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    >> Dict uses hashing to get a value from the dict and this is why it's O(1).

    >
    > Sure, that's why
    >
    > for key in dict:
    > print key[0], key[1], dict[key]
    >
    > is probably slower than
    >
    > for (edge1, edge2), cost in d.iteritems(): # or .items()
    > print edge1, edge2, cost
    >
    >
    > So, the latter is both faster and easier to read. Why are you arguing against it?
    >
    > Also, please stop top-posting. It's impolite here, and makes it much harder to figure out who is saying what, in what order.
    >
    >
    >
    > --
    >
    > DaveA
    >


    I'm not arguing at all. Sorry if it sounded like I was arguing.
    Thanks for notifying me of the way messages should be sent.

    Roman
     
    Roman Vashkevich, Aug 9, 2012
    #16
  17. On 09/08/2012 22:34, Roman Vashkevich wrote:
    > Actually, they are different.
    > Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    > Dict uses hashing to get a value from the dict and this is why it's O(1).
    >


    Sligtly off topic, but looking up a value in a dictionary is actually
    O(n) for all other entries in the dict which suffer a hash collision
    with the searched entry.

    True, a sensible choice of hash function will reduce n to 1 in common
    cases, but it becomes an important consideration for larger datasets.

    ~Andrew
     
    Andrew Cooper, Aug 9, 2012
    #17
  18. Dave Angel Guest

    On 08/09/2012 06:03 PM, Andrew Cooper wrote:
    > On 09/08/2012 22:34, Roman Vashkevich wrote:
    >> Actually, they are different.
    >> Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    >> Dict uses hashing to get a value from the dict and this is why it's O(1).
    >>

    > Sligtly off topic, but looking up a value in a dictionary is actually
    > O(n) for all other entries in the dict which suffer a hash collision
    > with the searched entry.
    >
    > True, a sensible choice of hash function will reduce n to 1 in common
    > cases, but it becomes an important consideration for larger datasets.
    >
    > ~Andrew


    I'm glad you're wrong for CPython's dictionaries. The only time the
    lookup would degenerate to O[n] would be if the hash table had only one
    slot. CPython sensibly increases the hash table size when it becomes
    too small for efficiency.


    Where have you seen dictionaries so poorly implemented?

    --

    DaveA
     
    Dave Angel, Aug 9, 2012
    #18
  19. Chris Kaynor Guest

    On Thu, Aug 9, 2012 at 3:26 PM, Dave Angel <> wrote:
    > On 08/09/2012 06:03 PM, Andrew Cooper wrote:
    >> On 09/08/2012 22:34, Roman Vashkevich wrote:
    >>> Actually, they are different.
    >>> Put a dict.{iter}items() in an O(k^N) algorithm and make it a hundred thousand entries, and you will feel the difference.
    >>> Dict uses hashing to get a value from the dict and this is why it's O(1).
    >>>

    >> Sligtly off topic, but looking up a value in a dictionary is actually
    >> O(n) for all other entries in the dict which suffer a hash collision
    >> with the searched entry.
    >>
    >> True, a sensible choice of hash function will reduce n to 1 in common
    >> cases, but it becomes an important consideration for larger datasets.
    >>
    >> ~Andrew

    >
    > I'm glad you're wrong for CPython's dictionaries. The only time the
    > lookup would degenerate to O[n] would be if the hash table had only one
    > slot. CPython sensibly increases the hash table size when it becomes
    > too small for efficiency.
    >
    >
    > Where have you seen dictionaries so poorly implemented?


    There are plenty of ways to make a pathological hash function that
    will have that issue in CPython.

    The very simple (and stupid):

    class O(object):
    def __hash__(self):
    return 0
    def __eq__(self, other): # I am aware this is the default equals method.
    return self is other

    Start adding those to a dictionary to get O(n) lookups.

    Any case the hash return values modulus the dictionary hash table size
    is constant will have similar results; powers of 2 are likely to
    result in such behavior as well.

    >
    > --
    >
    > DaveA
    >
    > --
    > http://mail.python.org/mailman/listinfo/python-list
     
    Chris Kaynor, Aug 9, 2012
    #19
  20. Tim Chase Guest

    On 08/09/12 17:26, Dave Angel wrote:
    > On 08/09/2012 06:03 PM, Andrew Cooper wrote:
    > I'm glad you're wrong for CPython's dictionaries. The only time the
    > lookup would degenerate to O[n] would be if the hash table had only one
    > slot. CPython sensibly increases the hash table size when it becomes
    > too small for efficiency.
    >
    > Where have you seen dictionaries so poorly implemented?


    PHP?

    http://www.phpclasses.org/blog/post/171-PHP-Vulnerability-May-Halt-Millions-of-Servers.html

    -tkc
     
    Tim Chase, Aug 9, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Luis P. Mendes

    save a dictionary in a file

    Luis P. Mendes, Nov 15, 2004, in forum: Python
    Replies:
    10
    Views:
    565
    Leif K-Brooks
    Nov 16, 2004
  2. Stef Mientki

    function without brackets ?

    Stef Mientki, Jan 3, 2007, in forum: Python
    Replies:
    5
    Views:
    336
    Stef Mientki
    Jan 3, 2007
  3. Replies:
    9
    Views:
    821
  4. subhadip
    Replies:
    0
    Views:
    647
    subhadip
    Mar 28, 2007
  5. Shahar Golan
    Replies:
    5
    Views:
    294
    kaeli
    Oct 16, 2003
Loading...

Share This Page