[ Main page | About Your System | Knowledge Bases | Rule Traces | Demand Modelling | About Fuzzy Logic | The Importance of Explainability | Commercialising ]
This page is about the knowledge bases I have written for you. They all use the same notation for rules and fuzzy sets, and they all calculate their rules in the same way. You will be able to read them without much more than a knowledge of English; but to know exactly how they calculate a result, and how much each rule contributes to it, you'll need to work through the About Fuzzy Logic page. The page on Rule Traces is a useful first summary. In this page, I give details of how each works, note any technical and/or pricing-related points, and tell how to select inputs and run the knowledge base on them.
Linked from here. The knowledge base reacts
to one input variable, days_to_flight. There are
two fuzzy sets for this, many_days and
few_days. There is one rule for each, testing
membership of days_to_flight in it.
Intuitively, the rules do what they say. They select a low price increase if there are many days left before the flight, and a moderate increase if there are few days left. There is a very narrow transition region around 32 days where the price increase is a mixture of both. It's narrow because the input fuzzy sets only just overlap.
To change the variables that this knowledge base uses, use the draggable bar to change days to flight. Then press the βπ option on the knowledge-base menu.
Linked from here. This knowledge base also reacts
to one input variable, days_to_flight, but has an
extra fuzzy set, last_minute. This is bunched up
against the zero-days end, and mandates an extra, high,
increase for about six days or fewer remaining. The closer this gets
to zero, the more this high increase gets mixed in.
I have also changed the many_days and
few_days fuzzy sets so that they
have shallower slopes, and thus overlap more. This
means that the transition from low to moderate
price increase around 32 days is smoother and longer.
What this shows is that we can tailor such transitions
by tweaking our fuzzy sets.
To change the variables that this knowledge base uses, use the draggable bar to change days to flight. Then press the βπ π option on the knowledge-base menu.
Linked from here. This knowledge base
reacts to a different input variable, class.
This is either "tourist" or "business". There are two
rules, one of which selects a low price increase for tourist class,
and the other of which selects a moderate price increase for
business class.
The class variable is
categorical — a classification into two possibilities —
so doesn't involve fuzzy sets in the rule conditions at all.
Fuzzy sets are used as before for price increases, but get
weighted by either 0 or 1. This means that, in effect, one
of the rules always concludes a price increase weighted by 1, but then
the other one concludes an increase weighted by 0, so its
contribution can be ignored.
To change the variables that this knowledge base uses, use the π·πΌ button to toggle tourist and business. Then press the π·πΌ option on the knowledge-base menu.
Linked from here. This knowledge base combines Days To Flight and Tourist Or Business. There are four rules, which cover all possible combinations of class with days to flight being many or few.
Once again, the rules can be understood intuitively. They
introduce a new operator, and, which has more
or less the same meaning as in English. As the
About Fuzzy
Logic references explain, and works by
taking two memberships as input and calculating their minimum.
In A and B, if A's membership is 0, this returns 0.
If A's membership is 1, this returns B's membership.
Since, from the previous section, A is always class = "business" and
class = "tourist", and these are always 0 or 1, A effectively
acts as a gate. It either switches the rule off, or lets B
have full say over the result. You can see this in
action in the Rule Traces.
To change the variables that this knowledge base uses, use the draggable bar to change days to flight. Use the π·πΌ button to toggle tourist and business. Then press the βπ π·πΌ option on the knowledge-base menu.
Linked from here. Capacity utilisation refers to the proportion of a flight's seats that are occupied or sold at any given time. Unlike attributes such as days to flight or class, which passengers can directly choose or control, capacity utilisation is typically a result of airline operations and market demand. Passengers won't have direct control over this attribute, nor is it generally visible to them when booking a flight. Instead, it is more of a derived characteristic that airlines use to gauge how full flights are. They may then adjust pricing or availability accordingly.
The knowledge base assumes that higher capacity utilisation — more seats filled — could trigger higher price increments due to increased demand.
As far as fuzzy logic and programming go, the rules are very simple, and don't introduce any new concepts over those already seen.
To change the variables that this knowledge base uses, use the πͺ menu to select a capacity utilisation. Then press the πͺ option on the knowledge-base menu.
Linked from here. This reacts to capacity utilisation and also to days to flight and to class. It is a more complex example of combining variables.
The tables below show the knowledge base's results at various levels of days to flight (across) and capacity utilisation (down). The first table is business, the second tourist. It will be seen that prices increase monotonically as days to flight decrease, and as capacity utilisation increases. This, I believe, is what a dynamic-pricing system should do. The fuzzy nature of the sets allows once again for smooth gradations between pricing regimes.
| πΌ | 62 | 50 | 40 | 30 | 20 | 10 | 0 |
|---|---|---|---|---|---|---|---|
| 0 | 8.00 | 8.00 | 8.00 | 8.00 | 8.00 | 8.00 | 90.33 |
| 25 | 8.00 | 8.00 | 8.00 | 29.47 | 39.24 | 39.24 | 90.33 |
| 50 | 8.00 | 8.00 | 8.00 | 33.28 | 44.36 | 44.36 | 90.33 |
| 75 | 8.00 | 8.00 | 8.00 | 41.53 | 48.33 | 48.33 | 90.33 |
| 100 | 90.33 | 90.33 | 90.33 | 90.33 | 90.33 | 90.33 | 97.00 |
| π· | 62 | 50 | 40 | 30 | 20 | 10 | 0 |
|---|---|---|---|---|---|---|---|
| 0 | 8.00 | 8.00 | 8.00 | 8.00 | 8.00 | 8.00 | 48.33 |
| 25 | 8.00 | 8.00 | 8.00 | 29.47 | 39.24 | 39.24 | 48.33 |
| 50 | 8.00 | 8.00 | 8.00 | 33.28 | 44.36 | 44.36 | 48.33 |
| 75 | 8.00 | 8.00 | 8.00 | 41.53 | 48.33 | 48.33 | 48.33 |
| 100 | 48.33 | 48.33 | 48.33 | 48.33 | 48.33 | 48.33 | 90.33 |
The tourist prices are, on average, lower than the business prices, presumably in return for worse service. This was arranged by using different fuzzy sets in some rules' outputs. The tourist prices are also "flatter": they don't curve upwards as steeply as the business ones. This illustrates how one can implement different price elasticities. In other words, leisure travelers are often more price-sensitive and plan further in advance, while business travelers are willing to pay more for last-minute bookings due to urgent needs.
To change the variables that this knowledge base uses, use the draggable bar to change days to flight. Use the πͺ menu to select a capacity utilisation. Use the π·πΌ button to toggle tourist and business. Then press the βπ π·πΌπͺ option on the knowledge-base menu.
Linked from here. This knowledge base
is where the event charts on the simulation display come in. Each chart
represents the demand pattern for the green event block shown above it.
The sum of all charts on a particular day is the total demand, and that
is one of the input variables, total_demand_increment,
to this knowledge base.
In principle, we could have written a knowledge base that deals with events directly, by testing the type of all events active, the weather forecast for them, the weather in past years on that date, and so on. The charts are there partly to remind us that there is that way of doing things. However, I think it would get complicated very very quickly. It seems better to aggregate events into a total demand: do so outside the expert system, and use that as an input. For more on how I do this, please see Demand Modelling. In this page, I'll take it as given.
So total_demand_increment is one of the variables.
Strictly, this isn't a demand, it's an increment.
Alpenstadt always has a certain baseline demand: total_demand_increment
measures how much the sum of the charts adds to it.
Although modelling total demand moves a lot of work elsewhere, it isn't sufficient. Unexpected events can occur, and the travel consultant will need to take these into account. That is what this knowledge base does: it assumes a demand model, and provides the levers to tweak it with.
One lever is health_concerns. Health worries
about a destination can arise very quickly: Covid left us
in no doubt of that. The knowledge base contains rules which
add this in as an independent variable influencing price.
Another variable is event_popularity_change. This
allows for sudden negative or positive swings to an event's
popularity, and adjusts price accordingly.
Technically speaking, there is nothing new to these rules. They
use the and operator, which we have already seen,
to combine memberships.
To change the variables that this knowledge base uses, use the π· menu to select a healthcare concern, and the π menu to select an event popularity change. Also move the draggable bar over the charts to adjust the total demand Ξ£π shown at its lower right. Then press the Ξ£π π·π option on the knowledge-base menu.