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

bfast() integration #12

Open
fdetsch opened this issue Nov 30, 2020 · 6 comments
Open

bfast() integration #12

fdetsch opened this issue Nov 30, 2020 · 6 comments
Labels
question Further information is requested

Comments

@fdetsch
Copy link

fdetsch commented Nov 30, 2020

Thanks for your work. Are there plans to integrate the "traditional" bfast() function as well?

@mortvest
Copy link
Collaborator

mortvest commented Nov 30, 2020

You're welcome! Yes, we are currently working on the integration of the BFAST algorithm (bfast() R function). We have an early prototype of the Python backend, and it would be integrated to the bfast-experimental branch in the near future. Regarding the OpenCL backend, it is a huge amount of work that hopefully would be somewhat ready around summer.

@mortvest mortvest added the question Further information is requested label Nov 30, 2020
@fdetsch
Copy link
Author

fdetsch commented Nov 30, 2020

Awesome! Ultimately, a Python version of R bfast() enhanced with OpenCL would be a massive benefit as regards performance. Do you expect the native Python version (ie. without OpenCL) to be already superior to R bfast() from a performance point of view?

@mortvest
Copy link
Collaborator

mortvest commented Nov 30, 2020

Sadly, I expect the native Python version to be a bit slower, since the most computationally intensive operations in the R version are written in C++. Multiprocessing can be utilized to get some speedup though

@fdetsch
Copy link
Author

fdetsch commented Nov 30, 2020

Argh, alright.. in any event, I am eager to see both the native and OpenCL based approach being implemented (:

@mirt001
Copy link

mirt001 commented Dec 8, 2020

@fdetsch while @mortvest is right that the most intensive parts of the R version are written in C++, this is only true for the latest version of strucchange and bfast found at https://github.com/bfast2 . The default CRAN version is slower.

Even so, I would expect the Python version to be less memory intensive because R strictly uses 4 bytes numbers.

@mortvest
Copy link
Collaborator

mortvest commented Dec 8, 2020

Hmm, interesting. Thank you for your input @mirt001

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

No branches or pull requests

3 participants