ENH: optimize.minimize: Expose LINCOA, BOBYQA, NEWUOA, and UOBYQA #21554
Comments
lucascolley
changed the title
|
x-ref gh-1477 |
|
Thanks for opening this issue :). The important question is which ones of the algorithms we really want. From what I understand, BOBYQA actually supersedes NEWUOA and UOBYQA. LINCOA I do not know much about.. is something between BOBYQA and COBYQA or more similar to COBYLA? |
|
cc @gnikit I think you brought this topic up at the summit? (may be thinking of someone else!) |
|
cc @janosg also |
|
Hi @lucascolley, thanks for the ping! My understanding is as follows: NEWUOA (2004) was Powell's first solver to use underdetermined quadratic trustregion models with 2n + 1 interpolation points, resolving the remaining degrees of freedom by penalizing the change in the Hessian terms of the quadratic models. Prof. Powell is very fond of this approach, even though he discovered it almost by accident:
BOBYQA (2009), LINCOA (2013) and COBYQA (2022) use this same approach and extend NEWUOA to handle bound constraints, linear constraints and nonlinear constraints, respectively. However, I would argue that none of the later solvers supersedes an earlier solver as the earlier solvers might perform better if the extensions are not needed. For example, NEWUOA might perform better than BOBYQA if no bound constraints are present because it can use a spherical trust-region instead of a cube shaped trust-region, which in my experience can help with performance. NEWUOA (2004) supersedes UOBYQA (2000); Both are designed for unconstrained problems. COBYQA (2022) supersedes COBYLA (1994); Both are designed for problems with nonlinear constraints. However, superseding only means that the later solver is expected to be better on average. There is no guarantee that the later solver will be better for every problem. I therefore see value in having access to all solvers. |
|
@nbelakovski I could work on exposing the solvers in scipy. I wanted to start contributing to scipy.optimize for a while and since I am already familiar with the solvers this might be a good starting point. |
|
(no fortran please) |
could you elaborate? Do you not want to take on the new functions if their (vendored) implementation is in Fortran? |
|
I thought the plan was that gradual removal of Fortran was the way forward. Python/c/python is much preferred. |
|
Perhaps it makes sense to implement the Python interface to the other PRIMA algorithms in a different package then, if we don't want to commit to new Fortran algorithms in SciPy? |
|
This seems like a more subtle situation than would be covered by "prefer no Fortran". If I understand correctly, we here get a better, maintained, modern Fortran version of something that had an old unmaintained F77 implementation. So surely the answer to the replacements is - clearly yes for now, until we have a C implemention. Then the question is - should we make use of the other optimizers that we get for free. I would have thought the answer would be yes there too ... until we have a C implementation. |
|
There was a discussion on Slack a couple of weeks ago (sep3) out this kind of thing. Essentially use the newer implementation to replace cobyla (new Fortran better than old Fortran). For new algos it would be preferred if it was c/python/python. Always open for a further discussion tho |
|
It would be good to place a summary of that policy discussion on the Discourse. |
It's a little hard to summarize, as I don't think we came to any consensus. Four contributors responded, with four semi-overlapping areas of concern. I also don't want to quote people out of context, as people may have given off-the-cuff answers. If you'd like, I could re-post my original question to the Discourse, and see what the consensus is there? Edit: I have now done this: https://discuss.scientific-python.org/t/is-adding-new-fortran-to-scipy-generally-allowed/1438 |
That would be great, actually. Can back-link to #18566 and an older Discourse (or maybe even scipy-dev ML) post by Ralf about Fortran. |
I looked through all of his Discourse posts, and I did a little searching on scipy-dev, and I couldn't find Ralf Gommer's post on this subject. Could you give me a link? |
|
I'll super-summarize what I learned in the last 20 months; after reading some 90K lines of F77 code, I came to the conclusion that I can't read modern Fortran, it's a completely new language, many moving parts. So there needs to be a nuance. And I can't learn yet another language that I don't like. Instead I'd work on C3, Zig whatever. The old JurassicPACK, fine, I invested stupid amount of time and we are getting there one goto at a time, I can now read and translate that horror. But! modern Fortran is F77 with classes, if you recognize that phrase then that's exactly my worry about getting more modern fortran code in. I don't mean to take away any value from thankless work the authors put into these solvers but as I mentioned multiple times, the actual question is are we going to be able to maintain this code 15 years later? (We as in the royal we). Example; This code is very new so enthusiasm is high but we also need to think about post-honeymoon phase. I can help with all F77 we have, but I don't have any drive left to touch modern fortran. So the question is who wants to dive into modern fortran? |
|
I'm willing to step up and help maintain this code. Most of it is pretty well written, although there are some details in the implementation of the trust region steps which is horrid, but every codebase has warts. The nice thing is that there's clear interfaces with good documentation about what the parameters are supposed to be and lots of comments throughout the code. We're at risk of veering off topic here, but @ilayn could you clarify what you mean about modern Fortran being F77 with classes? The PRIMA codebase doesn't use classes in Fortran (it doesn't even use derived types), and I just looked through the Fortran documentation and as far as I can tell it doesn't support any sort of object oriented programming? Overall I've found modern Fortran to be very functional-oriented, and the overall look and feel, from my point of view, is that it's very much like C but with intrinsic matrix operations. As regards the discussion about including new Fortran code, while I agree with the spirit of trying to modernize and consolidate, I feel an exception should be made for PRIMA. It's not like some of those old implementations which are just a handful of questionably named Fortran files and maybe some compile instructions if you're lucky. It's a modern codebase with a proper build system and CI tests. In any case, it's my understanding that the decision to include PRIMA to replace COBYLA has already been made, and the work of exposing the other 4 algorithms is just a question of going through the Python interface that PRIMA exposes. The work of compiling those algorithms is already done in the PR mentioned in the first comment of this issue, so any PR for this issue would be pure Python. |
|
When C++ came out they used to call it "C with classes". That's what I meant that it is a different language than F77. If it is clear and it does not have any fortran specific things then let's translate it. What I want to emphasize is that this involves risk. Just being available should not be a reason to add things regardless of functionality. Because when this hits the SciPy crowd, we will get questions issues etc. just like in case of Boost and Highs libraries. we are going to be knocking the door of the authors each and every time. Meanwhile, life can happen and people might move on. There is a nonnegligible risk that future maintainers of SciPy will be left alone with this fortran code. I want to make sure that we consider that risk appropriately before we take more code in. I hope you appreciate that we spent quite some effort to clean things up and we are a bit wary of repopulating our fortran tank. And if we are getting it in, at least get it in familiar form. If we are going to take them in, why don't we translate it now rather than later? The hard work is done and if it is written clearly it won't take too much effort to do the conversion. It is a plus for Prima team too. Instead of bindings you can just have native C code. Clean Fortran and clean C are quite similar except array indices. |
|
I would like to echo @ilayn point on support here. Whilst original authors have good will for support, a wider support base within the community is needed, otherwise the risk of things becoming orphaned is too high. There was also a viewpoint that the interface between Fortran and C (esp. the Python C-API) was a maintenance burden. |
Took me a while to find it again, too. The topic was different, but the discussion veered into the fortran-land: https://discuss.scientific-python.org/t/releasing-or-not-32-bit-windows-wheels/282 Also some previous discussion in the Fortran discourse: https://fortran-lang.discourse.group/t/the-difficulties-of-using-fortran-in-scipy/6753 |
|
I am gonna take a stab at this discussion without discussing the build issues as I do not know enough about that. So the issue boils down to: will SciPy be responsable for the maintenance of PRIMA in the long run? Rewriting it in C is possible but we would not benefit from any improvements in the upstream PRIMA repo that happen in Fortran. Nobody will keep two different implementations in sync and I do not think we can expect the PRIMA authors to develop the same code in Fortran and C. What I see is that there is a very deep personal motivation behind the PRIMA project by the "academic children" of Mike Powell to keep the legacy of his solvers alive. Maintenance wise, I think PRIMA is in a better shape than for example qhull which is the workhorse of If we do not want any more Fortran then we really need to reimplement PRIMA ourselves. Do we want that? My opinion is that sometimes black box dependencies need to be used as we simply cannot have expertise in every area of computational science under the condition that these dependencies are actively maintained. Boost is probably one of the most complex, heaviest templated C++ libraries there are and therefore not liked by everyone. But the Boost devs have been very responsive to issues raised by us, so this is not a problem in my opinion. |
|
I don't think we'd want to implement PRIMA ourselves, it'd be a long effort.
Even if we're not responsible for maintaining the sub-repo there are still maintenance issues, because the level of Fortran expertise within the scipy team is stretched. This means that it's hard for us to contribute upstream when we have an issue. Boost does have a big team contributing when they experience issues. |
|
I posted a summary at https://discuss.scientific-python.org/t/is-adding-new-fortran-to-scipy-generally-allowed/1438/3, perhaps better to continue any more general discussion there. |
|
@certik - do you have any thoughts about modern Fortran in Scipy? Discourse thread over at : https://discuss.scientific-python.org/t/is-adding-new-fortran-to-scipy-generally-allowed/1438 |
|
@matthew-brett I think @lucascolley summarized it pretty well. I think that SciPy developers who actually do the work of maintaining SciPy should choose the tooling and languages. It doesn't matter what I think. Based on the feedback above (@ilayn, @andyfaff, @nickodell), I think the direction is clear: just use C, C++, Cython and Python, but not Fortran if you can. That's what the maintainer community wants. We've been helping @ilayn answer any questions about Fortran over at the Fortran Discourse: https://fortran-lang.discourse.group/, he is very good at F77 now, much better than I am. But since you asked what I think, I am always happy to share what I think. :) But I want to stress that it really does not matter here, it must be the SciPy maintainers to decide. So I think that Fortran is a great language and it's ideal for scientific computing, much better than a combination of C, C++, Cython and Python, and I know all these languages very well. So I personally always use Fortran, so much easier to maintain, it's easy to write fast code, it compiles quickly, better error messages, etc., and then thin Python wrappers (using Cython usually) if needed. Fortran needs better tooling, so we are fixing that too. We made LFortran compile 60% of SciPy this year: https://lfortran.org/blog/2024/01/lfortran-compiles-60-of-scipy/ and I was hoping there would be some interest and excitement and even collaboration from the SciPy community, perhaps running it in WebAssembly and other things for the packages that fully work, but the only feedback I got from the SciPy community was from @ilayn (thank you!) and the feedback was that it's not needed, because SciPy is moving away from Fortran. So I am personally not focusing on SciPy anymore, and rather focusing on other Fortran projects that want to use LFortran once it can compile their codes. But the door is open, and if SciPy wants to collaborate, we would be happy to! So far I don't see it yet, but I think that will change too over time. Check out LFortran, it's a cool compiler (https://lfortran.org/), and it's written in C++, no Fortran! So I think you will like the internals. It compiles quickly, it's actively developed and easy to develop, and I think it's a very nice piece of technology and we are always looking for more contributors and we have funding, so if anybody here is interested to help out, please get in touch with me. For example you can help us with the Fortran to C/C++ translation backends that we have. :) And yes, LFortran runs in a Jupyter notebook allowing to use Fortran interactively. It also run in a browser: https://dev.lfortran.org/. We also have a subset of Python frontend to the compiler called LPython and it runs in the browser too: https://dev.lpython.org/. I think in general it's good to be a little more open-minded about Fortran. In the short-term you have to decide based on what people want today and the quality of production tooling today. In the long-term however I decide based on the potential of the language, and the trajectory things are going. Just imagine what happens once LFortran compiles all Fortran code. And Flang, which SciPy already uses on Windows, is even a bit ahead of us in the number of codes it can compile. Give it 5 more years for both compilers to mature and become rock solid. That will change everything in my opinion. So that's what I think. |
|
Thanks for the thoughts @certik ! Despite my lack of feedback (mainly because I am rather new to this stuff) I think that LFortran is a really exciting project, from SciPy's perspective as well as my own. I caught Naman's talk about LPython at EuroSciPy this year. If you are looking for SciPy interest in LFortran, a clear example from this issue would be compiling PRIMA, then being able to convert PRIMA from Fortran to C or C++ or whatever. In effect, that would give us a panic-button / get-out-of-jail-free-card in the scenario that PRIMA became unmaintained (which multiple maintainers are wary of above). Personally, I would have no reservations about adding these new algorithms from PRIMA if we had that backup option. Of course, the same goes for LAPACK, if the results are good. And great to hear that LFortran still has funding! |
Yes, PRIMA (and LAPACK) is next on our 3rd party code compilation TODO list: lfortran/lfortran#3806. And yes, that is the idea behind the C++ backend to not being locked into Fortran, but could always migrate to a readable C++. |
Perhaps @agriyakhetarpal can comment on the Wasm side of things? He's been working on using Pyodide to provide interactive docs for SciPy. |
|
Here is a blog post how to use LFortran with WASM: https://lfortran.org/blog/2024/05/fortran-on-web-using-lfortran/. |
|
A agree with previous commenters that ultimately, the question whether Fortran code is acceptable in SciPy has to be decided by the maintainers who understand the costs of that decision. But I would like to weigh-in from the optimizer side: In my opinion, having access to BOBYQA, NEWUOA and LINCOA would be very valuable for users. While I have no personal experience with LINCOA, I have used BOBYQA and NEWUOA a lot. They are some of my go-to optimizers for derivative free problems and were one of the reasons I often had to switch between scipy and NlOpt (which ultimately lead to the creation of optimagic). Since benchmarks suggest that the PRIMA versions work even better, I would love to see them in SciPy.
As I said, I would very much prefer if those algorithms were in SciPy and I know that the maintainers of PRIMA would also prefer that. But if you ultimately decide against it, optimagic could be a good place to maintain the Python interface to the algorithms. However, the optimagic team has no experience in vendoring Fortran code, so we would need help in the beginning. |
|
First and foremost, thank you @nbelakovski for the work you put into wrapping PRIMA and for the offer to maintain the wrapper and the library itself going forward! This is greatly appreciated, regardless of how this discussion concludes. I'd suggest we separate the discussion: the general Fortran discussion might be better suited for the Discourse thread; for the algorithmic part though, let's forget the implementation language and first understand what is the reason they should be in scipy? |
Thanks for the ping, @lucascolley! Yes, SciPy v1.14.1 in Pyodide currently applies eighteen patches at the time of writing, and a lot more conversions in the It is to be noted that our friends over at emscripten-forge have now packaged So, with Fortran modules being rewritten in C/C++/Cython in #18566 and LFortran already able to compile 60% of SciPy's Fortran modules as mentioned in #21554 (comment), it would be great if approaches to compiling the rest of the modules could be attempted again at some point down the road. I can't comment on what language is best for SciPy's implementations of its algorithms, not being experienced with Fortran beyond an introductory book's chapters myself – but, perhaps it could be worthwhile to see whether making something compile with LFortran is easier or rewriting it in another language is the best way forward, as a means to mix and match expectations and pursue collaborations? Not only would that address the lack of a Fortran to WASM compiler, but it would also improve the state of SciPy in WASM in general (even though this is slightly old, please see https://hackmd.io/9cbsykxyT9mstqfW0EV5ug?viewk for historical context) because even Either way, rewriting in Cython fixes things automatically, sometimes: #20558 and pyodide/pyodide#4920. If we're able to bring the patches down to, say, two or three at most, out-of-tree builds for SciPy would be more plausible. I would ping @lesteve who might have a few more comments – please feel free to add what I missed. :) |
|
@agriyakhetarpal excellent comments! Yes, that was precisely my goal to collaborate on WASM and get the tooling working well. It's a net benefit to everybody in the long run. And yes, we have common friends at emscripten-forge, and they have helped greatly with LFortran and we appreciate their support! :) |
|
I need some input from SciPy folks then; Scenario 1; I can translate PRIMA (would be nice if others join too), it's a couple of thousand lines. It is doable as SLSQP, MINPACK, QUADPACK were also like that. And we translate the rest of it and we follow the fortran-free way. Scenario 2; we take in PRIMA entirely, so fortran stays. Then we don't translate the rest. There is no middle ground I'm afraid. It is no secret that I'm on scenario 1 team. But I need that consensus now because otherwise I don't see the need for translation if it is not going to lead to anything. Definitely a net win for me though a big opportunity that we miss. However in the end, the code survived decades so probably the world will be the same next morning. |
Scenario 3a: we continue to convert the unmaintained F77 codebase and vendor PRIMA just for COBYLA. Perhaps at some point in the future PRIMA becomes unmaintained and that part of PRIMA will need to be translated, or perhaps there is a reason to translate it before that. Scenario 3b: the same but we use all of the algorithms from PRIMA. Would these not count as middle-ground? Why would continuing to have some externally-maintained Fortran in the codebase make other translations futile? I think the enhancements that your translations have enabled in Perhaps consider expanding on this dichotomy on the Discourse thread if you still believe it to be the case. |
|
Lucas let the discussion roll please. We don't need extra moderation if you don't mind. There is no added value pointing to places to write things around. I know I can do that and I already wrote it there already. |
|
Only a quick comment as I do not have access to a computer. I fear we are in danger of throwing the baby out with the bath water here. Of course the work on F77 translations has been amazing but it should not block the use of PRIMA imo. It is not clear to me that we would do a better job of maintaining a translation of this code than the PRIMA maintainers. |
|
This is much more lively and far ranging discussion than I anticipated when I created this issue! All good things for the most part, although @certik and @agriyakhetarpal I'd appreciate if you didn't hijack my issue to talk about LFortran ;) <3 I think @janosg brought up a good point which is that if we step away from the implementation discussion for a bit it's helpful to ask what is the value of adding these things to SciPy? If these things were implemented in impeccable Python, would SciPy want them? It sounds like the consensus is yes, and I think that's really helpful to guide the discussion. Maintenance and translations can always be prioritized/deprioritized as appropriate, and since these solvers have been demonstrated to work across a range of problems from CUTEst I think their maintenance needs ought to be reasonably low. As I've stated elsewhere in this thread I've offered to help with maintaining this code, and by the way I'm not exactly a stranger around here. This is community effort so obviously there are factors besides one person volunteering some of their time, but it would be helpful to know what those are. I haven't taken a look at the discourse thread, I will do so after I post this, but mainly I'm wondering what exactly the main issues are in terms of Fortran maintenance and what are the specific concerns that adding these solvers raises? I believe that the effort to integrate these solvers will be low and they bring unique capabilities to SciPy, and it would be a shame not to include them if the only reason for doing so was that they are implemented in a language that is no longer in fashion, even if their implementation is actually better than some C++ and even some Python codebases I've worked with. |
|
For the record we have been maintaining quite a bit of libraries ourselves. In this case maintaining means look at what changed and apply the same. This is not something that requires specific knowledge. Fortranness of the code is not special and I don't see the point of the must that it has to be in fortran. The translations are done to get to a fortran free state as a hail mary attempt. It's not a hobby. So I can't commit to translations if we are not getting there. If someone else wants to pickup then more than welcome. |
|
I don't think that using PRIMA for the time-being blocks a Fortran-free future. It just may be useful to keep PRIMA upstream until we can translate LAPACK. We can still work towards a Fortran-free state without translating PRIMA immediately. Adding the other algorithms (= depending on more of the PRIMA API surface) would work against the goal by adding more that would ultimately have to be translated, and that might mean that we don't want to add them, but it still wouldn't block a Fortran-free future. I suppose my point is that it seems too early to decide that we are "all-or-nothing" with Fortran when it is still going to be around for the foreseeable future. |
|
@ilayn : I am starting to feel tensions about this topic. Let me try to deascalate: I think we are all on the same page that unmaintable go to infected F77 code has to go. Let me repeat that the python community should be very thankful for your high personal efforts in that regard. The question if modern high quality maintained Fortran code can be included in SciPy is another one. I am +1 here and apparently not the only one. If there had been a concensus that we do not want modern Fortran, then why did we start this PRIMA endavour in the first place? If it gets rewritten in C or Python in a few months, then we could have started right away from the translation of the PRIMA implementation without using the Fortran version as a first step. If this concensus was reached, I might have missed it admittedly. Still, if this clear concensus was reached, not communicating this directly seems at least a little impolite to @nbelakovski who clearly invested a lot of time into the new wrapper and the resulting necessary changes to PRIMA. |
Because there is. A lot actually on my side.
Python community will be thankful to all of us if we stop forcing them to install a fortran toolchain, even though they have nothing to do with fortran and make them jump through 65 different hoops. We forced windows users to install scipy from C. Gohlke's wheels instead of
I am full -1 on that one and to be honest I don't mind being the only one. I did not wake up one day and said to myself "Hmm, let me waste two years on this F77 code". I did it because there is a goalpost and that is fortran-free SciPy. If that is not going to happen then I don't need to bother with the rest. Someone else can pick it up.
It is also quite a bit impolite to me filling up more fortran because there is some code that comes ostensibly free (it is not free). But that seems to be a bit ignored and this is starting to get on my nerves. This code was in for decades. And these solvers will be there so. I am offering to translate them on top of the Fortran. So they can have multiple versions which is much much better than having bindings that forces you to still have fortran. And we can still use the same bindings that are now put in place. But no, we must get it as fortran because it is the developers' baby. So should I start running around explaining how proud I am with the translations or tell everyone on the Hacker News. I have been translating PRIMA-long codebases every month. Is this now our yardstick? In fact I might be the only one in this thread who knows what it takes to do such work and how soul-draining it can be. Because I have been doing the exact same thing. We have issues, the tools are not even beta, and we better treat it so. If I bring any other tool, say nanobind, or whatever, we have two months of discussion, "well it is not proven", "should we get it in", "new dependency is problematic" etc. When it comes to this, suddenly, not even a door lock, please walk right in. While we are not taking SUNDIALS, or anything from julia which is becoming de-facto gold standard for diff.eq., this discussion makes no sense to me to get more fortran in. There are much more comprehensive tools out there that we said no to. I don't know why this became so special. It's not my problem that the authors chose this language or this language is not being preferred as much as others. If you need to reach out to me, please do it in private. I really don't want to discuss this matter publicly anymore, as if I own Fortran community anything. It is getting a bit tiring to hear how good fortran is. It is not and does not look like it will become so. |
Fortran has been facing this kind of (what I consider irrational) response for decades. I guarantee you it is a lot better than you make it look. It might very well not be the best fit for SciPy, only you can decide that. The Fortran community has been supporting you with any questions you had about these old codes and features, despite knowing your main motivation is to just get rid of it. And indeed you don't owe us anything, as you said. That being said, if you want to help us, you know how. :) |
|
I'm not telling fortran users what to do. But it is not C, it can't go into everywhere where C goes. That is the irrational part. If one wishes to use Fortran then they can use it whichever they want. The irrational part is claiming that it is suitable for every toolchain which is not. I did not put fortran in that position. If you consider decades of criticism as irrational that's fine with me but they might have a point. If you can save it from that place, I can only be happy for you and the users. And you deserve that but pretending as if it is C and should be available everywhere so we should squeeze it in every package is the irrational part. We dodged the bullet three times in the course of SciPy, until v1 cgohlke wheels, with v1 wheels Pauli and xoviat and then Axel's blogpost explaining Ralf's heroic effort switching to meson. Always someone somehow saving the day and miraculously it is always about this amazing tool that is fortran. I don't know how many crises it would take to finally say maybe this is not the right tool for us. |
|
Yes, Fortran must get to the point that it just works on every platform, including Windows, and cmake, meson, etc. It's "just" a tooling issue, but you need a solid compiler toolchain that fixes all this and works well with other languages and platforms. I offered you this support from our side for 60% of packages in SciPy. You said "no thanks, we don't want it", and went ahead and removed many of these packages that just worked with LFortran (fully working, all SciPy tests passing). I claim that the tooling issues that SciPy has with Fortran can be fixed (and possibly are already fixed in many ways on the Fortran side), and if you want to collaborate with us on that, for example on a Fortran package that is still in SciPy and that fully works with LFortran, then we are ready on our side. If you do not want to collaborate on that, you don't need to. It's just an offer from our side. |
|
For the last time, nobody ordered a compiler from you and nobody cancelled that order midway. I said, I don't want Fortran code (not "we" as you can clearly see in this thread, I said). I started translating, and now I am stopping. This is not about you or lfortran or flang. This is a fundamental open-source maintenance issue. You are putting an alpha version software in a project that is so fragile that we eat each other alive to deprecate one keyword. And you think Lfortran with its alpha stage is the tool for us as if we don't have enough problems. We also invited you and the whole forum many times, "come take a look at the fortran issues" we have. And collectively you said nothing. So if you are really caring about its reputation of this language, make it less painful and people gravitate towards you. If you don't have the capacity, someone else should. But for decades these code lied dormant not one person touched any of these code except Jacob Williams and now I am to blame to say this needs to go. There needs to be a reality check at some point. I can't keep talking about this. My apologies but I already wasted enough weekends on this nonsense. I'll leave to other folks, I have better things to do than beating a dead horse. |
I am not.
I don't think that.
Just look at the number of contributors here: https://github.com/fortran-lang/minpack, I see at least 6.
I apologize to you if I caused any troubles with my offers. I also apologize to @nbelakovski for "hijacking" his thread, although I was invited here. Most of us are doing this in our free time, let's be excited about our work! And yes, if you want production compilers, do not use alpha compilers. :) Thank you all for maintaining SciPy, and good luck either way you decide and go forward. And if anyone wants to collaborate, the door is open. |
|
@ilayn my suggestion to expose these remaining solvers in PRIMA was not meant as a personal attack against you. It was also not meant as some sort of snide way to laugh or otherwise poke fun at the Fortran-free goal. It feels like you’ve decided for the entire SciPy community that no new Fortran will be allowed. It doesn’t look like the community supports that decision. I understand that Fortran is difficult to maintain, but it feels like this goal to go Fortran free is one of those things that made sense at the time but now looks misguided. My takeaway from your previous comments is that one of the main difficulties is the tooling, can we work on making the tooling situation better instead of aiming to go Fortran free? I’m sorry that you set this goal of going Fortran free and this new library is perhaps the straw that broke the camel’s back in terms of being able to achieve that goal. But, hey, these things happen. I think it’s better to try to focus on how we can support the mission of SciPy and align efforts with that goal. If that means translating all the Fortran code and removing the Fortran toolchain, great. If that means finding more sustainable ways to integrate the Fortran toolchain so that volunteers don’t burn out, also great. Please accept my apologies for posting this publicly after you said you don’t want to talk about it. It seems like this conversation is centering around whether or not to include new Fortran code and it felt like that should be a more open discussion. Again, apologies. |
|
I posted this morning at https://discuss.scientific-python.org/t/is-adding-new-fortran-to-scipy-generally-allowed/1438/3. My overall preference would also be to not add new Fortran based code to the project. |
It's fine, no offense taken.
Respectfully, we discussed these things many many times. Everytime, we don't need a new version of it with more non-SciPy maintainers joining in especially more Fortran folks. You don't need to apologize this is not about your actions. With no offense, I really don't need more advice, I am fully aware of what I was doing. I'm not angry, this is open-source, I am just annoyed to waste a good chunk of time. However, I am done discussing this matter with non-maintainers in public as there is nothing left to be said that we already didn't. And maintainers know how to reach out to me if need be. So I let the others decide. |
|
Perhaps also we have jumped the gun a little bit here, I think first we should determine which solvers of these solvers we would like to add via benchmarking against our existing offerings because that determines the size of any potential translation. |
|
I will leave the discussion for Discourse. For the record: I am fine with whatever outcome we find, but for heaven's sake, let's cool down here. We are discussing a choice of technology, not presidential elections. |
Is your feature request related to a problem? Please describe.
With the pending closure of #20964, PRIMA will be integrated with SciPy, and while the primary goal of that PR and the issue it closes is to update COBYLA, PRIMA contains 4 other algorithms for derivative free optimization. They are:
More information can be found at @zaikunzhang's website: https://www.zhangzk.net/software.html
Since PRIMA will already be integrated in SciPy with the above PR, exposing these should be rather simple. I could do these myself, and I would propose to add them one by one to smooth out the review process, but these could also be a nice set of "good first issue" for folks interested in contributing to SciPy. I wonder if the maintainers have someone in mind who wants to contribute and can add these, or perhaps we can mark this issue as a good first issue and leave it up for a month or so to see if we have any bites?
Like I said I'd be happy to get this done myself and I'd even be willing to take responsibility for maintaining it in the future, but I thought it might be prudent to pause and ask if there are others who would like to take this opportunity to contribute.
Describe the solution you'd like.
No response
Describe alternatives you've considered.
No response
Additional context (e.g. screenshots, GIFs)
No response
The text was updated successfully, but these errors were encountered: