Re: [Python-Dev] longobject.c ob_size
Tim Peters [EMAIL PROTECTED] writes: [Michael Hudson] Asking mostly for curiousity, how hard would it be to have longs store their sign bit somewhere less aggravating? Depends on where that is. It seems to me that the top bit of ob_digit[0] is always 0, for example, Yes, the top bit of ob_digit[i], for all relevant i, is 0 on all platforms now. and I'm sure this would result no less convolution in longobject.c it'd be considerably more localized convolution. I'd much rather give struct _longobject a distinct sign member (say, 0 == zero, -1 = non-zero negative, 1 == non-zero positive). Well, that would indeed be simpler. That would simplify code. It would cost no extra bytes for some longs, and 8 extra bytes for others (since obmalloc rounds up to a multiple of 8); I don't care about that (e.g., I never use millions of longs simultaneously, but often use a few dozen very big longs simultaneously; the memory difference is in the noise then). Note that longintrepr.h isn't included by Python.h. Only longobject.h is, and longobject.h doesn't reveal the internal structure of longs. IOW, changing the internal layout of longs shouldn't even hurt binary compatibility. Bonus. The ob_size member of PyObject_VAR_HEAD would also be redeclared as size_t in an ideal world. As nature intended. I might do a patch, at some point... Cheers, mwh -- Indeed, when I design my killer language, the identifiers foo and bar will be reserved words, never used, and not even mentioned in the reference manual. Any program using one will simply dump core without comment. Multitudes will rejoice. -- Tim Peters, 29 Apr 1998 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] longobject.c ob_size
Michael Hudson [EMAIL PROTECTED] writes: Tim Peters [EMAIL PROTECTED] writes: [Michael Hudson] Asking mostly for curiousity, how hard would it be to have longs store their sign bit somewhere less aggravating? Depends on where that is. [...] I'd much rather give struct _longobject a distinct sign member (say, 0 == zero, -1 = non-zero negative, 1 == non-zero positive). I ended up doing -1 non-zero negative, 1 zero and positive, but I don't know if this is really clearer than what you suggest overall. I suspect it's a wash. [...] I might do a patch, at some point... http://python.org/sf/119 Assigned to you, but unassign if you don't have time (testing the patch is probably more worthwhile than reading it!). Cheers, mwh -- Linux: Horse. Like a wild horse, fun to ride. Also prone to throwing you and stamping you into the ground because it doesn't like your socks. -- Jim's pedigree of operating systems, asr ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] longobject.c ob_size
[Michael Hudson] Asking mostly for curiousity, how hard would it be to have longs store their sign bit somewhere less aggravating? Depends on where that is. It seems to me that the top bit of ob_digit[0] is always 0, for example, Yes, the top bit of ob_digit[i], for all relevant i, is 0 on all platforms now. and I'm sure this would result no less convolution in longobject.c it'd be considerably more localized convolution. I'd much rather give struct _longobject a distinct sign member (say, 0 == zero, -1 = non-zero negative, 1 == non-zero positive). That would simplify code. It would cost no extra bytes for some longs, and 8 extra bytes for others (since obmalloc rounds up to a multiple of 8); I don't care about that (e.g., I never use millions of longs simultaneously, but often use a few dozen very big longs simultaneously; the memory difference is in the noise then). Note that longintrepr.h isn't included by Python.h. Only longobject.h is, and longobject.h doesn't reveal the internal structure of longs. IOW, changing the internal layout of longs shouldn't even hurt binary compatibility. The ob_size member of PyObject_VAR_HEAD would also be redeclared as size_t in an ideal world. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] longobject.c ob_size
Hi Michael, On Sun, Apr 03, 2005 at 04:14:16PM +0100, Michael Hudson wrote: Asking mostly for curiousity, how hard would it be to have longs store their sign bit somewhere less aggravating? As I guess your goal is to get rid of all the if (size 0) size = -size in object.c and friends, I should point out that longobject.c has set out an example that might have been followed by C extension writers. Maybe it is too late to say now that ob_size cannot be negative any more :-( Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] longobject.c ob_size
Michael Hudson wrote: Asking mostly for curiousity, how hard would it be to have longs store their sign bit somewhere less aggravating? It seems to me that the top bit of ob_digit[0] is always 0, for example, and I'm sure this would result no less convolution in longobject.c it'd be considerably more localized convolution. I think the amount of special-casing that you need would remain the same - i.e. you would have to mask out the sign before performing the algorithms, then bring it back in. Masking out the bit from digit[0] might slow down the algorithms somewhat, because you would probably mask it out from every digit, not only digit[0] (or else test for digit[0], which test would then be performed for all digits). You would also have to keep the special case for 0L, which has ob_size==0 (i.e. doesn't have digit[0]). That said, I think the change could be implemented within a few hours, taking a day to make the testsuite run again; depending on the review process, you might need two releases to fix the bugs (but then, it is also reasonable to expect to get it right the first time). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
