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

integrate numpy datetime64 for greater range of years #77

Closed
2 tasks done
rlskoeser opened this issue Jun 6, 2024 · 4 comments
Closed
2 tasks done

integrate numpy datetime64 for greater range of years #77

rlskoeser opened this issue Jun 6, 2024 · 4 comments
Assignees
Labels
resolved resolved but not yet released (merged to main) until ticket is closed
Milestone

Comments

@rlskoeser
Copy link
Member

rlskoeser commented Jun 6, 2024

  • how much does the code change? how much does numpy.datetime64 help, how heavy of a dependency is this?
  • could this be optional, for people who need the expanded year range but not installed by default?

benchmarking / documentation:

  • how long does it take to run the test suite with/without numpy?
  • how big is the installation size with/without?
@rlskoeser
Copy link
Member Author

next steps:

  • check numpy depedencies; check 1.2 and 2.0 - difference in size? does the change break anything?
  • fully implement clean numpy datetime shims and add typing, tests, docs, etc
  • document numpy integration and any information about recommended versions, dependencies, etc.

@rlskoeser
Copy link
Member Author

From NumPy installation docs:

NumPy doesn’t depend on any other Python packages, however, it does depend on an accelerated linear algebra library - typically Intel MKL or OpenBLAS. Users don’t have to worry about installing those (they’re automatically included in all NumPy install methods)

@rlskoeser rlskoeser changed the title test integrating numpy datetime64 for greater range of years integrate numpy datetime64 for greater range of years Oct 3, 2024
rlskoeser added a commit that referenced this issue Nov 7, 2024
Use numpy datetime64  instead of datetime.date #77
@rlskoeser rlskoeser added the resolved resolved but not yet released (merged to main) until ticket is closed label Nov 7, 2024
@rlskoeser
Copy link
Member Author

@ColeDCrawford as I close this out, I remembered you wanted some benchmarking / assessment on the numpy inclusion. The test suite is pretty fast either way, and we've also been expanding the functionality in other ways, so it's not a strict comparison.

Running a checkout of the 0.2 tag, I get

113 passed in 0.11s

Running in current develop, I get

138 passed in 0.16s

I compared the virtualenv size when installing version 0.2 and current develop. Without numpy, the virtualenv is 14MB; with numpy it's 46MB. Looking at the folders in the sitep ackages for the latter, the numpy folder is 31MB on its own.

Let me know if you think any of this needs to be documented in the changelog or elsewhere.

@ColeDCrawford
Copy link
Collaborator

Nice, thanks for remembering that. Seems like a negligible performance difference with the main change being the payload size, but we knew about that going in. I think it would be nice to note in the changelog for the v1.0 release

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolved resolved but not yet released (merged to main) until ticket is closed
Projects
None yet
Development

No branches or pull requests

2 participants