HLSVDPro v2.x is based on the extended algorithm in the 2002 JMR paper by Laudadio.
In creating the HLSVDPro v2.x package, I started with the Jake Vanderplas code for just the PROPACK v2.2 libray. I had to modify it quite a bit. As our wiki states, we developed HLSVDPro to work within the ‘Vespa' project (https://scion.duhs.duke.edu/vespa/project) and wanted it to be as self contained as possible. For HLSVDPro v2.x that meant that I could not assume that there would be a ‘system LAPACK or BLAS' available.
So to create the PROPACK v2.2 library, I had to add in all the missing library files for those calls that PROPACK needed. And I could not assume that the gfortran library would be available, so I had to figure out how to statically link that in. So basically, I'm breaking all the rules of ‘reusable code' in the name of making it work on Windows.
Anyway, I added all the files to PROPACK source tree for the single, double, complex and dcomplex versions of the library. I used f2py to generate some of the wrapping code for calling FORTRAN from Python. But I had to ‘hand wrap' Makefiles to enforce static linking, and just use trusty old ‘make' to do the actual compiling. I then created LOTS of different libraries, because f2py had to be linked against whatever version of Python was going to call it.
There are libraries for: 1) single, double, complex, dcomplex PROPACK, 2) Python 27, 36, 37, 38, and 3) Linux, Windows, MacOS … so, LOTS, like 48. The Makefiles help with some of this. But, eventually, I have to make Python wheels for the different versions. Just FYI, the main reason for using f2py (from Jake Vanderplas) was to allow a user to define the matrix product function call (Aprod) as a Python function and then pass that into the FORTRAN call. This required that (d)complex numbers be sent in, and CTYPES does not handle those types. So, f2py to the rescue and more complexity. But now, back to our story …
Now that I had the PROPACK v2.2 library available in Python, I worked on porting the HLSVDPro algorithm from FORTRAN to Python. That ended up being pretty easy, since all the necessary LAPACK calls seemed to either be available in Scipy.lapack, or equivalent calls were present in Numpy or Scipy themselves.
The actual Python algorithm (without comments) is only about 15 lines long and runs about as fast as pure FORTRAN, but with more flexibility.