frozenset question

[Will McGugan]

Hi,

Are there any benefits in using a frozenset over a set, other than it
being immutable?
Will McGugan
--
http://www.willmcgugan.com
"".join({'*':'@ ','^':'.'}.get( c,0) or chr(97+(ord(c)-84)%26) for c in
"jvyy*jvyyzptht na^pbz")

[Qiangning Hong]

On 7/6/05, Will McGugan <ne**@nowillmcg uganspam.com> wrote:

Hi,

Are there any benefits in using a frozenset over a set, other than it
being immutable?

A frozenset can be used as a key of a dict:

..>> s1 = set([1])
..>> s2 = frozenset([2])
..>> {s1: 1}
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: set objects are unhashable
..>> {s2:1}
{frozenset([2]): 1}

--
Qiangning Hong
Get Firefox! <http://www.spreadfiref ox.com/?q=affiliates&a mp;id=67907&amp ;t=1>

[Will McGugan]

Qiangning Hong wrote:

On 7/6/05, Will McGugan <ne**@nowillmcg uganspam.com> wrote:

Hi,

Are there any benefits in using a frozenset over a set, other than it
being immutable?

A frozenset can be used as a key of a dict:

Thanks, but I meant to imply that.

I was wondering if frozenset was faster or more efficient in some way.
Thinking back to the dark ages of C++, you could optimize things that
you knew to be constant.
Will

--
http://www.willmcgugan.com
"".join({'*':'@ ','^':'.'}.get( c,0) or chr(97+(ord(c)-84)%26) for c in
"jvyy*jvyyzptht na^pbz")

