On Nov 30, 2006, at 7:34 PM, William Stein wrote: > On Thu, 30 Nov 2006 18:59:32 -0800, David Harvey > <[EMAIL PROTECTED]> wrote: >> On Nov 30, 2006, at 9:40 PM, William Stein wrote: >>>> If it's 1MB per ring, then I only have to be >>>> working modulo 500 or so integers simultaneously --- not at all a >>>> far- >>>> fetched situation --- before my typical desktop PC runs out of RAM. >>> >>> We could only automatically cache up to 50 rings, say. If the user >>> *wants* caching, they can always explicitly ask for it, and if they >>> don't they can always explicitly ask not to have it. >>> >>> sage: Integers(97, cache=False) >>> sage: Integers(97, cache=True) >>> >>> if you are explicitly about casting then either option should >>> be respected. If you don't specify anything for cache, it could >>> use some rules, such as suggested above. >> >> OK, I could live with that. > > Robert: "make it so".
Done. >>> On the other hand, if you create a large number of elements >>> modulo one >>> integer with the caching you won't run out of memory, whereas >>> without >>> it you might very well run out. >> >> I'm not so sure about this. If you cache, then every IntegerMod is a >> Python object containing a pointer that points to the cached object. >> If you don't cache, then every IntegerMod is a Python object >> containing a single machine word describing which element it is. Am I >> missing something here? > > Yes. > >> Have I been spending too long away from >> python/pyrex? > > Maybe. > > If you cache, then every IntegerMod is a single PyObject*, i.e., it's > a machine pointer. Note that when this pointer is returned Robert (I > hope!) > was careful to increment the reference count to the actual cached > IntegerMod. If you don't cache, then ever IntegerMod is a struct > that contains all kinds of stuff: > > * reference counting info > * type info (??) > * pointer to the parent > * actual value. > > I think on a 32-bit machine it's something like 24 bytes versus 4 > bytes. I actually implemented this as a python list, using the unsafe PyList_SET_ITEM api. I could probably squeeze a bit more out of it using a PyObject** directly, though I'm curious as to how much. I was also thinking about caching inverses in the elements (either at calculation time or ring creation time (can this be done faster than iterating over about half the list?)) since this is probably the most expensive operation commonly done with these elements. This could certainly be a saving when the element are already all in a table, but I'm not sure how to (very quickly) decide to do so otherwise. --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
