Message95959
Zooko: Yes; that's the sort of solution that's needed if we're not
allowed to assume two's complement with the extraordinary value (-
sys.maxint - 1) not a trap representation. If we are allowed to
assume this, then more efficient solutions are available.
Also, if we're not allowed to assume two's complement + no trap
representation, then int_and, int_xor, int_or are plain wrong:
For ones' complement or sign-and-magnitude, the result of these
logical operations won't match the result of the corresponding
operations on longs, for negative operands.
For two's complement with (-sys.maxint-1) a trap representation,
int_and and int_xor should be producing a Python long instead
of a Python int in some cases: -sys.maxint ^ 1 should be -sys.maxint - 1,
which wouldn't be representable as a Python int.
That's why I want to make these extra assumptions beyond what's
guaranteed by the C standards; working around them introduces
inefficiencies for all implementations, for the benefit
of implementations that (probably) don't even exist. |
|
Date |
User |
Action |
Args |
2009-12-04 10:58:51 | mark.dickinson | set | recipients:
+ mark.dickinson, zooko, eric.smith |
2009-12-04 10:58:51 | mark.dickinson | set | messageid: <1259924331.36.0.881580871602.issue7406@psf.upfronthosting.co.za> |
2009-12-04 10:58:49 | mark.dickinson | link | issue7406 messages |
2009-12-04 10:58:48 | mark.dickinson | create | |
|