The World as Information: Part 6

Modeling and Natural Language

Apr 11, 2025

Now we are getting to the more fun parts. In this part we will begin to see how information structures tend to correspond with natural language and how, with a little extra code we transform natural language constructs into Proteus models and vice-versa.

As with the previous articles I wish to avoid huge textual explanations as well as overly detailed examples. To that end, in what is ahead I will develop various models and then talk about how they illustrate a general modeling technique as well as point out their deficiencies and how they can be improved to cover more complex use-cases.

Chapter 1: A default library

Just as with languages like C++ with its standard library of useful classes and functions, there are a myriad of small models that are used so often we should just assume they are available. Let us build that as we go along, starting with models from previous parts:

concepts: {
   @rat  = (*_+_ *_+_)
   @unit = (*1+_ *_+_)
   @coord = rat
   @x = coord
   @y = coord
   @z = coord
   @angle = unit
   @a1 = angle
   @a2 = angle
   @a3 = angle
   @location = {x y z}
   @orientation = {a1, a2, a3}
   @color = *_+[red, blue, pink, ...]
   @object = {location, orientation, color}
}

The above is a very preliminary start. Location and orientation do not really capture spaces, the definition of color is almost useless; we will update it shortly. And the definition of objects doesn't account for velocity. Nor does it tell us how to identify a starting position. Nevertheless, this will get us started.

From now on, we assume these models can be used without further mention.

Chapter 1: A Toy Model

As we progress, we will go into more and more detail about modeling complex systems. For now let us start with a toy model that we can use as an example in this article. Let us model a bike. We will not model how the parts fit together or their shape or what they are made of or how the bike changes over time or how it changes your spatial location if you ride it.

But we will model some of its state at an instant. Obviously we can assert the existence of states with the notation *n+m, or by using rat for rationals or unit or other such definitions. But we can also assert states by talking about a sub-part that has states. So for more complex systems we can simply list their parts to assert their states:

@Bike = {
   &object,
   Bike frame
   Steering system,
   Pedal assembly, 
   Front wheel,
   Rear wheel,
   Bike chain,
   Bike seat,
   ...
}

It might seem that this definition is circular since it contains “bike” which is the object being defined. But recall that these definitions are descriptive. That is, Proteus can search for something based on its structure regardless of what it is named. We wouldn't have to define “front wheel”. We could define “front bike wheel” or just use a generic definition of “front” and “wheel” and refine our wheel description for a bike later. The reason “wheel” will work is that the description “the bike's around-the-axel thing with gears” would be enough of a match to the description of the structure of a bike's rear wheel. (That is assuming definitions of gears, around, axel etc exist.) So the important part is not choosing the perfect words or phrases to define but getting the model that the words call up to a place that it works for what you need.

General models

In the long run, a really great model of a bike would have a core that was just the essentials of what a bike is. Maybe: 2 inline wheels, a frame, and a way to propel it such that a person can use it to more rapidly change their location. The information flow is from the pedal system and the steering system to the rider’s location. Then other refinements could describe 10-speeds, mountain bikes, different brands of bike and so on. These refinements could include how pedals update the chain and in turn, the rear wheel against the ground to ultimately update the rider’s location state. By analyzing these more specific models the engine could determine if the mechanism would indeed update the rider's location. So there are different ways that being a bike can “supervene” on the states of the sub-parts. But they will all meet the basic core information flow. That is, whether the information flow is from pedals to the rear wheel then from the ground, through the frame and seat, into the rider's location, or, through some hand-based propulsion mechanism or maybe an electric motor, doesn't matter. If the mechanism’s information system matches the core “bike” information flow pattern then it can be found as matching the word “bike”.

To complete the definition of a bike we would need to also model all the parts such as the pedals, steering system and so on. Further, we would model how the parts fit together when assembled, how the states of the parts interact and and how it can be part of a super-system consisting of a bike and a rider.

Don’t worry, we will go over how to do all of these things but with a simpler system than a bike. Spoiler, we will eventually model a rubix cube.

But first, let’s look at different ways we can talk about what state something is in.

Chapter 2: Constraints on states

Now we have a way of describing an object by telling what states it has. For example, given the above we could use the following Proteus code. For simplicity, let’s assume a bike is in the context %ctx:

%ctx.bike.rear wheel.orientation.a1 = 0.5

Presumably, this means that the wheel is half way around it’s rotation. But we do not talk like that. For one thing, what is the starting position? And it's linguistically odd to be so precise.

It would be cool to have a variety of models that, rather than assert that states exist, merely constrain the values of the states in useful ways. For example, rather than having to give an expression of someone's x,y,z location relative to our own, we could encapsulate that in a model and call it “far away” or “really far away” or “3 feet away” or “right next to”.

Let us come up with some ways of describing and constraining the “color” state given in the object model. We need to completely redo the color model given above.

Modeling color

When making a model it is important to think about the purpose it will be used for. That can inform which details to include and when you have enough detail. We want to define names for colors so we can use the Hue/Saturation/Brightness (HSB) model. Later we will also want to map colors to computer representations such as jpegs or streams from a camera. So we also need the RGB model and a mapping between HSV and RGB.

