PEP 218 Re: ANN: set-0.1 module available

[James J. Besemer]

Fernando Pérez wrote:

> So the issue is not whether it can be done
> or not, but whether the existence of that penalty tilts the decision in favor
> of making them mutable and thus paying the price of losing hashability.

As I acknowledged in my previous post.

Furthermore, I previously recanted and agreed a mutable implementation probably is
better because of performance reasons.

> And by the way, when you say 'Creating a new one each time SOUNDS like a lot
> more work but in practice I bet it won't be', I hope you don't really mean
> that.

I meant that, like with strings, the majority of users won't have a problem.  I
don't mean that nobody will.  Exactly like with Numerics -- some applications
require much greater numeric performance than Python offers out of the box.

Say La Vee.

> If you deal routinely with sets with 2**N (N>>30) elements, a copy
> operation for simulating += can be prohibitive. Why do you think that
> Numeric's arrays implement [a:b] slicing as a reference and not a copy
> operation (which bites most newbies _hard_)?

One could similarly imagine a special Set implementation for huge numbers of
elements.

E.g., some applications might use large sets of a subrange of integers, say
0..64K.  For them a bitmap implementation (ala Pascal) might be way more efficient
than any kind of dictionary lookup.  Even if you need sets of arbitrary values, a
special high-performance version might be appropriate as a library alternative
instead of loading extra complexity into the base language.

If you're pushing the envelope, you're pushing the envelope and you may run into
problems.

> That is the crux I'm trying to point you to, not whether
> you can _simulate_ in-place operations with immutable objects. We've known
> that all along.

Then you should have SAID that sooner.  ;o)

Most of my objections have been with the faulty reasons you used in your argument.

> In case you are curious, for the 2d case the meat of the Laplace code is
> as simple as:

Can you think of a practical example that requires efficient, large SETs?

Regards

--jb

--
James J. Besemer  503-280-0838 voice
http://cascade-sys.com  503-280-0375 fax
mailto:jb at cascade-sys.com