I don't think we need to model all of J here. The derivative of ": is not going to be a thing, for example.
Building up from a useful core is probably the way to go. And that starts with rank 0 numeric functions (followed by their higher ranked analogs). Having enough documentation to keep core contributors from getting lost (and ease the path for new contributors) also seems important. Anyways, ... my experience with (hopefully related) projects kind of like this suggests that there's something to be gained from rewrites as we learn how to approach the problems. (And that some test -- hopefully quick tests -- are invaluable for avoiding regressions.) Thanks, -- Raul On Tue, Oct 4, 2022 at 2:33 PM Jan-Pieter Jacobs <janpieter.jac...@gmail.com> wrote: > > I took a quick glance at egraphs-good (egg) and I can see the > advantage. I just wonder whether a setup like this could manage with > the complexity required for fully modelling J. > > For now the calculus addon pretty much manually codes every possible > combination, each with its own, adhoc structure. I agree rewriting > rules would be far easier to edit (and probably reason about) in a > framework like egg, certainly when having the ambitious goal of > creating a rewriter / optimizer / compiler for J. If this works, it > could also form the basis of a rewrite of the code for 13 : 'string' > and debug/tte. > > The problem is I don't speak Rust. I understand the basic examples, > but anything further is beyond me (for now). I also have a hard time > imagining how to fit all of J into a language definition using egg > (e.g. verb rank, keeping track of shape, ...) . Perhaps I just need > more time to absorb... > > I presume that if we could model J in egg in Rust, it could be > compiled to a dynamic library and called via the CD FFI to work the > magic on string representations. In this way, we'd profit from the > alleged speed of egg, and any future improvements they might make. > > The egg website also lists this interesting python notebook: > https://colab.research.google.com/drive/1tNOQijJqe5tw-Pk9iqd6HHb2abC5aRid?usp=sharing > . I think it would be feasible to translate that into J (I've started > but not finished yet). > > Anyway, good stuff for thought, thanks. > > Op vr 30 sep. 2022 om 10:14 schreef Elijah Stone <elro...@elronnd.net>: > > > > > > On Fri, 30 Sep 2022, Jan-Pieter Jacobs wrote: > > > > > Ideally the simplifier should be called en-route, because the derivstg and > > > family (doing differentiation on string representations) call themselves > > > all > > > the time, which is why in the current version, things like 1&o. deriv 100 > > > blow up. > > > > Ha, yes, I see. I should mention--this representation needs to be gced > > periodically, otherwise it will blow up similarly. (But any symbolic > > manipulator will generate a lot of garbage, and the j interpreter is quite > > bad > > with small objects, so this is probably better than the alternative anyway.) > > > > > > > This is, partly, what the calculus addon does. It works with atomic > > > representations, which appears to be (I've nearly no CS background) a > > > parsed > > > tree structure of any J entity. > > > > Afaik, 'gerund' is synonymous with 'atomic representation' (glossary agrees > > with me, at least). I don't think ARs are very nice to manipulate from j. > > There's empirical evidence that this is the case: the calculus addon doesn't > > _generate_ ARs; it generates strings, which it then parses. This sort of > > stratification is no good for composability. > > > > > > > I'd do the edge to y first, to stick with J's right to left evaluation. > > > Even > > > if we should not really care because it's a non-standardised > > > implementation > > > detail, this is the behaviour of forks at the moment. It makes a > > > difference > > > when y or x have side effects. > > > > I'm not talking about side effects. + was a bad example since it's > > commutative; but e.g. you care a great deal about the difference between x-y > > and y-x. > > > > > > > I don't know whether this is possible, at least not with the current > > > setup: > > > deriv executes, and thus disapears, the moment it is applied to its > > > arguments... > > > > Right--I'm suggesting something very different from the current setup. > > > > > > > Internally, the addon already uses this identity, see e.g. here > > > > Yeah--just a simple example; but the idea is that you'd want to build up a > > very large library of similar rewrite rules, and a succinct way of > > expressing > > them; and that it would be easy for people to contribute to that library of > > rewrite rules. > > > > Perhaps a conjunction like assert_eq, such that you can say 0&+ assert_eq ]. > > (Or specify separately monad/dyad; specify additional facts that have to > > hold; > > whatever.) > > > > -E > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
