Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arithmetic operations on complex SpectralData #199

Closed
tensionhead opened this issue Feb 3, 2022 · 2 comments
Closed

Arithmetic operations on complex SpectralData #199

tensionhead opened this issue Feb 3, 2022 · 2 comments
Assignees
Labels
Bug An error that is serious but does not break (parts of) the package. However, it clearly impedes the

Comments

@tensionhead
Copy link
Contributor

When trying to multiply a float to a complex64 type SpectralData object

res = spy.freqanalysis(data)
res * 2.2

a SPYTyperError is thrown:

SPYTypeError: Wrong type of `operand`: expected scalar of same mathematical type (real/complex) found float

Even an int should also of course work here in this case!

@tensionhead tensionhead added the Bug An error that is serious but does not break (parts of) the package. However, it clearly impedes the label Feb 3, 2022
@pantaray
Copy link
Member

pantaray commented Feb 3, 2022

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 ?

@tensionhead
Copy link
Contributor Author

Well, as long as one operand is a simple scalar (be it float, int or complex), I don't see any other checks being necessary!

pantaray added a commit that referenced this issue Feb 14, 2022
- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug An error that is serious but does not break (parts of) the package. However, it clearly impedes the
Projects
None yet
Development

No branches or pull requests

2 participants