3 ms·

> is there a reason to learn Julia? JuMP is why I learned whatever I did of Julia and that was mostly because it allowed me to express some things better (not

by gopalv 8y ago

> is there a reason to learn Julia? JuMP is why I learned whatever I did of Julia and that was mostly because it allowed me to express some things better (not necessarily faster or in parallel). A good example would be this random problem that came out of an interview discussion. https://gist.github.com/t3rmin4t0r/44d8e09e17495d1c24908fc0fae01e48 https://gist.github.com/t3rmin4t0r/44d8e09e17495d1c24908fc0f... I'm almost sure my python implementation is wrong, but I can't quite prove it - the Julia one is trivial to understand (a dot product + a minimization function).

kevmo314 8y ago
Using an optimization library seems like the completely wrong approach to solving this interview question. Was that intentional?
- pietjepuk88 8y ago
  Aside from the special case of "1" always being present, I would say that in general you should just use an optimizer to solve knapsack problems. Whether you should do so for an interview question is up for debate I guess; using libraries shows you can get something done quickly and efficiently, but implementing your own solver might show you understand the underlying complexity. As far as comparing code complexity of Julia to Python is concerned, I would say that when you use JuMP in Julia, you should use Pyomo/CasADi/PuLP/... in Python. That is not to say that I don't find JuMP to be a more appealing framework overall. It has wide support for all kinds of solvers, and some Julia/JuMP authors even wrote fairly good MIQCP/MICP solvers on top of commercial/open-source MILP/SOCP solvers.
  - kevmo314 8y ago
    > I would say that in general you should just use an optimizer to solve knapsack problems. Why do you say that? Perhaps if the knapsack problem is provably non-polynomial, but being able to distinguish those cases is a rather important skill. For example, the problem you specified can more easily be solved directly: https://repl.it/repls/RotatingObeseBusinesses https://repl.it/repls/RotatingObeseBusinesses With respect to the interview question context, if I had a candidate that implemented a solver, I would be inclined to say they completely overengineered the solution for a less optimal answer. There are a bunch of assumptions that are required for a solver to be optimal and unless the candidate can enumerate all of them and argue why the problem meets those constraints, the solver is not 100% guaranteed to be correct, whereas a direct solution is. Not to mention, as you noted, edge cases, and the complete cryptic-ness of the code.

by gopalv 8y ago

kevmo314 8y ago

Using an optimization library seems like the completely wrong approach to solving this interview question. Was that intentional?

pietjepuk88 8y ago
Aside from the special case of "1" always being present, I would say that in general you should just use an optimizer to solve knapsack problems. Whether you should do so for an interview question is up for debate I guess; using libraries shows you can get something done quickly and efficiently, but implementing your own solver might show you understand the underlying complexity. As far as comparing code complexity of Julia to Python is concerned, I would say that when you use JuMP in Julia, you should use Pyomo/CasADi/PuLP/... in Python. That is not to say that I don't find JuMP to be a more appealing framework overall. It has wide support for all kinds of solvers, and some Julia/JuMP authors even wrote fairly good MIQCP/MICP solvers on top of commercial/open-source MILP/SOCP solvers.
- kevmo314 8y ago
  > I would say that in general you should just use an optimizer to solve knapsack problems. Why do you say that? Perhaps if the knapsack problem is provably non-polynomial, but being able to distinguish those cases is a rather important skill. For example, the problem you specified can more easily be solved directly: https://repl.it/repls/RotatingObeseBusinesses https://repl.it/repls/RotatingObeseBusinesses With respect to the interview question context, if I had a candidate that implemented a solver, I would be inclined to say they completely overengineered the solution for a less optimal answer. There are a bunch of assumptions that are required for a solver to be optimal and unless the candidate can enumerate all of them and argue why the problem meets those constraints, the solver is not 100% guaranteed to be correct, whereas a direct solution is. Not to mention, as you noted, edge cases, and the complete cryptic-ness of the code.