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

Discussion: input and output argument type casting #5

Open
AartGoossens opened this issue Mar 10, 2018 · 2 comments
Open

Discussion: input and output argument type casting #5

AartGoossens opened this issue Mar 10, 2018 · 2 comments

Comments

@AartGoossens
Copy link
Contributor

@sladkovm This is the discussion we started before. Shall we continue here?

For algorithms it is possible to accept multiple input argument types and cast them to a desirable type and cast the output to a type similar to the input type (example of a method that does this in the vmpy source code).

Benefits:

  • Usage of the algorithms is more straightforward when you don't have to worry about the input types
  • ...

Drawbacks:

  • Input argument type is part of the interface specification. Allowing multiple input types might make the interface vague
  • It is not possible to accept all input types. How do we communicate what is/is not possible?
  • Unittesting for multiple input types is a hassle
  • ...

I have a preference for accepting (i.e. developing for) one input type.

Alternative solution: It might be possible to add input and output argument type casting by decorating the algorithms "on the fly" by calling a helper function after import (sort of similar to this). It's not the cleanest way to do it but it might work, I'll try to make a POC for this. For me this would solve the drawbacks and it would still offer input/output type casting for users that do want it.

@sladkovm
Copy link
Contributor

I have myself second thoughts about supporting all array-like inputs - it makes type transformation very opaque for the user. To put it differently, I'm convinced now that converting lists to ndarrays and back should be a user's headache. If we can design a decorator for it - it would be nice, but not a must.

More interesting question - could we make the ndarray as a default input type, but than still design all algorithms/ function to work directly with pd.Series as well? Basically, repeat what NumPy does already.

@sladkovm sladkovm mentioned this issue Mar 10, 2018
@AartGoossens
Copy link
Contributor Author

AartGoossens commented Mar 10, 2018

pandas.Series is in a way a wrapper around numpy.ndarray so my expectation is that in most cases it will just work. E.g.

>>> import numpy as np
>>> import pandas as pd
>>> a = pd.Series([1, 2, 3, 4])
>>> np.power(a, 2)
0     1
1     4
2     9
3    16
dtype: int64
>>>

I want to prevent if-statements in the algorithms like:

if isinstance(power, pd.Series):
    # do this
else:
    # do that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants