On Tue, 01 Sep 2009 16:43:06 -0700, Carl Banks wrote: >> Numbers are immutable by nature (math). The number 3.14 remains 3.14 >> whatever you try to do with it. What you call an immutable number is in >> fact a container that contains a number. > > I wouldn't agree with that terminology or logic.
Abstract numbers aren't really "things", they're concepts, and as such I don't think mutable or immutable has any meaning. But if it does, then abstract numbers are immutable, because you can't change one into two without losing the value one, and that certainly doesn't happen. > First of all "mutable number" is really just a short way to say "mutable > number object". Yes, but "object" in the above doesn't necessarily mean object in the sense of object-oriented programming. Perhaps a better word is "mutable number thing", where "thing" could be an object in the OOP sense, or a variable in the memory-location sense, or on a stack, in a register, or chalk marks on a whiteboard. > A number object in Python is not a number, it's just a > representation of a number. Even if numbers are immutable by nature, an > object representing a number need not be. /s/number/abstract number/ Given that, then I agree, but given Python's implementation, you would need more than one change to make number's mutable, and what you would have wouldn't be Python any more. > And if your number object is mutable, it does not make that object a > container, at least not what I would call a container. A container you > have to dereference somehow to get at the object inside, whereas a > mutable number object you don't dereference: it acts like number as- is. Agreed, so long as we're talking from the programmer's perspective. From the compiler's perspective, or the Virtual Machine's perspective, variables of the type "value stored at memory location" are a kind of container: you don't dereference anything, but the compiler does. There are multiple perspectives which are valid at once, depending on where you're looking from. A *name* is kind of a container (but not in the same sense that lists and dicts are containers), in that the VM has to dereference the name to get to the object. > IOW, the first example below is a container, the second is not: Do you mean the name `num` is a container, or the *contents* of `num` is a container? I assume you mean the contents. > num = [2] > num[0] += 3 > > num = mutable_int(2) > num += 3 In the sense of container that you give, I agree. But there's nothing magic about mutable_int() in the above -- num could be bound to a regular int, and it still wouldn't be a container. Obviously. > (If you want to call the mutable number a container anyway, fine with > me, I am not here to bicker.) A container is sufficient to get a layer > of indirection if that's what you want the mutable number for. > > However, the mutable number has a performance advantage over using a > container: it avoids the overhead of creating a new object. You're assuming that the overhead of flipping bits is less than the overhead of creating a new object, and that's almost certainly valid if the VM is implemented in (say) C. But it may not be the case if the VM is implemented in (say) Python, or Javascript, in which case "create a new object" might be less expensive than "flip a bunch of bits". If you can get the CPU to flip your bits, that will be fast, but perhaps your implementation needs to convert the int to a string of ones and zeroes, then perform bit-operations on those, then convert back to a real int. (I mention this as a theoretical issue, not a serious objection to the existing CPython implementation. But perhaps the PyPy people have to deal with it?) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
