I have to say, these are my first steps in this kind of topic, so I could be wrong, or I could be trying this people have tried a decade or two ago, and noticed it does not work.
But I think that if I don't keep out semantics the final solution is less general, because: - The moment you apply verbs to arguments at the time of graph construction, either monad or dyad, you loose the capability of reason about the verb's other valence. - The same holds for hooks and forks - Similarly, and likely even worse, for conjunctions: if, when adding e.g. -@:+ as monad, you interpret the @, you end up loosing the @ notation itself, as it would be simply - applied monadically to monadic result of +, i.e. you loose both the dyadic case, as well as the reason you ended up with it. To me this feels as never being able to go e.g. from the explicit -+y to (-@+) y. It seems to me that adding them as equivalent classes later using rewrite rules does not seem difficult and preserves the original as well. Jan-Pieter On Sat, 15 Oct 2022, 02:24 Elijah Stone, <elro...@elronnd.net> wrote: > The whole point is to suss out semantics. Why leave them out? > > On Wed, 12 Oct 2022, Jan-Pieter Jacobs wrote: > > > Hi Elijah, > > > > Thanks for your suggestions, they've been really helpful, the idea of > > having an apply node is exactly what I was missing. > > With that, verbs can be leafs, as well as nouns, so they can both > > coexist in the same egraph. > > I've got the hunch that this is desirable as it allows > > - to keep semantics out of the graph construction > > - treating applied verbs as monad, dyad or both > > - working at the verb-noun level at the same time as at the > > adv/conj-verb level at the same time. > > > > Whether this all is a good thing, future will tell, as I have still to > > see whether it works out. > > > > Jan-Pieter > > > > Op za 8 okt. 2022 om 00:22 schreef Elijah Stone <elro...@elronnd.net>: > >> > >> Distinguish: > >> > >> 1. Notional function (f+) > >> > >> 2. Monadic application of a function (m+, conjugate) > >> > >> 3. Dyadic application of a function (d+, add) > >> > >> Semantically, 2 and 3 are distinct from each other; but j puns them. > (And 1 > >> needs to be distinguished to bridge the gap with j semantics.) > >> > >> The j -@:% is an application of d@: to f- and f%. If you take the > derived > >> verb and apply it (I have a special 'apply' node), cf -@:% y, you can > have a > >> rewrite rule matching (apply (d@: fu fv) y) -> (du y (mv y)). At some > point > >> this needs to be more sophisticated than simple rewrite rules, when you > go to > >> substitute and parse in an explicit definition (or even to substitute > du for > >> fu), but that is par for the course; it can still be treated uniformly. > >> > >> Re ambivalent verbs: usually the user will have a particular valence in > mind > >> and can specify that. But if you care: split the verb into > monadic/dyadic > >> cases, apply to symbolic arguments, simplify, and then restore if > necessary to > >> round-trip. > >> > >> > in + + + + +, all +'s would collapse to a single enode > >> > >> Why? > >> > >> On Fri, 7 Oct 2022, Jan-Pieter Jacobs wrote: > >> > >> > Dear all, > >> > > >> > After recent discussion of the math/calculus addon, I started playing > >> > around with what could become a symbolic toolkit for J, which could > in turn > >> > serve as a backend for other projects, like future versions of the > >> > math/calculus addon, explicit-to-tacit and vice versa, etc. It should > thus > >> > remain as agnostic of verb meaning as possible. > >> > > >> > Current status > >> > -------------------- > >> > I started out implementing egraphs as it looked like a good idea (you > can > >> > find my progress here: https://github.com/jpjacobs/general_sym). It > is > >> > based on this colab notebook I've found: > >> > > https://colab.research.google.com/drive/1tNOQijJqe5tw-Pk9iqd6HHb2abC5aRid?usp=sharing#scrollTo=4YJ14dN1awEA > . > >> > I've gotten so far that I can convert AR's of forks and hooks into an > >> > egraph structure, with place-holder arguments. For now, only named and > >> > primitive components are allowed, no derived verbs resulting from > applying > >> > adverbs/conjunctions. I chose to work on AR's since all parts of > speech > >> > have an AR, and they are already conveniently parsed for recursive > >> > treatment (discovered through my dabblings in math/calculus). My idea > was > >> > that the egraph should ignore the meaning of each individual part of > >> > speech, only taking into account syntax. The meaning and equivalences > would > >> > then be handled by the rewrite rules applied on this egraph structure. > >> > > >> > Perhaps easier to show than to explain: > >> > > >> > install'github:jpjacobs/general_sym' > >> > installed: jpjacobs/general_sym master into folder: general/sym > >> > load'general/sym' > >> > eg=:sym'' > >> > 3 add__eg ((!+#*%+) arofu__eg) > >> > 5 > >> > en__eg > >> > ┌───┬───┐ > >> > │y::│ │ > >> > ├───┼───┤ > >> > │+ │0 │ > >> > ├───┼───┤ > >> > │* │0 │ > >> > ├───┼───┤ > >> > │% │2 1│ > >> > ├───┼───┤ > >> > │# │1 3│ > >> > ├───┼───┤ > >> > │! │0 4│ > >> > └───┴───┘ > >> > The above creates an empty graph, adds the (nonsensical) train > (!+#*%+) as a > >> > monad (x=3) and shows the resulting enodes in the egraph, with y:: > being > >> > what I came up with as implied argument. You can see that + is added > only > >> > once, because it was noticed by adden that it was already present, and > >> > applied to the same arguments, when found the second time. I thought > x::, > >> > y::, u:: and v:: were nice, since they are syntactically recognised > as J > >> > words (by e.g. ;:), but not yet used (others I'd have in mind for > later are > >> > d:: and D:: for deriv and pderiv). The first column shows the > arguments, > >> > verbs, the second column their argument references; the third I added > so > >> > you can easily see where the argument references point to. For > instance, ! > >> > takes as arguments eclassid 0, i.e. y:: and eclassid 5, with 5 being > the > >> > result of # applied between arguments 4 and 3, and so on. The same > works > >> > for dyads (try x=4), NVV forks and capped forks. The interface should > be > >> > adapted to be more user-friendly but it's just a POC at the moment. > >> > > >> > At the moment, enodes (in en__eg) without arguments (i.e. leafs) are > nouns; > >> > verbs are enodes with 1 (monads) and 2 (dyads) arguments. The numbers > >> > listed as arguments are , in egraph terminology, called eclassid, and > point > >> > to classes containing enodes that all represent the same result when > >> > executed. For now, eclasses are all singleton sets of enodes, as no > >> > rewrites can be done yet. > >> > > >> > Now I tried adding conjunctions and adverbs in the mix and came to the > >> > conclusion that my approach runs into troubles: > >> > To know how arguments are applied to verbs, I would need to interpret > the > >> > conjunctions (something I would have prefered to leave up to the > rewriting > >> > rules to implement). > >> > Treating applied conjunctions as opaque, monolithic blocks, is > clearly not > >> > an option (as you then can't influence anything in its arguments, e.g. > >> > -@-@-@- could not be reduced to ]). > >> > An idea that at first sight seems to make sense is to give operators > up to > >> > 4 arguments, up to 2 for the arguments of the operator (u/v) and upto > 2 for > >> > the generated verb, but that breaks down on operators generating > operators > >> > (e.g. 2 : '') and nouns (e.g. b. 0). > >> > Treating the verbs on a higher level, i.e. without caring (yet) about > nouns > >> > to serve as verb arguments,crossed my mind. However, this does not > let one > >> > distinguish for instance which instance in the compound verb the enode > >> > refers to. e.g. in + + + + +, all +'s would collapse to a single > enode, and > >> > it gets worse when they are not all at the same level. > >> > Interpreting adverbs and conjunctions and applying arguments to verbs > >> > directly, thereby removing the need for storing the conjunctions and > >> > adverbs sounds fine for simple operators like @, & and family, but > soon > >> > gets quite difficult to imagine with operators like /. or ;. . > >> > > >> > A last thing I wonder about is how to handle ambivalent verbs. Now I'm > >> > either adding monads, or dyads, but have no way of indicating x:: > might or > >> > not be present. For instance, (#~ {."1) is useful for selecting by > 0/1 in > >> > the first column of y, but can also be used to filter from x based on > y. > >> > The same holds for (/: {."1). > >> > > >> > So, who would have a suggestion as to how to represent operators in > this > >> > kind of framework? Any guidance would be welcome. I could go on > >> > implementing all other machinery to do rewrites, but I feel I'd need > to > >> > have the basic representation right to start with. > >> > > >> > Thanks, > >> > Jan-Pieter > >> > ---------------------------------------------------------------------- > >> > 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 > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
