Dashboard | Walkthrough | About fuzzy logic | The places behind Caribou Ford

Walkthrough

The map — a setting for histories, generators, models, and scenarios

The program you are going to use starts with a map of the fictional Canadian city of Caribou Ford. The map shows shops, houses, green spaces, roads, and parking areas. In real life, all of these can generate waste. A waste manager must be able to forecast how much waste will be generated, of what kinds, and test service responses for collecting and processing it. The map provides a setting for doing so.

Briefly stated, we have models, generators, and scenarios. A generator is a place, such as a shop, that generates waste. A model is a piece of computer program that forecasts how much waste will be generated and what kinds. This will probably depend on internal variables such as a shop's floor area and brand recognition, and also on external variables such as the time of year, weather, and promotional events.

A city is a complex system, and it would be difficult to fit every influence into a single model. So we introduced scenarios. A scenario is like algebra for waste generation: it lets you write formulae that describe a waste history, building them up one piece at a time.

For example, imagine a sports shop called Northern Ice. We could write a simple model that gives it a baseline waste history depending on its floor area and footfall.

But actual waste will also depend, amongst other things, on the season. Around Christmas, we might see furious activity on the 23rd and early 24th, tailing off as shoppers go home; nothing on Christmas Day; sales on Boxing Day; muted turnover during that strange nothing-much period known as Dead Week; and then a return to near-normal activity at the start of January. We say near-normal because many shoppers may find their purses depleted by Christmas.

<> That being so, we .....

Try the map

Look at the map. It contains blue, purple, brown and grey blocks. These represent housing, other buildings, shopping, and parking and delivery areas. Like many Metro maps, this one is topological: it is somewhat stylised to make it easier to read and edit.

On some of the shopping blocks are circles representing shops and cafés. As explained above, we call these generators. There are also a few symbols that we will return to later when looking at how waste is handled.

To pan the map, drag it with the mouse. To zoom in or out, use the mouse wheel.

You can select a block, generator or road by clicking it. More than one item can be selected at the same time. If only one is selected, the panel to the right displays its coordinates, ID, and a few other properties.

You are unlikely to need this information during the walkthrough; it is mainly there to help the developer inspect and edit the map.

The scenario catalogue

Scroll down below the map. Under it is a table with the headings Name, Description, Expression, Range, and Run. Each Expression is a formula defining a scenario. Take a moment to read through the entries in the table.

To run a scenario, press its Evaluate button in the Run column. Several pieces of output will then appear. We deal with these in the next section but one.

Writing one's own scenarios and models

The scenarios and models in this demonstrator have been predefined. In a fully developed commercial product, users would need to create and adapt their own, and the system should support that.

But that is somw way beyond the MVP. We will need to design a formula language that is easy to type and read, while also allowing the system to check expressions for errors.

The details of that language will depend on the kinds of waste histories, models and combinations that users actually need. Establishing those requirements will therefore need further analysis.

So for the moment, the MVP is restricted to the predefined scenarios in the table and to the models used by those scenarios.

Inspecting results and explanations

Here is a summary of the main output windows. As already mentioned, Waste-Impact Output shows generated waste day by day, either by waste category or as total weight.

To the right of the plot is a textual representation of the results. It shows the waste categories and quantities for each day. This is mainly intended to help the developer inspect the calculations.

Under the plot is an Explanation Tree. This shows the order in which the system evaluated the scenario expression to obtain its daily values. This is useful for development, but it can also help users check how the result was constructed.

Finally, the Diagnostics window just above the scenario catalogue shows how the model used in the expression arrived at its result. At present, it has room for only one model's worth of explanation, so it under-reports scenarios that combine several models. One task in moving from the MVP to a fuller product will therefore be to find a clear and convenient way to present diagnostics from several models at once.

Fuzzy logic and the need for intelligible exlanations

<> One rincile behind our advice / work is that rograms hould always exlain themselves. There are way too many rograms, ranging from video recommendation systems to hallucinating large language models, that cannot. <>

Service-response modelling

In my introduction, I said that there are a few symbols that we'll see later when looking at how waste is handled. That time has now arrived.

To demonstrate this, please select any of the Northern Ice scenarios. Ignore the ones that follow, for Twin Fort Landing.

As before, then look at the Waste-Impact Output window. Change the view selector from Total Waste to Waste By Type, and inspect both.

Then scroll down, past the Explanation Tree, to Service-response output — Junction Crossing. Ignore the play controls for the moment and look at the film-strip display underneath. Each frame shows the cumulative level of four waste bins, classified by type as shown. Under the bins are their contents, in kg.

You can scroll these horizontally with the scroll bar under the film strip, or move through the strip a frame at a time with the play controls above it.

Now scroll back up the page until you are just under the map. The top-left block in Junction Crossing holds these four bins. A facilities-management operative periodically moves waste from them, compacts it, and has it collected by a contractor for remote processing.

I took this model from a paper on waste management at Bicester Village retail park in Oxfordshire, England. It's simple, but it's logistically plausible, and shows how we can drive waste-handling models with our scenarios.

So we can think about this in two ways. We can develop a scenario, then test waste-handling models to see which best handles the waste it generates. Or we can develop a waste-handling model, then test scenarios against it to see which are best suited to its capabilities.

In practice, we will need to do both. And in both cases, results should be attractively and clearly presented, and downloadable for use by our other analysis programs.