numarray, Numeric and 64-bit platforms
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
Hi, I'm having problems converting numarray objects into Numeric in 64-bit platforms, and I think this is numarray fault, but I'm not completely sure. The problem can be easily visualized in an example (I'm using numarray 1.3.1 and Numeric 24.0b2). In a 32-bit platform (Intel32, Linux):
In 64-bit platforms (AMD64, Linux):
The problem is that, for 32-bit platforms, na.typecode() == 'i' as it should be, but for 64-bit platforms na.typecode() == 'N' that is not a valid type in Numeric. I guess that na.typecode() should be mapped to 'l' in 64-bit platforms so that Numeric can recognize the Int64 correctly. Any suggestion? --
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Tue, 2005-04-26 at 13:42, Francesc Altet wrote:
I agree that since the typecode() method exists for backward compatibility, returning 'N' rather than 'l' on an LP64 platform can be considered a bug. However, there are two problems I see: 1. Returning 'l' doesn't handle the case of converting a numarray Int64 array on a 32-bit platform. AFIK, there is no typecode that will work for that case. So, we're only getting a partial solution. 2. numarray uses typecodes internally to encode type signatures. There, platform-independent typecodes are useful and making this change will add confusion. I think we may be butting up against the absolute/relative type definition problem. Comments? Todd
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
A Dimarts 26 Abril 2005 22:55, Todd Miller va escriure:
One can always do a separate case for 64-bit platforms. This solution is already used in Lib/numerictypes.py
Well, this is the root of the problem for 'l' (long int) types, that their meaning depends on the platform. Anyway, I've tried with the next patch, and everything seems to work well (i.e. it's done what it is itended): -------------------------------------------------------------- --- Lib/numerictypes.py Wed Apr 27 07:13:08 2005 +++ Lib/numerictypes.py.modif Wed Apr 27 07:21:48 2005 @@ -389,7 +389,11 @@ # at code generation / installation time. from codegenerator.ufunccode import typecode for tname, tcode in typecode.items(): - typecode[ eval(tname)] = tcode + if tname == "Int64" and numinclude.LP64: + typecode[ eval(tname)] = 'l' + else: + typecode[ eval(tname)] = tcode + if numinclude.hasUInt64: _MaximumType = { --------------------------------------------------------------- With that, we have on 64-bit platforms:
and on 32-bit:
Which should be the correct behaviour.
I think we may be butting up against the absolute/relative type definition problem. Comments?
That may add some confusion, but if we want to be consistent with the 'l' (long int) meaning for different platforms, I think the suggested patch (or other more elegant) is the way to go, IMHO. Cheers, --
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Wed, 2005-04-27 at 08:32, Francesc Altet wrote:
True. I'm just pointing out that doing this is still "half broken". On the other hand, it is also "half fixed".
My point was that if you have a numarray Int64 array, there's nothing in 32-bit Numeric to convert it to. Round tripping from Numeric-to-numarray works, but not from numarray-to-Numeric. In this case, I think "half-fixed" still has some merit, I just wanted it to be clear what we're not doing.
I logged this on Source Forge and will get something in for numarray-1.4 so that the typecode() method gives a workable answer on LP64. Intersted parties should stick to using the typecode() method rather than any of numarray's typecode related mappings. Cheers, Todd
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Tue, 2005-04-26 at 13:42, Francesc Altet wrote:
I agree that since the typecode() method exists for backward compatibility, returning 'N' rather than 'l' on an LP64 platform can be considered a bug. However, there are two problems I see: 1. Returning 'l' doesn't handle the case of converting a numarray Int64 array on a 32-bit platform. AFIK, there is no typecode that will work for that case. So, we're only getting a partial solution. 2. numarray uses typecodes internally to encode type signatures. There, platform-independent typecodes are useful and making this change will add confusion. I think we may be butting up against the absolute/relative type definition problem. Comments? Todd
![](https://secure.gravatar.com/avatar/5c7407de6b47afcd3b3e2164ff5bcd45.jpg?s=120&d=mm&r=g)
A Dimarts 26 Abril 2005 22:55, Todd Miller va escriure:
One can always do a separate case for 64-bit platforms. This solution is already used in Lib/numerictypes.py
Well, this is the root of the problem for 'l' (long int) types, that their meaning depends on the platform. Anyway, I've tried with the next patch, and everything seems to work well (i.e. it's done what it is itended): -------------------------------------------------------------- --- Lib/numerictypes.py Wed Apr 27 07:13:08 2005 +++ Lib/numerictypes.py.modif Wed Apr 27 07:21:48 2005 @@ -389,7 +389,11 @@ # at code generation / installation time. from codegenerator.ufunccode import typecode for tname, tcode in typecode.items(): - typecode[ eval(tname)] = tcode + if tname == "Int64" and numinclude.LP64: + typecode[ eval(tname)] = 'l' + else: + typecode[ eval(tname)] = tcode + if numinclude.hasUInt64: _MaximumType = { --------------------------------------------------------------- With that, we have on 64-bit platforms:
and on 32-bit:
Which should be the correct behaviour.
I think we may be butting up against the absolute/relative type definition problem. Comments?
That may add some confusion, but if we want to be consistent with the 'l' (long int) meaning for different platforms, I think the suggested patch (or other more elegant) is the way to go, IMHO. Cheers, --
![](https://secure.gravatar.com/avatar/faf9400121dca9940496a7473b1d8179.jpg?s=120&d=mm&r=g)
On Wed, 2005-04-27 at 08:32, Francesc Altet wrote:
True. I'm just pointing out that doing this is still "half broken". On the other hand, it is also "half fixed".
My point was that if you have a numarray Int64 array, there's nothing in 32-bit Numeric to convert it to. Round tripping from Numeric-to-numarray works, but not from numarray-to-Numeric. In this case, I think "half-fixed" still has some merit, I just wanted it to be clear what we're not doing.
I logged this on Source Forge and will get something in for numarray-1.4 so that the typecode() method gives a workable answer on LP64. Intersted parties should stick to using the typecode() method rather than any of numarray's typecode related mappings. Cheers, Todd
participants (2)
-
Francesc Altet
-
Todd Miller