First we note that Hue is in the range 0 to 360 and the value wraps around. Saturation and brightness can be measured from 0 to 1. The states of a color are hue, saturation and brightness. Lastly, we define some color names by constraining the values for hue and sometimes saturation. We can use these colors in a definition of a rubix cube.

concepts:{
    @hue = (*360+_ *_+_),    // Hue: rational representation (0–359°)
    @saturation = unit,      // Saturation: unit value (0 to 1)
    @brightness = unit,      // Brightness: unit value (0 to 1)

    @HSB = { hue, saturation, brightness },  
    @color = HSB,            // Color is defined as its HSB state

    // Named color definitions.
    // (Fields not given (saturation and brightness) are 'unknown')
    @red     =  color:{ hue = range:{start:355, end:10} },
    @brown   =  color:{ hue = range:{start:20, end:40}, 
                         saturation = range:{start:0.0, end:0.5} },
    @orange  =  color:{ hue = range:{start:20, end:40}, 
                         saturation = range:{start:0.5, end:1.0} },
    @yellow  =  color:{ hue = range:{start:50, end:60} },
    @green   =  color:{ hue = range:{start:80, end:140} },
    @cyan    =  color:{ hue = range:{start:170, end:200} },
    @blue    =  color:{ hue = range:{start:200, end:240} },
    @purple  =  color:{ hue = range:{start:240, end:280} },
    @magenta =  color:{ hue = range:{start:280, end:320} },
    @pink    =  color:{ hue = range:{start:330, end:355} },
}

This simple model of color can be made much more comprehensive in at least three ways. First, It basically only models typical human vision. Eagles and cats, for example, have different colors they can see. Similarly, space telescopes have sensors for other ranges of light. A more comprehensive model might account for these.

Second, color can be mapped to frequencies of light and the way photons interact with objects and are reflected into eyes or sensors to be picked up by rods and cones or a camera sensor.

Lastly, There is an enormous amount of knowledge from color science that could be digitized in these models.

Mapping to RGB

Let's quickly look at how we can map RGB colors to HSB. One way to do this would be to define RGB as a color with the additional variables red-level, green-level and blue-level and map them to H S B. However, the RGB color model is just as valid as the HSB model so let us re-work the model of color to have both interpretations.

Something to notice in the following is that some intermediate values are defined to be used in the calculations. By keeping these defined in the same concept set, the scope rules of Proteus will not choose their definition if the topic is not converting color formats (and assuming there are other definitions that work better). Also, note the use of the *_+[…] syntax to choose one item depending on the range of the hue value. This will be briefly discussed afterwards.

