Developer-focused chat about JuMP, M̶a̶t̶h̶P̶r̶o̶g̶B̶a̶s̶e̶, MathOptInterface, solver interfaces, and JuMP extensions. Towards JuMP 1.0! Basic usage questions will be answered more quickly at https://discourse.julialang.org/c/domain/opt.
when calling from SCIP:
_ZNSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_N5Ipopt8SmartPtrINS8_16RegisteredOptionEEEESt10_Select1stISC_ESt4lessIS5_ESaISC_EE4findERS7_ at /home/mbesancon/.julia/artifacts/a22df77e0dbcc7c4fcc9344c6649c97b5a40670c/lib/libipopt.so (unknown line)
_ZN5Ipopt17RegisteredOptions23AddBoundedIntegerOptionERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_iiiS8_ at /home/mbesancon/.julia/artifacts/a22df77e0dbcc7c4fcc9344c6649c97b5a40670c/lib/libipopt.so (unknown line)
_ZN5Ipopt16IpoptApplication15RegisterOptionsENS_8SmartPtrINS_17RegisteredOptionsEEE at /home/mbesancon/.julia/artifacts/a22df77e0dbcc7c4fcc9344c6649c97b5a40670c/lib/libipopt.so (unknown line)
_ZN5Ipopt26RegisterOptions_InterfacesERKNS_8SmartPtrINS_17RegisteredOptionsEEE at /home/mbesancon/.julia/artifacts/a22df77e0dbcc7c4fcc9344c6649c97b5a40670c/lib/libipopt.so (unknown line)
_ZN5Ipopt16IpoptApplication23RegisterAllIpoptOptionsERKNS_8SmartPtrINS_17RegisteredOptionsEEE at /home/mbesancon/.julia/artifacts/a22df77e0dbcc7c4fcc9344c6649c97b5a40670c/lib/libipopt.so (unknown line)
SCIPincludeNlpSolverIpopt at /home/mbesancon/.julia/artifacts/b60abebfc767cdd3fea2f036235d336d95257b88/lib/libscip.so (unknown line)
SCIPincludeDefaultPlugins at /home/mbesancon/.julia/artifacts/b60abebfc767cdd3fea2f036235d336d95257b88/lib/libscip.so (unknown line)
6 replies
[slack] <chrisrackauckas> JuMP doesn't have similar issues though. A lot of the ML case is a "how do we continue to progress faster than the Google and Facebook funded behemoths?", with a big group of online folk thinking "oh yeah Julia Computing and the Julia Lab is investing in that. Just wait for Diffractor and it's all good". I had to write a few blog posts recently just to describe in full that, there's a lot of wrong in that thinking.
- Diffractor won't be helpful in standard ML,
- if anything, it's detrimental to standard ML to pick a larger world to optimize and how standard ML as a subset gets fully optimal accidentally,
- no one is directly funding it, Julia Computing is a product focused company where the products are not ML (Pumas, JuliaSim, and Cedar), and the Julia Lab grants are public https://julia.mit.edu/research-grants/ mostly relying on a non-full time academic to get the huge grants for the lab, and no none of those grants are ML focused instead SciML
- who you think is working on Diffractor, Keno, has been leading circuit design development for along time and it's completely unreasonable to think he'll take like 2 years off to get Diffractor completed (https://cedar-eda.com/). This isn't news of course, this has been out in the open, but I think a lot of ML people just don't read the modeling and simulation stuff. There are students who have picked up the project, but it's a hard one. Expect this to take years, and I need to recruit more for it too.
And so for everyone who thinks Diffractor is the lord and savior that will solve all Zygote issues, 😅 yeah Flux cannot rely on that. When it doesn't reach their expectations, it won't be by accident but by design. It wasn't ever made to solve Flux issues but instead to solve physics-informed neural network issues (hence the higher order). It will work well for SciML, with the hope of being at least as good as Zygote for non-SciML things, but in no way shape or form is this going to create a horde of Julia Lab PhD students to rivel PyTorch. That was never ever in the plan, and this plan doesn't even make sense for that conclusion.
One argument for JuMP is things like this: cvxpy/cvxpy#1605. Instead of a new standard form, things just work.
Good design pays off \o/