[Patches] [ python-Patches-1177779 ] explicit sign variable for longs

[SourceForge.net]

Patches item #1177779, was opened at 2005-04-06 13:47
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470

Category: Core (C code)
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Armin Rigo (arigo)
Summary: explicit sign variable for longs

Initial Comment:
This patch removes longobject.c abuse of ob_size to store the sign 
in favour of an explicit sign member, as mentioned on python-dev.

The only other file that needed modifying is marshal.c (but the 
marshal format isn't changed).

It doesn't touch all the various code that handles ob_size 
generically.

----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2005-04-11 09:38

Message:
Logged In: YES 
user_id=4771

Sorry, I tested the memory overhead of adding an "int" field long_sign, and forgot that the digits were "short".

(mwh, your patch #2 forgot to rename "sign" in marshal.c)



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-04-10 23:44

Message:
Logged In: YES 
user_id=6656

Good, I didn't really understand Armin's point either :)

Here's a new version of the patch that pays a bit more attention to the 
comments (I changed my mind over a few details while writing it, I'm not 
entirely surprised that clarity suffered) and renames the sign member to 
long_sign -- but it turns out that you could find all references by searching 
for "->sign"...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2005-04-10 23:28

Message:
Logged In: YES 
user_id=31435

Armin, I don't understand your use case.  Can you be more 
explicit?  Best I can guess, you're using Python longs on a 
32-bit box to store positive integers with bit 2**31 set.  But 
there's no change in memory burden for those (rounds up to 
24 bytes either way), so that can't be what you mean.  
Maybe you're using Python longs to store _all_ integers, no 
matter how small they are?  But in that case you weren't 
serious about memory use to begin with.

Michael, I got confused at the start of the patch.  When you 
changed the comment

SUM(for i=0 through abs(ob_size)-1) ob_digit[i] * 2**(SHIFT*i)

to

sign * SUM(for i=0 through ob_size) ob_digit[i] * 2**(SHIFT*i)

you dropped the "-1" as well as the "abs()".  That wasn't 
intended, was it?

Was also confused by why you dropped the "zero is 
represented by ob_size == 0." comment.

It would be very helpful to rename the new member, e.g., 
as "long_sign".  Then it's easy to find references in the code 
with an editor search.


----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2005-04-08 14:20

Message:
Logged In: YES 
user_id=4771

Unlike Tim I have a use case for lots of small longs in memory: to store unsigned machine integers.  It's exactly the case where it would be nice that the extra field didn't cross the malloc 8-byte boundary.  Of course, it's exactly NOT what is happening here on 32-bit machines, and this patch makes program relying on this kind of longs suddenly consume 8 extra bytes per long.  Damn.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2005-04-06 13:51

Message:
Logged In: YES 
user_id=6656

Oh, and I meant to say, it passes make test but more testing is certainly 
welcome -- some mistakes show up in pretty obscure ways...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1177779&group_id=5470