Fork me on GitHub
#bristol-clojurians
<
2020-10-14
>
Adrian Smith22:10:31

I need to look into using core logic again I think it'll simplify the constraint solver in that puzzle from the Dutch meetup

Richard08:10:39

It was interesting to see Carlo's approach to the problem. The shape of the input https://en.wikipedia.org/wiki/Futoshiki was a problem. Starting with the correct structure would have saved time. His tests were interesting too. He was trying to write a test to the whole problem first. The usual approach I'm used to is writing tests to smaller units, building up to the bigger picture. (I'm not saying one's right and the other approach is wrong. It's just different.) As you say, core logic is the common approach to these Sudoku like problems. Maybe we should visit core.logic on the next meetup. Also, rules engines too.

Richard09:10:04

Another thought on this was Carlo was only logging where "<" ">" "^" "V" appeared on the grid and ignored the spaces, but they have an implicit constraint of not equals. It would create a larger datastructure but a more consistent one to include them.

j18:10:39

Those are excellent points! I also wondered about the size of the tests. I would've like to approached it with smaller tests first as well. I've been thinking about why it took such a long time to load the data into a data structure appropriate for the problem, but I then realized that I didn't actually know the appropriate data structure because I hadn't given thought to the solving algorithm. Perhaps spending a brief 5-10 minutes in the beginning talking about the algorithm first would've been helpful?

j16:10:25

looks like logic programming? I've done a bit or prolog a million years ago, but I'd be interested in seeing how it works in Clojure!