[Steven D'Aprano]

On Wed, 06 Jul 2005 11:30:14 +0100, Will McGugan wrote:

I was wondering if frozenset was faster or more efficient in some way.

Thinking back to the dark ages of C++, you could optimize things that
you knew to be constant.

Why would you want to?

py> import sets
py> import time
py> bigset = sets.Set(range( 500000))
py> bigimmutableset = sets.ImmutableS et(range(500000 ))
py> assert len(bigset) == len(bigimmutabl eset)
py>
py> def tester(S, L):
.... """Test if items from L are in S, and time the process."""
.... t = time.time()
.... for i in range(100):
.... for item in L:
.... item in S
.... return time.time() - t # time returned is for 100 loops
....
py>

Time some successful tests:

py> tester(bigset, range(100, 500))
0.1153950691223 1445
py> tester(bigimmut ableset, range(100, 500))
0.1201419830322 2656

Practically no difference when doing 100*400 checks of whether an integer
is in the set. But let's try again, just in case:

py> tester(bigset, range(100, 500))
0.1099889278411 8652
py> tester(bigimmut ableset, range(100, 500))
0.1111409664154 0527

The difference is insignificant. How about unsuccessful checks?

py> tester(bigset, range(-100, -500, -1))
0.1207029819488 5254
py> tester(bigset, range(-100, -500, -1))
0.1168141365051 2695
py> tester(bigimmut ableset, range(-100, -500, -1))
0.1131389141082 7637
py> tester(bigimmut ableset, range(-100, -500, -1))
0.1131570339202 8809

There is no significant speed difference between immutable and mutable
sets, at least for queries. Regardless of whether it is successful or
unsuccessful, mutable or immutable, it takes about 0.0000025 second to do
each test of item in set. Why would you need to optimize that?

If you tell us what you are trying to do, and under what circumstances it
is too slow, we'll see if we can suggest some ways to optimize it.

But if you are just trying to optimize for the sake of optimization,
that's a terrible idea. Get your program working first. Then when it
works, measure how fast it runs. If, and ONLY if, it is too slow,
identify the parts of the program that make it too slow. That means
profiling and timing. Then optimize those parts, and nothing else.

Otherwise, you will be like the car designer trying to speed up his sports
cars by making the seatbelts aerodynamic.
--
Steven.

[Will McGugan]

Steven D'Aprano wrote:

There is no significant speed difference between immutable and mutable
sets, at least for queries. Regardless of whether it is successful or
unsuccessful, mutable or immutable, it takes about 0.0000025 second to do
each test of item in set. Why would you need to optimize that?

If you tell us what you are trying to do, and under what circumstances it
is too slow, we'll see if we can suggest some ways to optimize it.

But if you are just trying to optimize for the sake of optimization,
that's a terrible idea. Get your program working first. Then when it
works, measure how fast it runs. If, and ONLY if, it is too slow,
identify the parts of the program that make it too slow. That means
profiling and timing. Then optimize those parts, and nothing else.

Otherwise, you will be like the car designer trying to speed up his sports
cars by making the seatbelts aerodynamic.

No need for the 'premature optimization is the root of all evil' speech.
I'm not trying to optimize anything - just enquiring about the nature of
frozenset. If typing 'frozenset' over 'set' gave me a saving in time or
memory (even if tiny) I would favour immutable sets, where appropriate.

Thanks for the info.

Will

--
http://www.willmcgugan.com
"".join({'*':'@ ','^':'.'}.get( c,0) or chr(97+(ord(c)-84)%26) for c in
"jvyy*jvyyzptht na^pbz")

[Michael Hudson]

Will McGugan <ne**@NOwillmcg uganSPAM.com> writes:

Qiangning Hong wrote:

On 7/6/05, Will McGugan <ne**@nowillmcg uganspam.com> wrote:

Hi,

Are there any benefits in using a frozenset over a set, other than it
being immutable?

A frozenset can be used as a key of a dict:

Thanks, but I meant to imply that.

I was wondering if frozenset was faster or more efficient in some
way.

No, the 'usable as a dict key' is the main motivation for frozenset's
existence.

Cheers,
mwh

--
The bottom tier is what a certain class of wanker would call
"business objects" ... -- Greg Ward, 9 Dec 1999

[Raymond Hettinger]

Will McGugan wrote:

Are there any benefits in using a frozenset over a set, other than it
being immutable?

No. The underlying implementation is identical with set. The only
difference is the addition of a hash method and absence of mutating
methods. Everything else is the same.
Raymond

[Steven D'Aprano]

On Wed, 06 Jul 2005 14:25:30 +0100, Will McGugan wrote:

But if you are just trying to optimize for the sake of optimization,
that's a terrible idea. Get your program working first. Then when it
works, measure how fast it runs. If, and ONLY if, it is too slow,
identify the parts of the program that make it too slow. That means
profiling and timing. Then optimize those parts, and nothing else.

Otherwise, you will be like the car designer trying to speed up his sports
cars by making the seatbelts aerodynamic.

No need for the 'premature optimization is the root of all evil' speech.
I'm not trying to optimize anything - just enquiring about the nature of
frozenset. If typing 'frozenset' over 'set' gave me a saving in time or
memory (even if tiny) I would favour immutable sets, where appropriate.

Well, obviously the "premature optimization" speech just went in one ear
and out the other. "Saving in time or memory" is what optimization is
about. What did you think optimization means?

set and frozenset have different functionality (one is mutable, the other
is not) and use cases (you use one where you need to dynamically add and
remove items from a set, and the other where you need to use a set as a
key in a dictionary). In most cases, they aren't interchangable. While
you're spending time worrying about shaving a thousandth of a millisecond
off a program that takes five seconds to run, I'll get on with development
using the right object for the functionality needed.

--
Steven.

[George Sakkis]

"Steven D'Aprano" <st***@REMOVETH IScyber.com.au> wrote:

On Wed, 06 Jul 2005 14:25:30 +0100, Will McGugan wrote:

No need for the 'premature optimization is the root of all evil' speech.
I'm not trying to optimize anything - just enquiring about the nature of
frozenset. If typing 'frozenset' over 'set' gave me a saving in time or
memory (even if tiny) I would favour immutable sets, where appropriate.

Well, obviously the "premature optimization" speech just went in one ear
and out the other. "Saving in time or memory" is what optimization is
about. What did you think optimization means?

set and frozenset have different functionality (one is mutable, the other
is not) and use cases (you use one where you need to dynamically add and
remove items from a set, and the other where you need to use a set as a
key in a dictionary). In most cases, they aren't interchangable.

Well, they *may* be interchangable under some conditions, and that was
the OP's point you apparently missed. If you don't need to dynamically
modify a set and don't add sets as keys in dictionaries, you currently
have a choice; both frozenset and set will work. So all other things
being equal, it makes sense to ask about the relative performance if
the only 'evil' it may introduce can be rectified in a single import.

George

[Steven D'Aprano]

On Wed, 06 Jul 2005 10:15:31 -0700, George Sakkis wrote:

Well, they *may* be interchangable under some conditions, and that was
the OP's point you apparently missed.

I didn't miss anything of the sort. That's why I spent 15 minutes actually
producing test cases to MEASURE if there was any detectable speed
differences between accessing set and frozenset instead of wasting time
worrying about "tiny" differences in performance that are almost certainly
lost in the noise in real code.

If, over a thousand runs of the program, you save a millisecond of time in
total, but it costs you two seconds to type the comment in the code
explaining why you used frozenset instead of the more natural set, then
your "optimizati on" is counter-productive. Even just considering the
question is a waste of valuable developer time! THAT is the lesson of
premature optimization: don't even THINK about optimizing code until you
have it WORKING and you have MEASURED that it is too slow.
--
Steven.