You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ha, that seems a little overly cautious ;) The intention of the underlying query in the code is to avoid that a complex number is "applied to" (i.e., added/subtracted/multiplied/divided) a real-valued data-set. The above example is of course obviously a bug in the query, however, I'm asking myself: do we actually want to gate-keep this at all? Maybe there are edge-cases, where I want to "convert" my data by multiplying by 1 + 0j? Maybe we should remove this type-check completely? What do you think @tensionhead ?
- do not print message on in-place selections but rather print some info if
a data-selection actually triggers on-disk copying (closes#199)
- amended docstrings of `_preview_trial` in `ContinousData` and `DiscreteData`
to highlight that these helpers can be used to easily (and cheaply) pseudo-
evaluate the effect of data selections
On branch fixes
Changes to be committed:
modified: syncopy/datatype/continuous_data.py
modified: syncopy/datatype/discrete_data.py
modified: syncopy/datatype/methods/selectdata.py
When trying to multiply a
float
to acomplex64
type SpectralData objecta
SPYTyperError
is thrown:Even an
int
should also of course work here in this case!The text was updated successfully, but these errors were encountered: