Allow to specify dtype and shape without type inference for Signal description
Closed this issue · 1 comments
(similar issue to #1178)
The signal description (.describe()) method guesses the dtype and shape of a Signal value,
from the default value passed to Signal constructor.
This leads to a type mismatch, rendering the implementation insufficiently robust. Initializing a
value with 0 does not inherently indicate that the signal is an integer; more frequently, the signal
is a float.
The describe() function would be better useful to get real information about the signal,
when considering who or what is interpreting the data—whether it be a human or a process
recording Ophyd data for example. The differentiation between numpy.uint32, numpy.int64, and
a generic integer is significant and must be maintained to ensure data validation.