opencog
MemberLink swap arguments
Currently member link is formatted as
MemberLink
<element>
<concept>
Linas has suggested a while ago to swap the arguments, as follows
MemberLink
<concept>
<element>
I agree with that for the following reasons
- That way it would be consistent with
EvaluationLinkthat follows
EvaluationLink
<predicate>
<element>
- It agrees with other similar links like
AtTimeLink
AtTimeLink
<node>
<time>
- There's a more conceptual reason, coming from functional programming, that arguments should be ordered from least frequently to most frequently changing value, because you can easily partially evaluate them on the first arguments and obtain, by currying, a function on the remaining arguments. It makes more sense to specialize (partially evaluate) a function by fixing its least frequently changing values than the opposite. For instance if you have
power: Number -> Number -> Number
by setting the first argument as the base and the second as the exponent, you can easily define specializations such as
power-of-2: Number -> Number
power-of-2 = power 2
or
exp: Number -> Number
exp = power e
Any opinion? In the absence of feedback with the next 48h, I'll probably do the change.
Arguments make sense. What about InheritanceLink(s) ? Should they be transformed by the same way?
I think InheritanceLink(s) should remain unchanged, first there isn't an obvious order based on frequency, and it is consistent with ImplicationLink.
I apologize for the bad reaction 8 days ago. I have several large datasets that have MemberLinks in them, so the pull request would scramble them. However, on closer inspection, these datasets are low quality and need to be recomputed, anyway. I'm gonna try to carefully think this through before launching the next major run. Perhaps making the swap at that time, after data analysis on the current datasets is complete, would be a good time to make the change.
@linas just a reminder to have you ponder about it before relaunching your experiments ;-)
BTW, it's not sure that your experiments would be affected by this change. As far as I know there are only 2 core components that assume a particular order for MemberLink, which are ECAN and the URE (and of course components that use these like OpenPsi).
I use MemberLink to assign WordNodes to WordClassNodes, I've got three large datasets that contain these MemberLinks in them, the datasets are described in the last 3-4 pages of the language-learning diary in opencog/nlp/learn/lang-learn-diary/lang-learn-diary.pdf As mentioned, those datasets are inadequate, and need to be recomputed. However, recomputing them is a 2 or 3 steps process, with each step taking maybe a week, and then I do data analysis on them, which is a kind-of unbounded amount of time. The original pull request came at a time when I was being particular active on this. Right now, I am waiting for the "paint to dry" on other part of the process. I'll try to look real soon.
Source code includes cset-class.scm gram-agglo.scm and gram-class.scm which your original pull request ignored.
Sorry for being late to the game here. I thought that MemberLink is essentially an extensional inheritance link (ExtInhLink), no?
If so, seems like it would be awkward to have the argument order for MemberLink one way and the order for InheritanceLink (and IntInhLink) the other.
On Sat, Jul 14, 2018 at 3:45 PM, Linas Vepštas [email protected] wrote:
I use MemberLink to assign WordNodes to WordClassNodes, I've got three large datasets that contain these MemberLinks in them, the datasets are described in the last 3-4 pages of the language-learning diary in opencog/nlp/learn/lang-learn-diary/lang-learn-diary.pdf As mentioned, those datasets are inadequate, and need to be recomputed. However, recomputing them is a 2 or 3 steps process, with each step taking maybe a week, and then I do data analysis on them, which is a kind-of unbounded amount of time. The original pull request came at a time when I was being particular active on this. Right now, I am waiting for the "paint to dry" on other part of the process. I'll try to look real soon.
Source code includes cset-class.scm gram-agglo.scm and gram-class.scm which your original pull request ignored.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opencog/atomspace/issues/1754#issuecomment-405054596, or mute the thread https://github.com/notifications/unsubscribe-auth/AEHdukVCu8ih80KD6aMSR_HGNChWBiRWks5uGnRsgaJpZM4UvXPj .
MemberLink is basically set membership https://en.wikipedia.org/wiki/Element_(mathematics). So, yes, the cons of that change (besides the fact that it opens rooms for midterm confusions) is that it is in contradiction with the order of the mathematical symbol ∈. It is also in contradiction with the order of member from the srfi-1 Scheme module https://srfi.schemers.org/srfi-1/srfi-1.html#member which I don't like (I wasn't aware of that at the time of creating that PR).
So overall, although I initially felt positive about that PR, I now have mixed feelings about it.
I think of it like so: "we are talking about the topic, and the topic is this set A. I'd like to mention the fact that, among other things, element x is pertinent to this topic, i.e. is relevant, that is, A contains x". So A comes first, because its the important thing, the thing being talked about, and x's membership is really just a commentary about A. Thus, in many mathbooks, you will see A ∋ x That is "A contains x"
Perhaps we should leave MemberLink alone, and create a ContainsLink, and then try to transition all usages from MemberLink to ContainsLink? That way, we have backwards compatibility, and a non-messy transition forward.
FYI, I am about to commit a change that adds the following atom types. The last one, TagLink is effectively a MemberLink with the order of the arguments reversed. These new Atoms may seem weird to you, as they don't fit neatly into the order of things as you know them. I have mixed feelings about them, but convinced myself that I need them, in order to keep some basic data processing pipelines maintainable and coherent.
// ----------
// The following Atoms are meant to describe "raw data", before that
// data has been organized with the Connectors and Sections above.
// Unlike the above, they are not rigorously defined; they're only
// for making low-level code more organized and easier to read.
//
// The general idea is this:
// * Items are "things" (words, pictures, sounds) being generated by
// some data stream.
// * ItemClasses are classifications of Items (words that are nouns,
// pictures of bicycles and road signs)
// * Tags are names of the data streams (streams of words, pictures)
//
// Note that the difference between a type and a set is blurry; so, in a
// sense Tags and ItemClasses (and sets) are all the "same thing". It's
// just handy to have these around for different kinds of uses in the
// code base.
// An ItemNode is used for any "item" or "thing" that we want to track.
// It's lexical, because, in general, we will be looking it up in some
// table or dictionary. See issue #2901 for discussion.
ITEM_NODE <- LEXICAL_NODE
// An ItemClassNode is a name for a collection of Items. Roughly, a
// collection is a set; this is the name of that set. Set membership
// is denoted with MemberLink so:
// (MemberLink (ItemNode "foo") (ItemClassNode "all foo things"))
ITEM_CLASS_NODE <- LEXICAL_NODE
// A TagNode is a name for a data stream that is generating Items.
// Data streams are kind-of-like sets, except that they are constantly
// popping out more Items, so they're not static or fixed.
TAG_NODE <- LEXICAL_NODE
// A TagLink is a link between a TagNode and the Item being tagged.
// The "natural" convention is to make the Tag first, the Item second,
// and so the order of the arguments is reversed from a MemberLink.
TAG_LINK <- ORDERED_LINK // <- MEMBER_LINK