souffle
mathlib
Our great sponsors
souffle | mathlib | |
---|---|---|
11 | 36 | |
861 | 1,625 | |
2.6% | 0.4% | |
7.6 | 8.8 | |
24 days ago | 9 days ago | |
C++ | Lean | |
Universal Permissive License v1.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
souffle
-
A Logic Language for Distributed SQL Queries
> In fact, we could have used Datalog to achieve our data goals — but that would mean we have to build our own Datalog implementation, backing data store, etc. We don’t want to do that.
Surprising that creating a whole new language made more sense then a backend. I wonder if they did a proof of concept with an existing logic system like Souffle¹ or Rel² first.
¹ https://github.com/souffle-lang/souffle
² https://relational.ai/blog/rel
-
Using_Prolog_as_the_AST
Consider using Datalog (the incredible subset of Prolog) for this perfect use case. Compared to Prolog, you get:
1. Free de-duplication. No more debugging why a predicate is returning the same result more than once.
2. Commutativity. Order of predicates does not change the result. Finally, true logic programming!
3. Easy static analysis. There are many papers that describe how to do points-to analysis (and other similar techniques) with Datalog rules that fit on a single page :O
Souffle[0] is a mature Datalog that is highly performant and has many nice features. I highly recommend playing with it!
[0] https://souffle-lang.github.io
-
If given a list of properties/definitions and relationship between them, could a machine come up with (mostly senseless, but) true implications?
Still, there are many useful tools based on these ideas, used by programmers and mathematicians alike. What you describe sounds rather like Datalog (e.g. Soufflé Datalog), where you supply some rules and an initial fact, and the system repeatedly expands out the set of facts until nothing new can be derived. (This has to be finite, if you want to get anywhere.) In Prolog (e.g. SWI Prolog) you also supply a set of rules and facts, but instead of a fact as your starting point, you give a query containing some unknown variables, and the system tries to find an assignment of the variables that proves the query. And finally there is a rich array of theorem provers and proof assistants such as Agda, Coq, Lean, and Twelf, which can all be used to help check your reasoning or explore new ideas.
-
Introduction to Datalog
It's true that this SPARQL-inspired view of Datalog as a triplestore query language is quite a narrow interpretation compared to something closer to the academic Prolog roots like https://souffle-lang.github.io/ - what do you feel are the most important differences?
- Systematic, Ontological, Undiscovered Fact Finding Logic Engine
- Soufflé • a Datalog Synthesis Tool for Static Analysis
-
Show HN: Cozo – new Graph DB with Datalog, embedded like SQLite, written in Rust
Very cool! I love the sqlite install everywhere model.
Could you compare use case with Souffle? https://souffle-lang.github.io/
I'd suggest putting the link to the docs more prominently on the github page
Is the "traditional" datalog `path(x,z) :- edge(x,y), path(y,z).` syntax not pleasant to the modern eye? I've grown to rather like it. Or is there something that syntax can't do?
I've been building a Datalog shim layer in python to bridge across a couple different datalog systems https://github.com/philzook58/snakelog (including a datalog built on top of the python sqlite bindings), so I should look into including yours
-
Ask HN: What are some interesting examples of Prolog?
TerminusDB CTO here.
Echoing what triska said, CLP(ℤ) and friends are some of the most under-appreciated aspects of prolog implementations.
I'm amazed that programmers still don't have access to CLP when trying to do scheduling and planning solutions.
As an example in practice, what if you want to know about a transaction in which a number of entities transitively had holdings in one of the beneficiaries of the transaction at that particular time. The date window is not known, and the date windows are important in the ownership chain as well as the transactions that are being undertaken.
With CLP(FD) you can ask for a window of time, and the solution will zoom in on an appropriate time window which exists for the entire chain and match the time of the transaction.
Now try to do this query in SQL. It's almost impossibly hard.
I can't wait until I have the time to implement constraint variables for TerminusDB, but at the minute we are still working on more prosaic features.
Aside from that there are very interesting program correctness and optimisation systems which are based on prolog (usually a datalog). For instance Soufflé: https://souffle-lang.github.io
-
is it possible to have a reversable operation
No problem :) What do you mean by voice control systems? Prolog has a bit of a learning curve and it's very difficult to write efficient code in. Although it did inspire Erlang, which is used in telecom and has some pretty interesting advantages not offered by other languages (reliance, multithreading, and updating without shutting down) Prolog is also pretty procedural, (the order you declare clauses in really really matters). There are other languages that use a much more pure for of logic Datalog: https://en.wikipedia.org/wiki/Datalog https://souffle-lang.github.io/
mathlib
- An Easy-Sounding Problem Yields Numbers Too Big for Our Universe
-
Towards a new SymPy: part 2 – Polynomials
It's been on my mind lately as well. I was trying out `symbolics.jl` (a CAS written in Julia), and it turned out that it didn't support symbolic integration beyond simple linear functions or polynomials (at least back then, things have changed now it seems). Implementing a generic algorithm for finding integrals is hard, but I was expecting more from that CAS since this seems to be implemented in most other CASs. The thing is that every single CAS that covers general maths knowledge will have to implement the same algorithm, while it's hard to do it even once!
I feel like at least a large part of the functionality of a general purpose CAS can be written down once, and every CAS out there could benefit from it, similar to what the Language Server Protocol did for programming tools. They also had to rewrite the same tool for some language multiple times because there are lots of editors out there, and the LSP cut the time investment down a lot. They did have to invest a large amount of time to get LSP up and running, and it'll have to be maintained, but I think it's orders of magnitudes more efficient than having every tool developed and maintained for every single (programming language, editor) pair out there.
Main problem is like you said how to write down mathematical knowledge in a way that all CASs can understand it. I've been learning about Mathlib lately [0], which seems like a great starting point for this. It is as far as I know one of the first machine readable libraries of mathematical knowledge; it has a large community which has been pushing it continuously forward for years into research-level mathematics and covering the entire undergraduate maths curriculum and it's still accelerating. If some kind of protocol can be designed to read from libraries like this and turn it into CAS code, that would be a major step towards making the CAS ecosystem more sustainable I think.
It's not exactly what you were talking about, as in, this would allow multiple CASs to co-exist and benefit from each other, but I think that's better than having one massive CAS that has a monopoly. No software is perfect, but having a diverse set of choices that are open source would be more than enough to satisfy everyone.
(I have posted about this before on the Lean Zulip forum, it's open to everyone to read without an account [1])
[0] https://leanprover-community.github.io/
-
Lean 4.0.0, first official lean4 release
Kinda agree but Mathlib and its documentation makes for a big corpus to learn by example from. Not ideal but it helps.
https://github.com/leanprover-community/mathlib
-
It's not mathematics that you need to contribute to (2010)
https://github.com/leanprover-community/mathlib
https://1lab.dev/
You can watch the next generation, or participate, right now.
-
If given a list of properties/definitions and relationship between them, could a machine come up with (mostly senseless, but) true implications?
Still, there are many useful tools based on these ideas, used by programmers and mathematicians alike. What you describe sounds rather like Datalog (e.g. Soufflé Datalog), where you supply some rules and an initial fact, and the system repeatedly expands out the set of facts until nothing new can be derived. (This has to be finite, if you want to get anywhere.) In Prolog (e.g. SWI Prolog) you also supply a set of rules and facts, but instead of a fact as your starting point, you give a query containing some unknown variables, and the system tries to find an assignment of the variables that proves the query. And finally there is a rich array of theorem provers and proof assistants such as Agda, Coq, Lean, and Twelf, which can all be used to help check your reasoning or explore new ideas.
-
Will Computers Redefine the Roots of Math?
For the math that you mention, I would suggest looking at mathlib (https://github.com/leanprover-community/mathlib). I agree that the foundations of Coq are somewhat distanced from the foundations most mathematicians are trained in. Lean/mathlib might be a bit more familiar, not sure. That said, I don't see any obstacles to developing classical real analysis or linear algebra in Coq, once you've gotten used to writing proofs in it.
- Did studying proof based math topics e.g. analysis make you a better programmer?
-
Which proof assistant is the best to formalize real analysis/probability/statistics?
At this point I would go with Lean because of mathlib. Mathlib's goal is to formalize modern mathematics, so many of the theorems you would need for analysis should already be there for you.
-
[R] Large Language Models trained on code reason better, even on benchmarks that have nothing to do with code
I think about that every day. Lean's mathlib is a gigantic (with respect to this kind of project) code base and each function, each definition has a precise and rigorous natural language counterpart (in a maths book, somewhere).
-
Is there a paid service where someone can explain a paper to me like I am 15?
It's been around since 2013, although there are LLM that interact with Lean to do automated theorem proving. Anyway, you can learn more about Lean here. I enjoyed their natural numbers game (which reminds, me I should finish the last two levels)
What are some alternatives?
cozo - A transactional, relational-graph-vector database that uses Datalog for query. The hippocampus for AI!
coq - Coq is a formal proof management system. It provides a formal language to write mathematical definitions, executable algorithms and theorems together with an environment for semi-interactive development of machine-checked proofs.
differential-datalog - DDlog is a programming language for incremental computation. It is well suited for writing programs that continuously update their output in response to input changes. A DDlog programmer does not write incremental algorithms; instead they specify the desired input-output mapping in a declarative manner.
Coq-Equations - A function definition package for Coq
copl-in-prolog - 書籍「プログラミング言語の基礎概念」の Prolog による実装
mathquill - Easily type math in your webapp
libredwg - Official mirror of libredwg. With CI hooks and nightly releases. PR's ok
fricas - Official repository of the FriCAS computer algebra system
crepe - Datalog compiler embedded in Rust as a procedural macro
polynomial-algebra - polynomial-algebra Haskell library
datascript - Immutable database and Datalog query engine for Clojure, ClojureScript and JS
lean-liquid - 💧 Liquid Tensor Experiment