I suggest you ...

(World model) Three-way relations

It would be nice to have two-way relations that also have an attached value for weighted relationships of some kind; or three-way relations. (These are essentially the same thing, only with different formal properties and kinds of terms.)

32 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Adminemshort (Admin, Inform 7) shared this idea  ·   ·  Admin →
    under review  ·  Adminemshort (Admin, Inform 7) responded  · 

    We
    would still like to see this. The most formidable problems are to do with the
    storage requirements – naive users could easily ask for enormous amounts of
    storage (e.g., a ternary relation between things) without realising how badly
    this will scale as their projects grow larger. Sparse data representations in
    dynamically allocated memory are more plausible, but come with a performance
    hit, and would be restricted to Glulx.

    11 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Captain Mikee commented  · 

        I'm all out of votes, but I wonder if anyone else would like to see compile-time table size declaration similar to the "with blank rows for every thing" syntax. Maybe something like "with blank rows for the combination of every thing and room" if you want a weighted relation between things and rooms.

      • Christopher Conley commented  · 

        Sorry, Andrew -- I just realized while reading an intfiction thread on a similar subject that this actually could be implemented using tables, with one column for each member of the relation. It requires some massive tables, with one row for every single combination of every instance of every kind involved; but, with a few "repeat running through"s, it's fairly easy to populate that list when play begins.

        And, since tables can be continued, it's possible for later authors to extend the system as they like -- as long as they provide enough blank rows to initialize it. So, it actually is possible to implement this extension in the current version of Inform. Thanks for helping me realize that.

      • Captain Mikee commented  · 

        Speaking of storage requirements, has anyone suggested any profiling tools for I7?

      • Captain Mikee commented  · 

        After looking at the template code for relations, I see that you're right - IDs are stored as integers whether they're object numbers or enums. I was thinking the restriction would help people understand what three-way relations are good for (e.g. weighted relations), but that's probably not worth the loss of flexibility.

      • Andrew Plotkin commented  · 

        I agree that native three-way relations would be of great value. I just twitch when someone says they're *necessary* to make a particular game.

        For what it's worth, I don't think that constraining the third element to be a KoV would make it simpler. (Or, to be optimistic, I don't think that allowing the third element to be a thing would make the problem harder. :)

      • Captain Mikee commented  · 

        Andrew - you can do it with tables, but you don't get the advantage of having the table size calculated and pre-allocated for you.

        I think it would be reasonable to constrain the third element of such a relation to be a number or a KoV, if that makes anything simpler.

      • Christopher Conley commented  · 

        Right, I'm using a relation of various lists to one number already. But that's not ideal; a list of any size, including empty, will be accepted. And because values cannot be stored in the same list as any thing, I'm forced to define personality traits as things. So I've already got a relation of {Alice, Bob, attraction} >=> -5. Being able to define {Alice, Bob} -> one trait -> one number in a single line of code (or, better, various people -> various people -> one trait -> one number) would be much neater, and allows the author to specify in the code exactly how many arguments are allowed.

        I would be fine with 3rd+ order relation members being limited to One only (as opposed to Various), for memory purposes.

        I7 doesn't support 3-dimensional tables, and I don't think tables would work here anyway. You can have one table row for each person, and extend that vertically as necessary, but the columns in a table can't really correspond a set of objects, and in any case the number of columns can't be extended.

      • Andrew Plotkin commented  · 

        Can you enlarge a *relation* to accomodate more people created during play? I'm not sure myself; creating objects is an unusual extension and I don't know how it fits with high-level I7 features.

        My point is, you're talking about a data structure problem. (The same data structure problem that Emily mentioned, in fact.) If it can't be addressed by simple tables, then maybe tables with dynamic lists will work. Or tables referring to other tables. Relations aren't magic, they're a convenience tool with a lot of built-in support.

      • Christopher Conley commented  · 

        Can you enlarge a table to accommodate more people created during play, say, or as a continuation of a table defined in an extension? The rows, yes; the columns, no.

      • Andrew Plotkin commented  · 

        I want 'em too, but don't get attached to specific features. Three-way relations are only "absolutely vital" if you insist on implementing attraction *as an Inform relation*. You can do it today if you use tables -- more awkward, but possible.

      • Christopher Conley commented  · 

        This is absolutely vital for implementing any kind of personality-based AI system. Right now Alice can either be attracted to Bob or not, but never slightly or enormously.

      Feedback and Knowledge Base