herbie VS paip-lisp

The herbie project using egraphs to explore different ways of rewriting floating point expressions. https://herbie.uwplse.org/ One can also write custom rulesets in egglog (a new egraph rewriting system / language / datalog) https://egraphs-good.github.io/egglog/?example=herbie

The approach is not yet anywhere near being able to touch all the domains sympy can handle. Destructive term rewriting tends to be a bit more forgiving to unsoundness in the rules and still returning roughly meaningful results. EGraph rewriting (and other automated reasoning systems) tend to just return junk as soon as you aren't careful about your semantics. Associativity and commutativity are ubiquitous in CAS applications and encoding these concepts in general purpose terms is rather unsatisfying. The post above emphasizes specialty methods for polynomials, which it would be desirable to find a clean way to integrate into egraph techniques. Variable binding (which is treated in a rather mangled form in CAS systems) is seemingly important for treating summation, differentiation, and integration correctly. The status of doing variable binding efficiently and correctly in egraphs is also unclear imo.

As a starting point, check Herbie: https://herbie.uwplse.org/

Here is a really cool automatic tool that rewrites floating point expressions to be more accurate: https://herbie.uwplse.org/

On a related note, see tools like Herbie which rewrite floating point expressions to improve accuracy without altering the underlying data-type. It's worth being aware that sometimes you get really bad diminishing returns from using bigger floats and what you really need to do is to rewrite the calculation to avoid a weakness of floating point representation, see numerically unstable calculations.

Have you seen https://stevelosh.com/blog/2018/08/a-road-to-common-lisp/ ? "Kludges" everywhere is applicable. On the other hand, having a function like "row-major-aref" that allows accessing any multi-dimensional array as if it were one dimensional is "sweeter than the honeycomb".

I still think CL code can be beautiful. Norvig's in PAIP https://github.com/norvig/paip-lisp is nice.

As for the inside-out remark, while technically you do it, you don't have to, and it's very convenient to not do. Clojure has its semi-famous arrow macro that lets you write things in a more sequential style, it exists in CL too, and there's always the venerable let* binding. e.g. 3 options:

    (loop (print (eval (read))))

PAIP by Peter Norvig, Chapter 23, Compiling Lisp

https://github.com/norvig/paip-lisp/blob/main/docs/chapter23...

Emacs is so much more than a text editor! But I need to stay on topic...

I believe your assessment of LISP (and therefore of MacArthy)'s impact on AI to be unfair. Just a few days ago https://github.com/norvig/paip-lisp was discussed on this site, for example.

Sounds like a great project idea to make a toy demo of this direction you'd like to see. Maybe comparable to https://github.com/norvig/paip-lisp/blob/main/docs/chapter15... and https://github.com/norvig/paip-lisp/blob/main/docs/chapter8.... which are a few hundred lines of Lisp each, but do enough to be interesting.

You could look into Paradigms of AI Programming by Peter Norvig which might interest you regardless of Lisp content.

Lisp has great power, examine PAIP, part II chapters 7 and 8.

A computer running Prolog reasons, and that only requires a couple of pages of code. So it seems feasible that the network could have learned some ability to reason within its network.

IMHO it's because lisp shines to manipulate symbols whereas the current AI trend is crunching matrices.

When AI was about building grammars, trees, developing expert systems builds rules etc. symbol manipulation was king. Look at PAIP for some examples: https://github.com/norvig/paip-lisp

This paradigm has changed.

Origen: Conversación con Bing, 4/4/2023(1) gigamonkey/monkeylib-binary-data - GitHub. https://github.com/gigamonkey/monkeylib-binary-data Con acceso 4/4/2023. (2) paip-lisp/chapter4.md at main · norvig/paip-lisp · GitHub. https://github.com/norvig/paip-lisp/blob/main/docs/chapter4.md Con acceso 4/4/2023. (3) bibliography.md · GitHub. https://gist.github.com/gigamonkey/6151820 Con acceso 4/4/2023.