4 ms·

Is this considered a nice Haskell style for this kind of programs? If so, I prefer how LP looks in Python. If someone is interested, my presentation slides: ht

by lrem 14y ago

Is this considered a nice Haskell style for this kind of programs? If so, I prefer how LP looks in Python. If someone is interested, my presentation slides: http://www-sop.inria.fr/members/Remigiusz.Modrzejewski/presentations/python_2012.pdf http://www-sop.inria.fr/members/Remigiusz.Modrzejewski/prese... Note this presentation was given to an audience that mostly knew ILP and has used it before for combinatorial optimization, so I'm not gentle with theory. It's just to show that Python is a little nicer than Java to do it.

tome 14y ago
Your Python DSL looks very nice. There's no reason a Haskell one couldn't look equally nice.
- dons 14y ago
  Indeed, with type information you can do quite sophisticated embedded DSLs that heavily reuse the host language's infrastructure for variables, control and types. So no need for the LpVariable stuff, for example, and you get type safety. An example of an SMT solver DSL, which: * reuses Haskell's type checker to check the types of the embedded language, * uses Haskell's polymorphism to add polymorphism to the underlying language * and the host language's variables as target language variables. http://code.haskell.org/~dons/docs/yices-painless/Yices-Painless-Language.html http://code.haskell.org/~dons/docs/yices-painless/Yices-Pain...
yummyfajitas 14y ago
It's throwaway code written for a blog post, and could certainly be cleaned up. However, Python code to solve the same problem would probably look very similar to the Haskell code. The initial example given in that presentation has only 4 variables and 4 constraints (slide 5), I have 15 and 27. Once you get to bigger problems, python code winds up looking similarly ugly. See lines 14-15 in that presentation. As the problems get bigger, your code isn't representing the LP problem. It's translating a small problem specification into a much bigger LP problem.
ozataman 14y ago
IMHO, his Haskell style is a little weird and not really the typical (or the best). The dailyCost function is a particularly ghastly example of bad layout and visual code organization. Then there are things like map (\(x,y) -> x) reservationFixedCosts instead of map fst reservationFixedCosts I'm also not a big fan of extensive use of list comprehensions; I'd prefer using "map" instead wherever I can. The whole thing could definitely look much cleaner.

by lrem 14y ago

tome 14y ago

Your Python DSL looks very nice. There's no reason a Haskell one couldn't look equally nice.

dons 14y ago
Indeed, with type information you can do quite sophisticated embedded DSLs that heavily reuse the host language's infrastructure for variables, control and types. So no need for the LpVariable stuff, for example, and you get type safety. An example of an SMT solver DSL, which: * reuses Haskell's type checker to check the types of the embedded language, * uses Haskell's polymorphism to add polymorphism to the underlying language * and the host language's variables as target language variables. http://code.haskell.org/~dons/docs/yices-painless/Yices-Painless-Language.html http://code.haskell.org/~dons/docs/yices-painless/Yices-Pain...

yummyfajitas 14y ago

It's throwaway code written for a blog post, and could certainly be cleaned up. However, Python code to solve the same problem would probably look very similar to the Haskell code. The initial example given in that presentation has only 4 variables and 4 constraints (slide 5), I have 15 and 27. Once you get to bigger problems, python code winds up looking similarly ugly. See lines 14-15 in that presentation. As the problems get bigger, your code isn't representing the LP problem. It's translating a small problem specification into a much bigger LP problem.

ozataman 14y ago

IMHO, his Haskell style is a little weird and not really the typical (or the best). The dailyCost function is a particularly ghastly example of bad layout and visual code organization. Then there are things like map (\(x,y) -> x) reservationFixedCosts instead of map fst reservationFixedCosts I'm also not a big fan of extensive use of list comprehensions; I'd prefer using "map" instead wherever I can. The whole thing could definitely look much cleaner.