4 ms·

Not really production, but probably THE most impressive biomedicine research work I've seen (and I'm an academic MD): https://github.com/webyrd/mediKanren http

by rscho 4y ago

Not really production, but probably THE most impressive biomedicine research work I've seen (and I'm an academic MD): https://github.com/webyrd/mediKanren https://github.com/webyrd/mediKanren This is a FOL theorem prover that uses medical research articles as terms. They use it to do genetics and drug repurposing metaresearch. It's like the wet dream of all the biomed machine learning fanboys out there, except that: 1. it's not machine learning and 2. it really works

YeGoblynQueenne 4y ago
Note you can do machine learning of logic programs. My PhD research: https://github.com/stassa/louise https://github.com/stassa/louise In which case it _is_ machine learning and it still really works :D
- rscho 4y ago
  Yeah, I wanted to try your system on the same database as they're using for medikanren. I got stuck bc loading the whole thing into the prolog fact database was too huge. Perhaps I should retry by querying the SQL database from prolog.
  - YeGoblynQueenne 4y ago
    Yes, I've seen this before. I'd suggest partitioning the database into parts that fit comfortably in memory and processing each separately, then simply combininig the learned programs into one. You can do this with Prolog because you can keep adding clauses to a program, or removing them from it, for as long as you want, and the program won't (necessarily) break, it will just become more specialised, or generalised (respectively). John McCarthy called that "elaboration tolerance". To, er, elaborate a bit on this, a logic program is a set of clauses interpreted as a conjunction (even if they look like alternatives!) so that the program as a whole has a set of "facts" it entails, but without any other assumptions about the relation between the clauses with each other. If you add clauses, your program entails more facts. If you remove clauses, it entails fewer facts. With negation-as-failure, the relation is non-monotonic, but it's still the same idea. This is what makes it possible to learn Prolog programs from examples, in the first place. With Louise in particular, because it builds up programs clause-by-clause, you can even train it with a single example at a time. It used to be it was limited in its one-shot learning capabilities but it's much better now. In fact, if you're doing any preliminary work with Louise, you really want to start by training it on a handful of examples at a time, so you can best figure out the right configuration to use to learn the kind of program you want it to learn. Otherwise, if you throw the entire database at it, even if it fits into memory, you'll get so much in the output that it will just be overwhelming. ILP and Louise work a bit differently than ordinary machine learning. You want to go slowly, processing small data in small batches, otherwise you get a firehose of clauses in the face and drown. It's the tradeoff you get for being able to inspect the learned "model": there's still a lot of it and you have to develop strategies to deal with its complexity. Hope that makes sense? Please do get in touch if you need help with Louise. Or anything ILP!

by rscho 4y ago

YeGoblynQueenne 4y ago

Note you can do machine learning of logic programs. My PhD research: https://github.com/stassa/louise https://github.com/stassa/louise In which case it _is_ machine learning and it still really works :D

rscho 4y ago
Yeah, I wanted to try your system on the same database as they're using for medikanren. I got stuck bc loading the whole thing into the prolog fact database was too huge. Perhaps I should retry by querying the SQL database from prolog.
- YeGoblynQueenne 4y ago
  Yes, I've seen this before. I'd suggest partitioning the database into parts that fit comfortably in memory and processing each separately, then simply combininig the learned programs into one. You can do this with Prolog because you can keep adding clauses to a program, or removing them from it, for as long as you want, and the program won't (necessarily) break, it will just become more specialised, or generalised (respectively). John McCarthy called that "elaboration tolerance". To, er, elaborate a bit on this, a logic program is a set of clauses interpreted as a conjunction (even if they look like alternatives!) so that the program as a whole has a set of "facts" it entails, but without any other assumptions about the relation between the clauses with each other. If you add clauses, your program entails more facts. If you remove clauses, it entails fewer facts. With negation-as-failure, the relation is non-monotonic, but it's still the same idea. This is what makes it possible to learn Prolog programs from examples, in the first place. With Louise in particular, because it builds up programs clause-by-clause, you can even train it with a single example at a time. It used to be it was limited in its one-shot learning capabilities but it's much better now. In fact, if you're doing any preliminary work with Louise, you really want to start by training it on a handful of examples at a time, so you can best figure out the right configuration to use to learn the kind of program you want it to learn. Otherwise, if you throw the entire database at it, even if it fits into memory, you'll get so much in the output that it will just be overwhelming. ILP and Louise work a bit differently than ordinary machine learning. You want to go slowly, processing small data in small batches, otherwise you get a firehose of clauses in the face and drown. It's the tradeoff you get for being able to inspect the learned "model": there's still a lot of it and you have to develop strategies to deal with its complexity. Hope that makes sense? Please do get in touch if you need help with Louise. Or anything ILP!