Relation behavior with infinite and finite domains

Authoring Inform 7
1

This program:

Lab is room.

oto relates one thing to one thing. The verb to oto means the oto relation.
spam is a thing. brick is a thing. spam otoes brick.

When play begins:
if there is a thing that otoes the brick,
  say "[thing that relates to brick by the oto relation], [random thing that otoes the brick], [random thing that is otoed by the spam].";

produces

spam, spam, brick.

This one:

Lab is room.
Encryption relates one number to one text. The verb to encode means the encryption relation.

Drum is always "drum". 5 encodes drum.

when play begins:
say random number that encodes the drum;

doesn’t compile:

You wrote ‘say random number that encodes the drum’ (line 16): but this asks to find a random choice from a range which is too large or impractical, so can’t be done. For instance, ‘a random person’ is fine - it’s clear exactly who all the people are, and the supply is limited - but not ‘a random text’.

Changing the when play begins rule


when play begins:
if there is a number that encodes drum, 
  say number that relates to drum by the encryption relation.

This compiles, but produces a run-time error:

** Run-time problem P59: You can’t implicitly repeat through the values of this kind: a problem arising from a description which started out here - “if there is a number that encodes drum”.

This, however:

when play begins:
if the list of numbers that the encryption relation relates is not empty,
  say number that relates to drum by the encryption relation.

works just fine and appropriately produces 5.

Would you consider this a bug? Or if not a bug, undesirable behavior?

1 Like
2

It’s definitely extremely strange behaviour, given that this:

is a stronger condition than this:


 but the weaker condition is needed to placate the compiler.

1 Like
3

Perhaps the element “list of numbers that the encryption relation relates” explicitly defines a necessarily finite element for the parser, unlike the other two approaches?

4

Haven’t tested, but does this work?

when play begins:
  if a number (called N) relates to drum by the encryption relation:
    say N.
5

Problem. You wrote ‘if a number (called N) relates to drum by the encryption relation’ (line 48), but ‘a number (called N)’ is used in a context where I’d expect to see a (single) specific example of a value, not a description.

I was trying to match one of these phrases:

  1. (a number ( called n ) - value) relates to (drum - name of kind) by (encryption relation - relation of values)
  2. (a number ( called n ) - name of kind) relates to (drum - value) by (encryption relation - relation of values)

I recognised:
a number ( called n ) = a description of numbers
drum = a non-temporary variable, holding a text
encryption relation = a relation of numbers to texts

6

Drat.

7

I think the pieces are in place at the I6 level for a working version of the condition that’s currently causing the RTP. Unfortunately, I still don’t know enough about Neptune to get it to work.

This is almost working in 6M62:

To decide whether there is a (name of kind K) that relates to (V2 - nonexisting value of kind L variable) via (R1 - relation of values of kind K to L):
	...

but the compiler is generating bad I6 – terminating a temporary assignment inside the parentheses part of an if condition with a semicolon instead of a comma.

There should be some form of RelationTest() that produces a correct answer.

1 Like
8

I was able to get what I’m perceiving as the desired result if I assign the value generated by the phrase in @zarf’s suggestion first, then do something with it. I also re-read WI 13.13 Relations involving values, which does talk about the impracticality of enumerating all possible ways one thing could relate to another and then talking about the various phrases to help with that.

Lab is room.
Encryption relates one number to one text. The verb to encode means the encryption relation.

Drum is always "drum". 5 encodes drum.

when play begins:
	let X be the number which relates to drum by the encryption relation;
	say X;

Output:

5
Welcome
An Interactive Fiction
Release 1 / Serial number 241118 / Inform 7 v10.1.2 / D

Lab
2 Likes
9

Perhaps closer to the crux of the question on whether this is a bug or not, I do see discussion in a few parts of the documentation that talk about nuanced use cases of what Inform allows and does not allow when working with potentially infinite sequences of numbers: WI 4.6 talks about how numbers can’t have properties because there are an infinite range of numbers, WI 6.1 talks about why Inform rejects the phrase number of (description of values) ... number if the number produced is potentially infinite (i.e. number of odd numbers), etc.

So there seems to be somewhat of an awareness of the limitations of describing something that represents a set of infinite numbers, but there also appear to be limited ways to express these sets in other ways.

Whether this is desirable behavior or not, you’ve shown that expressing potentially infinite numbers has differences relative to other kinds, but I don’t think I have any authority to say whether this is undesirable. The warnings in the documentation though are perhaps a clue of the awareness of this conundrum and does seem like there were efforts to reconcile.

1 Like