[Numpy-discussion] find_common_type broken?
Wed Jul 15 23:39:44 CDT 2009
On Jul 13, 2009, at 1:54 PM, Ralf Gommers wrote:
> On Sun, Jul 12, 2009 at 1:24 PM, Citi, Luca <email@example.com> wrote:
> > That is what I thought at first, but then what is the difference
> > array_types and scalar_types? Function signature is:
> > *find_common_type(array_types, scalar_types)*
> As I understand it, the difference is that in the following case:
> np.choose(range(5), [np.arange(1,6), np.zeros(5, dtype=np.uint8),
> 1j*np.arange(5), 22, 1.5])
> one should call:
> find_common_type([np.int64,np.uint8,np.complex128], [int,float])
> I had a look at the code and it looks like
> dtype1 < dtype2 if dtype1 can safely be broadcasted to dtype2
> As this is not the case, in either direction, for int32 and float32,
> then neither dtype(int32) < dtype(float32) nor dtype(int32) >
> and this causes the problem you highlighted.
> I think in this case find_common_type should return float64.
> The same problem arises with:
> >>> np.find_common_type([np.int8,np.uint8], )
> >>> np.find_common_type([np.uint8,np.int8], )
> here too, I think find_common_type should return e third type
> which is the "smallest" to which both can be safely
> broadcasted: int16.
> find_common_type() was added after a problem with r_ was reported in
> ticket 728. r_ still has a problem as well:
> >>> np.r_[1+1e-10, np.arange(2, dtype=np.float32)] - 1
> array([ 0., -1., 0.], dtype=float32)
This is not a problem with r_. This is correct behavior. A scalar
"float" will not cause an array "float32" to be upcast.
Nonetheless, the OP did point out a flaw in find_common_type that has
been fixed in r7133.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion