Using new numeric instances in NumArray and RecArray.
Hi all! I am trying to define new numeric types to use them in NumArray and RecArray objects. My intention is to define them as equivalent to other types, but also make possible to distinguish them. I tried "MyInt32 = IntegralType(4, 'MyType')", which registered OK, is equivalent to Int32, but distinguishable from it. However, I am not allowe to create a NumArray based on it: "a = array([1,2], MyInt32)" fails with "RuntimeError: _numarray_init: can't get typeno for type". Is it possible to integrate new types seamlessly into NumArray and RecArray objects? Is this the right approach, or am I getting that wrong? Well, thanks a lot for your cooperation. PS: Please CC: me with your replies, since I am not registered in the list. Thanks again. -- Ivan Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data ""
On Mon, 2004-12-13 at 12:39 +0100, Ivan Vilata i Balaguer wrote:
Hi all! I am trying to define new numeric types to use them in NumArray and RecArray objects. My intention is to define them as equivalent to other types, but also make possible to distinguish them. I tried "MyInt32 = IntegralType(4, 'MyType')", which registered OK, is equivalent to Int32, but distinguishable from it. However, I am not allowe to create a NumArray based on it: "a = array([1,2], MyInt32)" fails with "RuntimeError: _numarray_init: can't get typeno for type".
Is it possible to integrate new types seamlessly into NumArray and RecArray objects?
I don't know. No one else has asked for it yet so you're in unfamiliar territory. It does seem (to me anyway) like it would complicate an already complex system. What are you trying to do?
Is this the right approach, or am I getting that wrong?
The system as it stands is not designed for that. Regards, Todd
On Mon, Dec 13, 2004 at 07:53:27AM -0500, Todd Miller wrote:
On Mon, 2004-12-13 at 12:39 +0100, Ivan Vilata i Balaguer wrote: [...]
Is it possible to integrate new types seamlessly into NumArray and RecArray objects?
I don't know. No one else has asked for it yet so you're in unfamiliar territory. It does seem (to me anyway) like it would complicate an already complex system. What are you trying to do?
I'm trying to define new types that can be handled as normal types in numarray, but being different (distinguishable) from their equivalent types. For instance, an array of MyInt32 should work exactly as an Int32 array, but I would need to know it is a MyInt32 array and not an Int32 one. However, I you believe that the system is not prepared for that (or it would require too much work) I will try to identify it by some external means. Thank you anyway for your prompt answer. Best regards, Ivan -- Ivan Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data ""
On Mon, 2004-12-13 at 11:23, Ivan Vilata i Balaguer wrote:
I'm trying to define new types that can be handled as normal types in numarray, but being different (distinguishable) from their equivalent types. For instance, an array of MyInt32 should work exactly as an Int32 array, but I would need to know it is a MyInt32 array and not an Int32 one.
However, I you believe that the system is not prepared for that (or it would require too much work) I will try to identify it by some external means. Thank you anyway for your prompt answer.
I think the system is simply not designed for that. For what you want, I think Int32 would need to be a class, not an instance, so that it could be subclassed while retaining a relatively simple C implementation. As you noted, the C infrastructure works using a type mapping table which maps type *instances* onto type numbers, so it won't work as it is now. Regards, Todd
Hi Ivan, I might be ignorant because if have never heard about the "same-but-distinguishable" concept (except from general oo-deriving of course). But I might actually have a similar situation. I have a 3d-image file-format which I wanted to handle mostly just by it's pixel-data content, that is: I return it as numarray. But to allow me to access the extra (header) information that comes with that file-format I "stick" a new attribute into the numarray instance. (this must sound very surprising to e.g. C++-people put is standard python as I understand) So here is some outline of my code: ''' class Mrc: # our "mrc"-file-format def __init__(self): open-file, make memmap for header+ data data.Mrc = self # this is the "sticking-in part" return data ''' This is very much paraphrased. I think __init__ doesn't have a return (so I use a seprarate function for that). And (after much debugging) I now use "weakref" for the "sticking-in part" to avoid circular references. Tell me if I guessed you case right (at least somewhat) ;-) Regards, Sebastian Haase On Monday 13 December 2004 08:48 am, Todd Miller wrote:
On Mon, 2004-12-13 at 11:23, Ivan Vilata i Balaguer wrote:
I'm trying to define new types that can be handled as normal types in numarray, but being different (distinguishable) from their equivalent types. For instance, an array of MyInt32 should work exactly as an Int32 array, but I would need to know it is a MyInt32 array and not an Int32 one.
However, I you believe that the system is not prepared for that (or it would require too much work) I will try to identify it by some external means. Thank you anyway for your prompt answer.
I think the system is simply not designed for that. For what you want, I think Int32 would need to be a class, not an instance, so that it could be subclassed while retaining a relatively simple C implementation. As you noted, the C infrastructure works using a type mapping table which maps type *instances* onto type numbers, so it won't work as it is now.
Regards, Todd
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
On Mon, Dec 13, 2004 at 11:48:23AM -0500, Todd Miller wrote:
[...] I think the system is simply not designed for that. For what you want, I think Int32 would need to be a class, not an instance, so that it could be subclassed while retaining a relatively simple C implementation. As you noted, the C infrastructure works using a type mapping table which maps type *instances* onto type numbers, so it won't work as it is now.
Uh, what a pity. I thougth that creating new instances with IntegralType and FloatingType would be more useful. I will try with subclassing NumArray and RecArray as I was discussing with Colin. Thanks a lot for your help and useful information. Regards, Ivan -- Ivan Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data ""
On Mon, Dec 13, 2004 at 12:39:29PM +0100, Ivan Vilata i Balaguer wrote:
Hi all! I am trying to define new numeric types to use them in NumArray and RecArray objects. [...]
Hello again. I have started to code a subclass of RecArray to map custom instance types (MyInt32) to standard Numarray instance types (Int32). The task seems plausible once numarray.typeDict, numarray.records.numfmt and numarray.records.revfmt are tailored to support the new types. Translating a format specification like formats='1MyInt32,(2,3)f8' to formats='1Int32,(2,3)f8' looks hard but it is a question of time. However, I have come across the fact that the constructors for NumArray and RecArray are seldom used directly. Instead, functions like numarray.array() and numarray.records.array() are used. These make heavy transformations on their arguments and then create new {Num,Rec}Array objects. This fact makes using classes different to {Num,Rec}Array very difficult, even more when using different signatures for their constructors. One solution is redefining the aforementioned functions to use custom classes. However, this looks cumbersome and not a simple task, but it seems to me the only way to keep the numarray interface. So I will try to implement those new types around Numarray instead of at the same level. Well, this was my report on my attempt to define new Numarray types! Thank you again for your suggestions. Best wishes, Ivan import disclaimer -- Ivan Vilata i Balaguer >qo< http://www.carabos.com/ Cárabos Coop. V. V V Enjoy Data ""
participants (3)
-
Ivan Vilata i Balaguer -
Sebastian Haase -
Todd Miller