[Numpy-discussion] dtype.isbuiltin changed by .newbyteorder

Robert Kern robert.kern at gmail.com
Thu Jan 14 10:53:14 EST 2010

On Thu, Jan 14, 2010 at 07:01, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
> Over on the scipy list, someone pointed out an oddness in the output
> of the matlab reader, which revealed this - to me - unexpected
> behavior in numpy:
> In [20]: dt = np.dtype('f8')
> In [21]: dt.isbuiltin
> Out[21]: 1
> In [22]: ndt = dt.newbyteorder('<')
> In [23]: ndt.isbuiltin
> Out[23]: 0
> I was expecting the 'isbuiltin' attribute to be the same (1) after
> byte swapping.    Does that seem reasonable to y'all?  Then, is this a
> bug?

It is at least undesirable. It may not be a bug per se as I don't
think that we guarantee that .isbuiltin is free from false negatives
(though we do guarantee that it is free from false positives). The
reason is that we would have to search the builtin dtypes for a match
every time we create a new dtype object, and that could be more
expensive than we care to do for *every* creation of a dtype object.
It is possible that we can have a cheaper heuristic (native byte order
and the standard typecodes) and that transformations like
.newbyteorder() can have just a teeny bit more intelligent logic about
how it transforms the .isbuiltin flag.

Just for clarity and future googling, the issue is that when a native
dtype has .newbyteorder() called on it to make a new dtype that has
the *same* native byte order, the .isbuiltin flag incorrectly states
that it is not builtin. Using .newbyteorder() to swap the byte order
to the non-native byte order should and does cause the resulting dtype
to not be considered builtin.

Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco

More information about the NumPy-Discussion mailing list