On 10/7/2010 5:14 PM, Pauli Virtanen wrote: > to, 2010-10-07 kello 15:38 -0400, Andrew P. Mullhaupt kirjoitti: > [clip] >> On 10/7/2010 1:01 PM, Pauli Virtanen wrote: >>> to, 2010-10-07 kello 12:08 -0400, Andrew P. Mullhaupt kirjoitti: >>> [clip] >>> But to implement this, you'd have to rewrite large parts of Numpy since >>> the separated storage of re/im conflicts with its memory model. >> You wouldn't want to rewrite any of Numpy, just add a new class. > I believe you didn't really think about this. Because of the memory > model mismatch, you will need to rewrite all arithmetic operations, > special functions, and any operations that select, choose, sort, etc. > parts of arrays.
It wouldn't be the first time I suggested rewriting the select and choose operations. I spent months trying to get Guido to let anything more than slice indexing in arrays. And now, in the technologically advanced future, we can index a numpy array with a list, not just slices. I'm not claiming any credit for that though - I don't know who actually got that ball over the finish line. But it's also not as bad as you think if you do it right. In the first place, you don't need to rewrite any of the real operations other than to check if the complex part is trivial or not (which as I pointed out a minute ago can be done on a variable granular or page granular level for variables that take up more than a page. So it's only the case with a nontrivial complex part where you have to do anything at all. OK so just offset the real address by the different to the imaginary part. Doing this on a variable-level granularity would allow you to simply replicate all the selection and sorting addressing. The interesting case is noncontiguous data arrays. Here, you can actually get a benefit, since if all the floating values are in this class, you already know the address of the memory where you will widen them - so if you have to widen some horrific recursive spaghetti structure, then you get a big win here because you don't have to worry about copying the real parts. But let's go back to what I asked: Could we have a data type that would be able to widen itself? It appears that your answer is YES, we COULD have that, BUT it would be a lot of work. Best regards, Andrew Mullhaupt _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
