Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 20 20:57

    odow on gh-pages

    build based on 5f8846c (compare)

  • Jan 20 20:49
    blegat review_requested #1716
  • Jan 20 20:49

    blegat on qp_dual

    (compare)

  • Jan 20 20:49

    blegat on master

    Improve quadratic duality in do… (compare)

  • Jan 20 20:49
    blegat closed #1717
  • Jan 20 00:08

    odow on gh-pages

    build based on fcc63d9 (compare)

  • Jan 20 00:00

    blegat on master

    Fix operate vcat with numbers (… (compare)

  • Jan 20 00:00

    blegat on vcat_number

    (compare)

  • Jan 20 00:00
    blegat closed #1718
  • Jan 19 18:10

    odow on gh-pages

    build based on 9c8f7dc (compare)

  • Jan 19 18:07
    blegat commented #1720
  • Jan 19 18:07
    blegat commented #1720
  • Jan 19 18:05

    odow on gh-pages

    build based on 7d95d83 (compare)

  • Jan 19 18:04
    blegat synchronize #1717
  • Jan 19 18:04

    blegat on qp_dual

    Address comments (compare)

  • Jan 19 17:58
    blegat synchronize #1716
  • Jan 19 17:58

    blegat on free_var

    Expand docstring for free varia… (compare)

  • Jan 19 12:55
    matbesancon opened #1720
  • Jan 18 23:10
    blegat commented #1350
  • Jan 18 21:17
    trulsf commented #1350
Benjamin Chung
@BenChung
sorry for the silly questions, tangentially
not yet, want to pass the relevant parts of the test suite first
There are a surprisingly large number of ways that sovlers ask for quadratic terms
Benjamin Chung
@BenChung
I also don't handle primal infeasibility certificates right, either...
huh, interesting
Benjamin Chung
@BenChung
Yeah, this is me mapping between the solver's theory, numerical precision, and MOI's expectations; I had it about half working earlier lol
I can do dual infeasibility fine!
Benjamin Chung
@BenChung
alright, passing the relevant tests and fixed primal infeasibility certificates, it's available at https://github.com/BenChung/PIPG.jl. Completely undocumented as of yet, though.
Mathieu Besançon
@matbesancon
did anyone observe breaking changes in Ipopt with the latest release JLL?
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)
Jose Daniel Lara
@jd-lara
Yeah, I had that issue in the CI happen yesterday
Mathieu Besançon
@matbesancon
with SCIP or Ipopt alone?
pinging @odow in case
Jose Daniel Lara
@jd-lara
SCIP and Ipopt in the same project. SCIP is downgrading the ipopt binaries and making a bit of a mess
So I disabled the test that uses SCIP
Mathieu Besançon
@matbesancon
not sure what you mean? Currently SCIP_jll does not enforce an Ipopt version
I thought this was specific to the upgrade to SCIP 8 I'm currently trying. Could you share the setting in which this occurred?
Mathieu Besançon
@matbesancon
mmmh it does look like a separate issue, SCIP itself seems to have precompiled fine, but Ipopt_jll has some precompilation issue
Jose Daniel Lara
@jd-lara
and all the tests that use Ipopt passed fine also
Mathieu Besançon
@matbesancon
mmmh that's strange
Oscar Dowson
@odow
What is ] st -m? I'm not aware of breaking changes in ipopt_jll
6 replies
Jose Daniel Lara
@jd-lara
@odow it is just happening on CI, I can’t reproduce locally on my mac
Oscar Dowson
@odow
I'll take a look once I'm at my computer
François Pacaud
@frapac
does someone would like to present something at tomorrow's NLP meeting? Otherwise, I would suggest to cancel this meeting
Oscar Dowson
@odow
I'm travelling tomorrow, so would prefer to cancel. I have nothing that requires a separate call from the usual monthly one.
François Pacaud
@frapac
The event has been cancelled.
BridgingBot
@GitterIRCbot
[slack] <pure_interpeter> i can't seem to enter the call.
[slack] <pure_interpeter> The non-linear call
BridgingBot
@GitterIRCbot
[slack] <François Pacaud> the call has been cancelled.
Carleton Coffrin
@ccoffrin
Made me wonder if we could have a "The future of mathematical programming and why it looks a lot like JuMP" discussion :-)
BridgingBot
@GitterIRCbot
[slack] <matbesancon> depends if you're talking about the future of math programming in Julia or not, and more broader it's not obvious that JuMP is/should be the (only) future of mathematical optimization in Julia, as concluded in the nonlinear calls
BridgingBot
@GitterIRCbot
[slack] <chec> can I read more about that somewhere @matbesancon? or what's the basic idea
Carleton Coffrin
@ccoffrin
@matbesancon, fair point, I will confess that I was being a little facetious with remark but to be more precise about I had in mind, if one is looking for a math programming DSL (e.g., AMPL, GAMS, AIMMS, ...), you will be hard pressed to find one that is better than JuMP
This is basically why I moved to Julia / JuMP in 2016, there was no other viable option.
I very much agree there is no one size fits all solution to mathematical optimization in general (or maybe even mathematical programming) but in either case, mathematical programming is much more specific topic in my mind than mathematical optimization
Oscar Dowson
@odow
One argument for JuMP is things like this: cvxpy/cvxpy#1605. Instead of a new standard form, things just work.
BridgingBot
@GitterIRCbot

[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.

  1. Diffractor won't be helpful in standard ML,
  2. 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,
  3. 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
  4. 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.

[slack] <chrisrackauckas> (of course, the public internet one is a much softer way of saying that 😅 )
[slack] <chrisrackauckas> But JuMP is looking at what, COIN-OR? Pyomo? A few people at a few university labs keeping the project going is fine. JuMP is already in a good place, and people aren't expecting you to match a paid industry team of 40 people in terms of monthly output.
[slack] <chrisrackauckas> So yeah, actually some blog posts focusing on JuMP would be great. People need to understand that Julia's strength isn't ML, but that's okay. There's great stuff like JuMP. Not everyone does ML.
Mathieu Besançon
@matbesancon
@ccoffrin completely agreed, within the modelling languages realms, JuMP is one of the most robust and flexible options today
Benoît Legat
@blegat

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/

BridgingBot
@GitterIRCbot
[slack] <blegat> @chrisrackauckas I guess the reason Julia Computing's product's are based on SciML and not ML is that SciML is mature and competitive in Julia and Julia Computing needs to have projects that can be profitable short-term so relying on SciML is a good fit. From that point of view, it seems indeed that people shouldn't wait for Julia Computing to make ML competitive.
Jose Daniel Lara
@jd-lara
It looks like by adding the call to another calendar of mine everyone has been invited too
I am sorry, all I did was switch my email associated with the invite
lesson learned, avoid automated tools to transfer calendars