On Wednesday 15 November 2006 23:50, David Harvey wrote: > On Nov 15, 2006, at 5:00 PM, Martin Albrecht wrote: > > Hi there, > > > > I've implemented a very naive cache for finite extension field > > elements in the > > Givaro wrapper. Basically, all elements are created when the field > > is created > > and references are returned by the arithmetic methods: Thus, no > > objects are > > created, no malloc, nothing. The speed-up is noticeable: > > Ha ha that's ridiculous. If I remember correctly, givaro goes up to > 2^16, so each element actually requires 16 bits of storage space, and > now you're storing all possible 16 bits in an array and then > effectively representing elements of the field as a pointer into that > array!!! That's pretty funny.
Actually, it's sizeof(int), assumable because it's faster. > But I can see why it would be faster, given all the crap that sits > between us and those 16 bits. > > I don't necessarily have a problem with what you're doing, but in the > long run, we're better off just bloody well implementing the fields > ourselves. I don't understand that: You say, you want to reimplement the finite ext. field for GF(q) stuff to gain q * wordsize of RAM by calculating on Python objects instead of ints on the lowest level? That could make the whole stuff slower (if you'd work on pointers to Python objects) and would definitely increase the required RAM for certain applications. Right now, we could implement any matrix over GF(q) as a matrix with int entries, multivariate polynomials over GF(q) as polynomials over ints, etc. without using any Python stuff internally. Using Python objects at the inner most level would prevent that. Also, it feels like reinventing the wheel while driving a Porsche (... couldn't resist that pun). Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _icq: 177334829 _jab: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com 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/ -~----------~----~----~----~------~----~------~--~---
