
Using Monads in C++ to Solve Constraints: 1. The List Monad - andrzejsz
http://bartoszmilewski.com/2015/05/11/using-monads-in-c-to-solve-constraints-1-the-list-monad/
======
TheLoneWolfling
This method is _really_ inefficient. There are b! / (b - n)! ways to choose n
of b unique numbers, whereas this solution is O(b^n).

That being said, it's still fast enough for this example.

Also, Python solution along the same lines:

    
    
        import itertoolsdef
        def valueOf(*values, base=10):
            v = 0
            for v in itertools.accumulate(values, lambda a,b: a*base+b):
                pass
            return v
        def solve():
            for s,e,n,d,m,o,r,y in itertools.permutations(range(10), r=8):
                if valueOf(s,e,n,d) + valueOf(m,o,r,e) == valueOf(m,o,n,e,y):
                    yield (s,e,n,d),(m,o,r,e),(m,o,n,e,y)
    

(If anyone knows of a better way to do valueOf, let me know)

~~~
jordigh
> This method is really inefficient.

That's what I've noticed with Haskellers. They have a tendency to write really
slow code and don't have a clear idea of the execution model behind what they
write down.

A while ago I asked in #haskell for translations into Haskell of the following
C++ code:

[http://codepad.org/sQTXhqC2](http://codepad.org/sQTXhqC2)

This should be easy. The algorithm is right in front of you. There should not
be a lot of thinking in transcribing an algorithm into Haskell. But most of
them wrote down something with a fold which turned what is an O(m*n) algorithm
in time and O(n) in space into something like O(m^n) in space and time. The
only one who got close to the C++ implementation was one who used a lot of
State monads.

Then, of course, there was someone who pointed me out to a radically different
algorithm written in Haskell that I think is only O(n+m) in both space and
time. I haven't been able to understand this other algorithm yet.

~~~
wyager
The responses you got on IRC don't necessarily represent Haskell best practice
(or even good practice). Most people probably have better things to do than
translate random toy programs from C++.

Certain highly stateful algorithms may be difficult to translate into Haskell,
in the same way that certain highly structural or lazy algorithms may be
difficult to translate to C++.

I'm curious if your time complexity analyses are accurate, given that you
(admittedly) did not understand the faster algorithm. You could be getting
tripped up by laziness.

In general, I've found that most production Haskell code is quite fast, in
both big-O and absolute terms.

~~~
tezka
Spoken like a true Haskell fanboy. Why don't you give it a shot, OP has posted
the code.

~~~
alricb
Shriram Krishnamurti to the rescue! Here's a memoized version in scheme:
[http://blog.racket-lang.org/2012/08/dynamic-programming-
vers...](http://blog.racket-lang.org/2012/08/dynamic-programming-versus-
memoization.html)

------
taeric
Do you get bonus points for knowing that these are Alphametics? And covered in
ridiculous detail in volume 4A of The Art of Computer Programming? I'm curious
how the solutions there stack up to what is in mind here.

------
zeroonetwothree
I would just use std::next_permutation (or equivalent partial permutation from
a library). This produces pretty clean code.

------
awruef
"Once you internalize the many-worlds approach to programming, the
implementation is pretty straightforward." are you serious? this is why people
don't take Haskell seriously.

------
tjradcliffe
It is disingenous in the extreme to ask, "So what’s all this talk about
mutation and state? Well, who said you can’t have state in functional
programming?" when the _very first line_ of the _very first hit_ on
"functional programming mutation state" is the Wikipedia article on functional
programming, which says:

"In computer science, functional programming is a programming paradigm—a style
of building the structure and elements of computer programs—that treats
computation as the evaluation of mathematical functions and avoids changing-
state and mutable data." \--
[https://en.wikipedia.org/wiki/Functional_programming](https://en.wikipedia.org/wiki/Functional_programming)

So the answer to the question "Who said you can't have state in functional
programming?" is: "Every introduction to functional programming ever."

This is why people hate Haskell and make fun of Haskellers. In their quest to
appear more clever than the rest of us, they engage in utterly disingenous
rhetoric. Which is too bad, because I'm pretty sure they are actually more
clever than the rest of us--certainly more clever than me--and don't need this
nonsense.

Haskell is an amazingly cool language, and I've talked to people at meetups
who are using it for interesting things, and learning a bit of it myself has
been an interesting and educational challenge. But getting around to learning
it took five years longer than it should have because I was so put off by the
rhetorical nonsense the language community engages in.

~~~
jjnoakes
"Having state" != "Changing-state and mutable data".

5 years?