concepts:{
  @color = {
    HSB,

    chroma = saturation * brightness,
    X = chroma * (1 - abs((hue / 60 mod 2) - 1)),
    m = brightness - chroma,

    rgb1 = {r1, g1, b1} = *_+[
      { hue = range:{start:0,  end:60}, 
        result={r1 = chroma, g1 = X, b1 = 0 } 
      },
      { hue = range:{start:60,  end:120},
        result= { r1 = X,  g1 = chroma, b1 = 0 }
      },
      { hue = range:{start:120, end:180},
        result= { r1 = 0,  g1 = chroma, b1 = X }
      },
      { hue = range:{start:180, end:240},
        result= { r1 = 0,  g1 = X,  b1 = chroma } 
      },
      { hue = range:{start:240, end:300},
        result= { r1 = X,  g1 = 0,  b1 = chroma } 
      },
      { hue = range:{start:300, end:360},
        result= { r1 = chroma, g1 = 0, b1 = X } 
      }
    ].result,

    RGB = {
      red level   = (rgb1.r1 + m) * 255,
      green level = (rgb1.g1 + m) * 255,
      blue level  = (rgb1.b1 + m) * 255
    }
}

You can see here how RGB levels are calculated in terms of the HSB values. Notice that all the operations here are reversible and thus the engine should be able to calculate HSB from RGB.

Also notice that all the new values, such as chroma or even RGB, do not add new information to colors because they are calculated from HSB. Thus they are merely views into a color.

In the calculation there are different results based on the range of the hue. You can see that inside the square bracketed list (after ‘*_+’ which gives the list an unknown size) there are 6 places where an assertion about the range of hue is given, followed by setting the result. After the […] we see .result which selects the result.

This is how we encode conditionals. Recall that a list in square brackets returns the last item in the list. But if the size is unknown, that could be any one of the items. So if we put assertions in the items then it can evaluate which one it is by seeing if the assertion is true. If we also set some variable like result in each one, then it can choose the correct value for result to return. This way of doing conditionals might seem odd at first. But it let's the engine choose how it will determine a truth. Often a programmer will have to construct in if-condition based on some logic but there could be other ways of making the condition that would be available in different situations. This method just describes possible situations. Determining the test for that situation can be done at run time with the available information. In fact, a Proteus engine could reverse the entire thing by seeing what the result must have been and thus know the range for hue.

Using adjective models

We have made a vague distinction between models that assert that there is a state — like bike or color — and those that constrain states, like red or large or far away. The models that constrain states are useful for describing the values of the states of objects. That is, what state is it in? The reason the distinction is vague is that many models that constrain states do, in fact, also have a state. For example, red, by the definition above, is a color and thus has states. It’s just that the hue state is constrained to certain values. Such models can be used like objects. As in “What is you favorite color?” Nevertheless, the primary use of some models is to put constraints on an object's states and thus they perform like adjectives.

Here are some ways we can use adjective-like models:

“a red bike”

Bike.color=red

Recall that the “magic” infon %ctx stores the last few things referred to in a conversation. So, if we suppose that in a conversation there was a recent reference to a collection of bikes, we could refer to the red one with:

“The red bike”

%ctx.(bike.color=red)

Or: “The bike is red”

(%ctx.bike).color=red

The parentheses in these examples ensure we are referring to the red bike or the bike's color respectively.

We can use the techniques described in previous parts to make references or usages equivalent to:

All the red bikes
The bikes that are not red
What color is the bike?
Every third bike is red

And so on.

Summary

We have looked at how to model the state of an object at an instant and how to use models that constrain states to common use cases without having to give numeric expressions.

As an exercise, pick some adjectives from a dictionary and think about how to define them in terms of constraints on state.

Chapter 3: Function Words

Languages, in general, can have words in them that are sort of built in. C++ and similar languages have words like ‘for’ and ‘if’ and ‘class’ that are not user defined and are not functions or classes. I think it is cool that in functional languages these keywords can be user defined. Proteus is like that. In English, there are something like 200-300 function words depending on what you count and if you count different word forms. Words like ‘a’, ‘the’, ‘some’, ‘many’, and so on are considered function words. Let us define a few as examples:

We’ll start with the word ‘a’. We can define ‘an’ the same way.

The word ‘a’ has a number of uses but the primary one, which is its use as an indefinite article, is used to introduce something into the conversion context (as well as to assert or query something in connection with the associated noun). If one says:

I got a new bike yesterday

They add a bike into the conversation context.

In Proteus, to do that we just use the word naming the model. So where in Proteus we say ‘bike’, in English we say “a bike”.

In Proteus we can refer to a conversation context, with:

%ctx

The %ctx is an automatically maintained list of references in the current conversation as well as items the conversants may uniquely understand to be referenceable without any context. For example, the moon or the house they both live in.

So ‘a’ can be modeled:

@a %arg = %arg

Once the bike is in the context we can refer to it:

The rear wheel had a bent spoke.

In Proteus we can either rely on the engine to parse ‘rear wheel’ as one item and find the instance and model referred to or we can use parentheses. So “the rear wheel” in Proteus is:

%ctx.(rear wheel)

Assuming that our model of a bike contains a rear wheel and that the model of bike wheels has spokes, the first part of the above sentence will be derefenced as expected.

So we model ‘the’:

@the %arg = %ctx.%arg

‘The’ is used to pick exactly one thing from the conversation context. Basically, the last item referred to in the conversation that matches the pattern given right after ‘the’.

This definition of ‘the’ is not exactly right. If there is more than one item to be found it will choose the first one found. For example, what if I instead said ‘the bike's wheel’ there would be an ambiguity because bikes have two wheels. It is left as an exercise to fix the definition. Make it return all the matching items with the assertion that only one of them is valid. When the engine is conversing with a human, it can be made to resolve ambiguity by asking something like ‘which wheel; there are two?’

Comments

Note how using language this way is very different from a word-only usage. Instead, we do have words, but they call up or compose to models that enumerate the parts and sub-parts of the items models. More than that, the models can say something about how the parts interact to perform a function and even how the whole system interacts with other systems. So we don't need syntax checks to see if ‘the rear wheel’ should be parsed as:

The (rear wheel)

The (rear (wheel))

because the latter will not form a coherent model.

Some and Any

Here is Some:

@some %arg = (%arg, { %arg | ... })

The first %arg ensures that there is at least one of the items. Then there is a list of 0 or more. I would have defined “at least one” using ranges but chatGPT did it this way and I like it.

And Any:

@any %arg = { %arg | ... }

Some syntax is needed

You may have noticed that these definitions are under specified. For example, the definition for “any” is the same as for making the argument plural. We will need to define some syntax (see the tiny-lang example) to distinguish these usages.

Coming up:

In the next part we will define the states and shape of a rubix cube. We will then look at how the cube can evolve over time. We will describe how to model common changes (such as turning a face of the cube or disassembling it) and to assert that they happened or will happen at different times. I will demonstrate how our reference Proteus / Slipstream engine can draw the cube in 3D and iterate how it looked at different times. We will also look at models that constrain how changes happen. For example, did they happen “quickly”? Was the transition “smooth”?

Lastly, we will briefly consider how to model the “levels of being” of a rubix cube so that, in addition to being able to determine what would happen if we turn a face of the cube, we could determine what would happen if we held it over a flame or hit it with a hammer.

Bruce’s Substack

Discussion about this post

Ready for more?