[Numpy-discussion] Bug in numarray.typecode()?
Philip Austin
paustin at eos.ubc.ca
Tue Jul 6 09:31:05 EDT 2004
Todd Miller writes:
> >
> > Should this print 'U'?
>
> I think it could, but I wouldn't go so far as to say it should.
> typecode() is there for backward compatibility with Numeric. Since 'U'
> doesn't work for Numeric, I see no point in adding it to numarray. I'm
> not sure it would hurt anything other than create the illusion that
> something which works on numarray will also work on Numeric.
>
> If anyone has a good reason to add it, please speak up.
>
I don't necessarily need typecode, but I couldn't find the
inverse of
a = array([10], type = 'UInt8') (p. 19)
in the manual.
That is, I need a method that returns the string representation of a
numarray type in a single call (as opposed to the two-step
repr(array.type()). This is for code that uses the Boost C++ bindings
to numarray. These bindings work via callbacks to python (which
eliminates the need to link to the numarray or numeric api). Currently
I use typecode() to get an index into a map of types when I need to
check that the type of a passed argument is correct:
void check_type(boost::python::numeric::array arr,
string expected_type){
string actual_type = arr.typecode();
if (actual_type != expected_type) {
std::ostringstream stream;
stream << "expected Numeric type " << kindstrings[expected_type]
<< ", found Numeric type " << kindstrings[actual_type] << std::ends;
PyErr_SetString(PyExc_TypeError, stream.str().c_str());
throw_error_already_set();
}
return;
}
Unless I'm missing something, without typecode I need a second
interpreter call to repr, or I need to import numarray and load all
the types into storage for a type object comparison. It's not a
showstopper, but since I check every argument in every call, I'd like
to avoid this unless absolutely necessary.
Regards, Phil
More information about the NumPy-Discussion
mailing list