Hello Matías, On Sunday, November 18, 2018 at 9:31:24 PM UTC+1, Matías Guzmán Naranjo wrote: > > Hi all, > > are there any updates on this topic? Tahnks >
Do you have reference about feature structure you are talking about? Is it the same thing that is described in http://www.nltk.org/howto/featstruct.html? > > El martes, 27 de diciembre de 2016, 6:24:48 (UTC+1), Jason Hemann escribió: >> >> Ken, >> >> That's on the order of what I was expecting, although it's more >> sophisticated than I'd figured on. >> >> * Feature constraints sound promising, but AFAIK not implemented in any >> Kanrens >> * Your encoding is pretty darn cool, but it maybe isn't the clearest way >> to encode the data. >> >> The other options I'm coming up with are: >> >> * hack up the unifier and add it there >> * implement a feature-structure-unify as a miniKanren relation. >> >> I think the final choice is the traditional way to do this in Prolog, >> yes? >> >> JBH >> >> >> >> >> >> >> >> >> On Mon, Dec 26, 2016 at 4:44 PM, Chung-chieh Shan < >> [email protected]> wrote: >> >>> But we want the alists >>> ((a . _.0) (b . y)) >>> and >>> ((b . _.1) (a . x)) >>> to unify, yielding the mgu >>> ((a . x) (b . y)) >>> or equivalently >>> ((b . y) (a . x)) >>> >>> And we want the alists >>> ((a . x)) >>> and >>> ((b . y)) >>> to unify, yielding the same mgu as above. >>> >>> So the only way I know to encode (even unnested) feature structures >>> using trees is to map each feature name to a globally fixed address >>> in a binary tree. For example if we decide globally that "a" maps >>> to the address (left left right) and "b" maps to the address >>> (left right right left) then the alist above >>> ((a . _.0) (b . y)) >>> can be encoded by the tree >>> (((_.2 . _.0) . (_.3 . (y . _.4))) . _.5) >>> >>> Maybe this is what Jason has in mind? It's related to expressing >>> memoization as a lazy data structure. >>> >>> On 2016-12-24T12:07:14-0500, Dan Friedman wrote: >>> > I agree with Jason, processing alists (even split alists)i standard >>> fare. >>> > Nested alists might want some constraints Haven't given that >>> observation >>> > much thought. >>> > >>> > On Sat, Dec 24, 2016 at 11:08 AM, Jason Hemann <[email protected]> >>> > wrote: >>> > > I think these can be encoded using trees, yes? (Wiki seems to also >>> suggest >>> > > so, if I'm reading that correctly). I know of no implementations that >>> > > implement feature constraints presently, but I know those have been >>> investigated >>> > > in other contexts >>> > > <http://www.sciencedirect.com/science/article/pii/0743106694900442>. >>> > > >>> > > On Sat, Dec 24, 2016 at 8:06 AM, Amirouche Boubekki < >>> > > [email protected]> wrote: >>> > > >>> > >> Did anyone implement minikanren for feature structure >>> > >> <https://en.wikipedia.org/wiki/Feature_structure>? >>> >>> -- >>> Edit this signature at http://conway.bostoncoop.net/~ccshan/cgi-bin/sig >>> Information is not knowledge. Knowledge is not wisdom. Wisdom is not >>> truth. >>> Truth is not beauty. Beauty is not love. Love is not music. Music is THE >>> BEST. >>> ― Frank Zappa >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "minikanren" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/minikanren. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> JBH >> > -- You received this message because you are subscribed to the Google Groups "minikanren" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/minikanren. For more options, visit https://groups.google.com/d/optout.
