Should np.round, np.floor, np.ceil require dimensionless arguments?

[TAU-Reinier]

Currently, np.round, np.floor, and np.ceil work according to the matching_input_copy_units_output_ufuncs rule, meaning the output unit matches the input unit:

np.round(Q_(1.2345, 'm')) == Q_(1.0, 'm')

However, the same Quantity can give a different result:

Q_(1.2345, 'm') == Q_(1234.5, 'mm')   # is True
np.round(Q_(1234.5, 'mm')) == Q_(1234.0, 'mm')   # != Q_(1.0 'm')

It gets more unpredictable in cases such as:

total_time = Q_(1.0, 'second')
time_step = Q_(2.0, 'millisecond')
time_axis_length = int(np.ceil(total_time / time_step))

which gives axis length 1000 instead of 500 because int(np.ceil(Q_(0.5, 'second/millisecond'))) == int(Q_(1.0, 'second/millisecond')) == 1000

Moreover, the behavior of np.ceil and np.floor differ from math.ceil and math.floor:

math.ceil(total_time / time_step) == 500   # as would be intuitively expected
math.ceil(Q_(1.2345, 'm'))   # raises DimensionalityError

Should np.floor and np.ceil, and possibly np.round, require dimensionless arguments like math.ceil and math.floor do?

I would argue yes, because I expect a == b to imply func(a) == func(b) for all three of these, and Q_(2.0, 'ms') == Q_(0.002, 'sec') is True.

Moreover, I would argue that something like floor(1.2345 m) isn't meaningful, because what is the floor() of a distance or length? I realize a possible use case would be an engineer who can only order parts in millimeter increments. But I think requiring the explicit np.floor(Q_(1.2345, 'm').m_as('mm')), as well as throwing an error on np.floor(Q_(1.2345, 'm')), can prevent disastrous errors!

It looks to me like simply moving "round", "floor", and "ceil" from matching_input_copy_units_output_ufuncs to set_units_ufuncs would do it, though this would be a breaking change.