[Numpy-discussion] find_common_type broken?
Thu Jul 16 00:59:56 CDT 2009
On Thu, Jul 16, 2009 at 12:39 AM, Travis Oliphant <firstname.lastname@example.org>wrote:
> 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 between
>> > 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.
This was at first counter-intuitive but I found the reason for it in Guide
to Numpy now:
"Mixed scalar-array operations use a different set of casting rules that
a scalar cannot upcast an array unless the scalar is of a fundamentally
of data (i.e. under a different hierarchy in the data type hierarchy) then
This rule enables you to use scalar constants in your code (which as Python
are interpreted accordingly in ufuncs) without worrying about whether the
of the scalar constant will cause upcasting on your large (small precision)
> Nonetheless, the OP did point out a flaw in find_common_type that has been
> fixed in r7133.
Great, it works for me now.
There is still one rule I do not understand the reason for. Out of
curiosity, what is the reason for this:
In : can_cast(int32, float32)
In : can_cast(int64, float64)
> Best regards,
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion