Should object types exposed from gmpy be immutable (like builtin numbers) or mutable (for efficiency with += etc)? I'm open to suggestions & arguments on both sides -- fire away!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Numbers in Python have traditionally been treated as immutable objects. While this imposes some performance constraints (new objects have to be allocated more often), this allows the expected value semantics. Not surprising users is a good thing!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But could you get effective immutability by copy-on-write, doing something like checking in the += code whether the ref count is 1. If it is, modify in place, otherwise copy.
The only problem is that the resulting numbers can't be dictionary keys. Nasty.
It may (just barely!) be worth having a mutable version if the performance issue is sufficiently critical. But even then, I would use copy-on-write as above. I don't think that under any circumstances
a = MPZ(1)
b = a
a += 1
print b
should give any answer other than 1...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any reason to use C++? You're binding a C library to a C-based language interpreter. Where's the advantage in using C++? It's less portable simply because many of the compilers still aren't up to snuff with all the language features on minority platforms, but most everyone seems to have an ANSI C compiler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Should object types exposed from gmpy be immutable (like builtin numbers) or mutable (for efficiency with += etc)? I'm open to suggestions & arguments on both sides -- fire away!
Immutable.
Numbers in Python have traditionally been treated as immutable objects. While this imposes some performance constraints (new objects have to be allocated more often), this allows the expected value semantics. Not surprising users is a good thing!
Agreed - immutable.
But could you get effective immutability by copy-on-write, doing something like checking in the += code whether the ref count is 1. If it is, modify in place, otherwise copy.
The only problem is that the resulting numbers can't be dictionary keys. Nasty.
It may (just barely!) be worth having a mutable version if the performance issue is sufficiently critical. But even then, I would use copy-on-write as above. I don't think that under any circumstances
a = MPZ(1)
b = a
a += 1
print b
should give any answer other than 1...
Is there any reason to use C++? You're binding a C library to a C-based language interpreter. Where's the advantage in using C++? It's less portable simply because many of the compilers still aren't up to snuff with all the language features on minority platforms, but most everyone seems to have an ANSI C compiler.