usgroup

Well that would be extra information. Wherever you find the edge of your information, you will find the "problem of induction" as presented above.

yes, if you decide one of them is much more likely without reference to the data, then it will be much more likely :)

This issue happens at the edge of every induction. These two rules support their data equally well:

data: T T T T T T F

rule1: for all i: T

rule2: for i < 7: T else F

SWI Prolog is just fine, and you'll find it to be batteries included unlike many other choices. The first thing to learn is the "Prolog state of mind", or how to express your intentions in Prolog without trying to turn it into a functional or imperative programming language.

Prolog will show you another way of thinking. If it does not then you are doing it wrong.

Personally I don't like the Standard ML based mash-ups.

I think Curry is an interesting take on logic programming. A sort of Haskell meets Prolog.

I can recommend "Simply Logical". I also suggest Advent of Code as a nice way to cut your teeth with expressing thoughts with Prolog.

Generally speaking, Prolog syntax is ridiculously simple and uniform. Its pattern matching is the most universal of any programming language partly because of this.

Yeah that sounds like me too. Prolog became a fetish a few years ago. I used it intensely for 2 years, wrote a lot about it, until it became a part of me. Its intangible what it does to you, but its the dual of what you might expect.

No, datalog is a decidable subset of Prolog. That changes everything.

I think this article is problematic because Prolog is truly a different paradigm which requires time to understand. Laments about no strings, no functions and "x is confusing" read like expectations of a different paradigm.

Prolog is also unusual in a sense that it is essential to understand what the interpreter does with your code in order to be able to write it well. For vanilla Prolog, that's not so hard. However, when constraint programming and other extensions are added, that becomes much harder to do.

evil(x) -> not(do(x)) which equates to not(evil(x)) or not(do(x)).

The negation would be evil(x) and do(x) by DeMorgan's law.

If what you mean is all(x), evil(x) -> not(do(x))

then the negation would be exists(x), evil(x) and do(x).

Thanks for this reference; I found this paper interesting, but it is a satisfiability solver. Inherently it cannot quantify the probability of a subset of events, but it can find a probability assignment given a set of constraints. I.e. prove possibility. More usefully it can show that no such assignment is possible.

It's a typo. Its supposed to be a comma not a pipe, and read P(Q ⊆ X , ∀ x ∈ Q (x = 1)). I.e. Q is some subset of X and for all x in Q, x=1.

I think that's overly reductivist. In the general case DS operates on up to 2^M sets where M is the cardinality of the hypothesis space: worst case scenario. That's not true if hypotheses are hierarchical, or if evidence is frequently about the same set, or there just isn't enough evidence to fuse to get to 2^M.

In the worst case scenario there are efficient approximation methods which can be used.

Injective doesn’t mean bijective, and that seems obvious. That is, presumably very many inputs will map to the output “Yes”.

Doing Advent of Code 2025 in SETL this year.

I think more often people cast the widest net and then filter what comes back based on “is this better than what I have”.

I’m not sure that the process the author describes is all that common in practice even if it is eminently sensible.

:-) I would have hired you!