Type promotion rules regression (migrated from Trac #1798) #3346

thouis · 2012-09-27T04:16:48Z

Original ticket http://projects.scipy.org/numpy/ticket/1798
Reported 2011-04-11 by atmention:mwiebe, assigned to atmention:mwiebe.

[scalar float64]*[array int8] should produce [array float64], but when the value of the scalar float64 is small, it may produce [array float16] or [array float32]. Here is the current behavior:

>>> 3.1*np.ones(2,dtype=np.int8)
array([ 3.09960938,  3.09960938], dtype=float16)
>>> 1e10*np.ones(2,dtype=np.int8)
array([  1.00000000e+10,   1.00000000e+10], dtype=float32)
>>> 1e40*np.ones(2,dtype=np.int8)
array([  1.00000000e+40,   1.00000000e+40])

I propose a fix in two parts.

Fix this in the PyArray_ResultType/numpy.result_type function of the type promotion API. In particular, the algorithm should track the promoted array and scalar types separately, then if the kind of the promoted scalar type is greater than the kind of the promoted array type, continue the promotion of the promoted array type with the scalars without using minscalartype.
Change the ufunc to detect binary operators during creation, and set a flag for it. Then, during evaluation, use PyArray_ResultType to do the type promotion for binary operators instead of the existing slow linear search. The ufunc doesn't have a flags field, but it does have a field called 'check_return' which is unused, and could be repurposed as a flags field without changing the size of the python type.

The text was updated successfully, but these errors were encountered:

thouis · 2012-09-27T04:16:49Z

Comment in Trac by atmention:mwiebe, 2011-04-11

thouis · 2012-09-27T04:16:49Z

Comment in Trac by atmention:charris, 2011-04-11

I don't think the conversion should depend on the size. The old numpy behavior for scalars was python int -> long (or was it long long, I need to check), python float -> double, python complex -> complex128, other types were achieved by explicit casts, i.e., np.int8(5).

thouis · 2012-09-27T04:16:49Z

Comment in Trac by atmention:mwiebe, 2011-04-11

The old behavior depended on the scalar value in the same way, except it only used the scalar's value to detect int -> uint. This is so that [float64 scalar]*[float32 array] produces a [float32 array] instead of a [float64 array]. Without this rule, using float32 arrays is almost impossible since they will be promoted to float64 in many circumstances. I generalized it to also use the value to avoid obvious overflows.

1.5.x and earlier:
>>> 100000_np.ones(2,dtype=np.int8)
array([-31072, -31072], dtype=int16)
>>> 1e60_np.ones(2,dtype=np.float32)
array([ Inf, Inf], dtype=float32)

1.6 and later:
>>> 100000_np.ones(2,dtype=np.int8)
array([100000, 100000], dtype=int32)
>>> 1e60_np.ones(2,dtype=np.float32)
array([ 1.00000000e+60, 1.00000000e+60])

thouis · 2012-09-27T04:16:49Z

Comment in Trac by atmention:mwiebe, 2011-04-13

Proposed fix here: numpy/numpy#73

thouis · 2012-09-27T04:16:49Z

Comment in Trac by atmention:mwiebe, 2011-04-22

Fixed in commit:fbdc4b7 (master) and commit:cc55973 (1.6.x).

thouis closed this as completed Sep 27, 2012

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Type promotion rules regression (migrated from Trac #1798) #3346

Type promotion rules regression (migrated from Trac #1798) #3346

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Type promotion rules regression (migrated from Trac #1798) #3346

Type promotion rules regression (migrated from Trac #1798) #3346

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!