Jacob Williams

Do you want to pull the latest `main` into this and have it run the tests? (looks like there are some conflicts)

Another option: use something like what I describe here: https://fortran-lang.discourse.group/t/library-exporting-interface-for-multiple-real-kinds/2686 to provide all the interfaces simultaneously. Is that useful for some applications? IDK.

This is what I do in my codes: ```fortran module splpak_module use iso_fortran_env implicit none private #ifdef REAL32 integer,parameter :: wp = real32 !! Real working precision [4 bytes] #elif...

I don't think we need it for anything. We [tested](https://github.com/jacobwilliams/minpack-tester) the refactored version against the original one and made sure the results were the same. I think ours is superior...

Note: see also https://github.com/jacobwilliams/nlesolver-fortran, a basic solver that does use Lapack.

For me, step 1 is to modernize the code (coding style, comments, autodeployment of docs, CI, unit tests, FPM integration), then step 2 is to see about improving the algorithms...

Unfortunately, the license on the Powell solvers is somewhat clouded now. See [this thread](https://github.com/jacobwilliams/PowellOpt/issues/3). I think it would be better to stick with MIT/BSD for this library and not risk...

I would highly recommend not moving F77 code to fortran-lang. Or wrapping F77 with a modern interface. I think that is a bad idea. We need to modernize the code...

We need to modernize the API. We can't hold up something that requires you to stuff your problem data into `iwork` and `rwork` arrays as any kind of modern way...

I absolutely support using the legacy code. There's no need to rewrite it from scratch. All I was warning against was being locked into the old api or coding style...