Mark Dickinson <[EMAIL PROTECTED]> added the comment:
Other responses...
> It was an argument for changing the base used by the mashal :-)
Ah. I think I'm with you now. You're saying that ideally, marshal
shouldn't have to care about how Python stores its longs: it should
just ask some function in longobject.c to provide an already-converted-
to-base-256 representation. Is that right?
I also find the idea of making the marshal representation base 256 quite
attractive. There are already functions in longobject.c that could be
used for this: _PyLong_{From,As}ByteArray. And then you wouldn't need
to touch marshal.c when swapping the GMP version of longobject.c in and
out.
> Python stores the sign of the number in the first digit. Because
> of that, we are limited to 15/30 bits.
No: the sign is stored in the size: if v is a PyLongObject then
ABS(Py_SIZE(v)) gives the number of digits in the absolute value of the
integer represented by v, and the sign of Py_SIZE(v) gives the sign of
the integer.
> would it be possible to keep the "2 digits" hack in
> PyLong_FromLong, especially with base 2^15? Eg. "#if PyLong_SHIFT ==
> 15". The base 2^15 slow, so don't make it slower :-)
Why don't we leave this kind of micro-optimization out until we've got
some benchmarks. (I'm also tempted to get rid of the long_mul fast path
for now.)
> PyLong_FromLong() doesn't go into the 1 digit special case for
> negative number.
Well spotted! Yes, this should be fixed. I have a nasty feeling that I
was responsible for introducing this bug some time ago...
_______________________________________
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4258>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
