MathCAD

       

A genuinely optimum fire bucket


(Translation into English by R.Girvin)

(Russian Text)

This optimization task was easily manageable either numerically (see Etude 2) or analytically (see Etude 7). In those, we learned how to maximise the volume of a bucket given a chosen manufacturing technology: cutting a sector from a metal disk and folding the remainder into a cone. But that way the bucket lost not only optimality, but also the status of bucket: it turned into a fire bowl! It was also impossible to put on a floor, and would be useless for any purpose except as a Vietnamese hat. In our rush for Number (the volume of the bucket) we have lost Essence (the function of a bucket, its capacity for conveniently carrying liquid).

The author recalls a cartoon film based on a Norwegian fable about a goat that learned to count, and decided to count all the farm animals: "I am one; the hen is two; the pig is three, etc." But as all the animals were moving around, the process soon turned into uproar. "Oh, have you counted me?!" "Keep still, or else..!" But everything ended happily, both for the goat and the fable.

In this story, as with any other fairy tale, there's a deep wisdom. It's necessary for us to count things, but as we interact with them we can run into a conflict. Not only does Nature dislike sharp corners, but also enumeration, which in a number of cases simply kills her. This can be observed not only in biology and physics, where the tools of knowledge frequently unrecognizably spoil the object of research, but also in computer science. This applies not only when applying computers to natural sciences applications, but also when applying computers to computers.

To establish a diagnosis, a doctor has no need to know the exact numerical value for a patient's body temperature (36.6C, 38.9C, etc). It's enough to express the thermometer indications by ranges, on which 'medics' have agreed beforehand: "low", "normal", "raised", "mild fever", "high fever". The borders of these estimates, though precisely fixed, are nevertheless imprecise – 'fuzzy'. This comes not merely from modern representations in terms of fuzzy set theory (FST) but also in terms of practical reality: thermometer error, measurement technique, and so on. A graduate of a medical school can tell you, without even pausing to think, where the division between high and very high temperature lies. The skilled doctor can decide this without consciously thinking of the number, while diagnosing better than the beginner.


Even the parameters of patients that are expressed not in real numbers, but in a kind of binary – Wasserman test positive/negative, Koch bacilli present/not present, HIV positive/negative, etc. – have 'fuzzy' borders. Laboratory analysts know this well. If you glance in any therapeutic reference book, where the symptoms of illnesses are described, normally you won't see hard numbers for body temperature, arterial pressure, haemoglobin count, etc. You'll simply see a broad categorisation: "is raised", "is lowered", and so on. Perhaps this is why programs that output a diagnosis, based on patient parameters entered into a computer, have not received wide practical application. One of difficulties in this area is translation of the parameter (a number) into a symptom (a category).
There's a generally accepted identification of three recent revolutions in programming: structural, object-oriented, and visual. But this revolutionary zeal focused more on the programs (the art for its own sake) and virtually neglected the point of programming: the models of the real world, the properties, and the events programs are simulating. Moreover, in retrospective we can see certain counter-revolutions: for example, the decline of analogue computers in favour of digital engineering. Recently, though, there has been a renaissance through the revival of principles of analogue modelling on modern digital computers (for example, the MathConnex environment included with Mathcad 7 and 8 Pro: see Appendix 7). It can similarly be seen in the technology of visual programming, where the former analogue control elements – adders, integrators etc. – are reconstructed.
But the virtual nature of these neo-analogue machines means also their strict determinism, and this brings not only positive, but also negative consequences. The principles of FST have been in programmers' hands for a long time – literally. The computer mouse reacts to two events: a click, and a double click. What, actually, is the difference one double click and two single? The duration of the pause between clicks. Expressed in non-technical language – "very short", "short", "long", etc.) this is a typical example of sets with 'fuzzy' borders. How much time is needed to increase a short pause to turn it into long, so that the double click breaks up into two single? How many handfuls of grain make a heap?


At the peak of the structural programming revolution, when in all the programming 'temples' the keyword GOTO was anathema, you frequently heard such statements as: "It's practically impossible to teach good programming to students originally taught BASIC; as potential programmers they're crippled intellectually, without hope of a cure." There were also broader warnings such as "Caution! Employment in programming is a dead end career. Don't think that having learned to program, you'll achieve anything in life".
It's as if traditional programming forces the programmer to look at the Technicolor world through monochrome glasses: a binary variable can take only two values (yes/no), and a real variable, values anywhere in a stipulated range strictly determined by the length of the mantissa. The truth lies somewhere between. The extreme points of view aren't useless – they are like book-ends that stop it sliding beyond defined extremes. The intermediate truths are termed 'fuzzy'. So one might say, "If you want to learn about the world (which is fuzzy, and unquantifiable) and to deal with it, beware of the traditional programming languages and mathematical programs with their strict determinism."
But we shall return to our problem of the fire bucket, and try to solve it using FST techniques and the opinions of people (who – thank goodness! – don't need such a rigmarole to use a simple device to escape being roasted).
Let's carry out an original poll and learn as much as we can about the parameters of an optimum fire bucket: its most convenient geometry (radius of the base of the cone to the height) and its optimum volume (the weight of the filled bucket). These can then be expressed as FST rules. How much water can you add to a bucket before it turns from light to heavy? How much can you increase or reduce the radius, or the height, of a bucket before it stops being convenient? These statements are typical definers of fuzzy sets. In the Mathcad environment, as well as in other popular packages, there are no variable types for storing such objects. But nevertheless we'll try to solve the given problem (see figures 6.41, 6.42, 6.43, 6.44 and 6.45 – a solution developed with B. Usyenko). Let's break it down into steps.





Fig. 6.41. Optimum radius of fire bucket
Step 1 (fig. 6.41). The matrix ?r stores people' s views about the optimum (most convenient) base radius r of a conical fire bucket, expressed in millimeters. This data could be gathered by making buckets of various geometries, giving them to people to try out, and then asking for estimates on a scale:
  • convenient (1);

  • more convenient than inconvenient (0.67);

  • more inconvenient than convenient (0.34);

  • inconvenient (0).

  • It would be possible to have more options within the range 0-1. In step 1 we have a limited familty of points, but these also could be increased; there are as many opinions as people. Readers can ask all their friends, and add new columns to the matrix [?r]
    Step 2. The survey data is processed by the least squares method (see Etude 4). We can see that the data approximately fits a normal distribution curve (see figs. 6.41 and 6.42). The idea of a 'membership function' ?r for the radius of the bucket is one of the basic concepts of FST. In normal mathematics it would be considered that a certain size either belongs, or does not belong, to a particular set; in FST it's permissible to say that the size belongs to the set to some extent
    (so many percent).
    Step 3. The statistical processing is completed and plotted.

    Fig. 6.42. Optimum height of a fire bucket
    Steps 4-6 (fig. 6.42) repeat steps 1-3, but for a second parameter of the bucket, its height.

    Fig. 6.43. Optimum volume of a fire bucket
    Steps 7-9 repeat steps 1-3 and 1-6 for the third important parameter of the bucket, its volume (or weight – they're proportional). This is based on human estimates:
    • bucket is light (1);

    • bucket is more light than heavy (0.67);

    • bucket is more heavy than light (0.34):

    • bucket is heavy (0).

    • The survey data is processed as before, but using a "one-sided" cumulative distribution curve (see item 9 in a fig 6.43). (When designing technical systems, such parameters wouldn't be based on a survey but on figures provided by experts to the decision-makers).



      Fig. 6.44. the "Rotated" optimum fire bucket
      Step 10 in fig. 6. 44 is the nucleus of the solution of our: in this, a two-parameter membership function is generated by the merging (akin to multiplication) of two single-parameter membership functions.
      In FST there are no traditional concepts of addition, subtraction, multiplication etc.(those represented by the mathematical operators "+", "-", "×" etc. in the Mathcad environment). In FST, multiplication (crossing of sets – logical AND) is replaced with an operation of searching for a minimum; and addition (merging of sets – logical OR) by searching for a maximum. The mathematics of precise sets is a special case (a subset of the mathematics of fuzzy sets) where these operators/functions are genuinely equivalent. This means that in the Mathcad environment, where there are no built- in AND and OR operators, we can create equivalents using the min and max functions we described in Etude 3.
      In our task the membership function mu_rh is generated by the fuzzy addition (min) of the functions mu_r, mu_h and mu_v. That is, the fuzzy set "the convenient bucket " is the intersection of three other fuzzy sets: "convenient radius of bucket" (step 1), "convenient height of bucket" (step 6) and "a not heavy bucket" (step 9).
      Step 11. The top of the 'mountain' – the surface plot of function mu_rh – is the point where the parameters of most convenient fire bucket lie.

      Fig. 6.45. Designing the optimum fire bucket
      Step 12 (fig. 6.45). Searching for the maximum of the function mu_rh in the Mathcad environment can be done in various ways (see Etudes 2 and 3). We'll proceed this way: we'll imagine metal disks of various radius R (from 10mm-500 mm with a step of 1 mm) and cut each size into 2 to 10 identical buckets. This gives a large variety of bucket sizes and geometries, and we'll consider the optimum (the most convenient) bucket to be the one for which the membership function mu_rh is maximised.


      Even the reader who hasn' t been paying much attention will notice some discrepancies and simpiflications in our analysis of this task. Three of them are:
      • Unlike our theoretical bucket, a real one is never filled up right to the brim ("what counts as full?" defines another fuzzy set).

      • The author has only loosely defined, and often confused, such concepts as "volume", "weight", and "weight of bucket".

      • We haven't taken into account the weight of an empty bucket, and also the material from which it is made.

      • However it is merely necessary to glance again at the diagrams illustrating fuzzy sets in figs. 6.41, 6.42 and 6.43
        to understand a major virtue of applying FST to decision-making tasks. Our solution works in isolation, so it's possible to express the essence of a task disregarding various minor variables: the density of water, weight of the empty bucket, degree of filling, etc. This feature is now realized, for example, in automatic control systems, where regulators based on FST rules are more 'attentive' to the basic signal and less susceptible to noise. It turns out, though it seems paradoxical, that the traditional 'precise' control algorithms qualitatively lose out to 'fuzzy' ones, or are their special cases. In the field of automatic control theory, a certain stagnation could be seen until recently, as any new algorithms couldn't be compared to the older Proportional Integral Derivative (PID) control algorithm. The principles of PID control can be seen in the procedure for a bank's credit check on a client applying for a loan. The banker, in assessing the decision, considers:
        1)      The sum of money in the client's account (this is the proportional component: the richer the client, the larger the loan that can be offered);
        2)      The average sum in the account over, say, the last five years (the integrated component; checking this ensures that the client didn't borrow a million pounds the day before, to create the illusion of solvency); and


        3)      The rate of change of the account (the differential component, showing whether the client's business is on the rise or decline);
        It's possible to take into account other factors, but three is a nice number!
        The PID-control algorithm has imperceptibly become something of a fetish. Fuzzy management cames as a fresh breeze in the theory of automatic control, whose basic rules are now open to review. To be sure, there are other opinions. Some scientists believe that the use of FST in automatic control, and cybernetics in general, is just replacing one uncertainty with another ("trying to stitch soapsuds", the Russian expression goes) and that's all there is to it. Sceptics explain away the observed improvement in control quality to our devoting more attention to regulator technology (as if the ritual of attention could improve performance). Besides some researchers believe that FST, since it dates back 30 years (it was devised by the Iranian-American Dr Lotfi Zadeh at UC/Berkeley in the 1960s) is old and best forgotten.
        Actually, the skip from a task about a tripartite duel to one about an optimum bucket wasn't entirely casual. Traditionally, precise sets are illustrated by circles with sharply delineated borders. Fuzzy sets are drawn as circles formed of separate dots, with a high density at the centre and thinning to zero (as if evaporating) towards the edges. Such 'fuzzy set' images can be seen on a firing range wall where targets are hung. The bullet traces form a probability distribution, whose mathematics is well-known. It appears that the theory for working on fuzzy sets, as probabilistic distributions, has already existed for a long time...
        We keep talking about fuzzy sets. But are they – mathematically – actually sets? To be consistent, it's necessary to ascertain that the fuzzy set has elements (fuzzy subsets, fuzzy sub-subsets, etc). We'll return to a classical example: a heap of grain. An element of this fuzzy set will be, say, a million grains. But a million grains is not a precise element: it's a fuzzy subset. If you count out grains, whether manually or automatically), it's no wonder that you might mistake, say, 999 997 grains for a million. In FST terminology, you could say that the element 999 997 has a 'membership value' 0.999997 for the fuzzy set {a million grains}. Besides, even "a grain" is not a precise element, and is another fuzzy subset: it might be a high-grade grain, but there are also underdeveloped grains, grain fragments, and bits of husk. Depending which way you decide, you might count one grain as two, or vice versa.


        The fuzzy set isn' t very easily accommodated in the digital computer with classical data constructs: elements of a file (a vector) should be new files of files (composed of vectors and matrices, in the case of Mathcad). The classical mathematics of precise sets (number theory, arithmetic, etc) is rather like a hook, with the help of which we anchor ourselves on the slippery and fuzzy environmental world. And a hook is a rough implement, quite often damaging what it's embedded in. The terms describing fuzzy set membership values (there are plenty in this book and others – "much", "some", "a few", and so on) are difficult to make into programming statements because they're contextually dependent. It's one business to say, "Give me a few sunflower seeds" to someone with a cupful, and another to say the same to a driver hauling a lorryload.
        Whether it is possible to see a certain crisis in theory and practice of programming connected with contradict between precise structure of the programs (data) and fuzzy world? Is it necessary to develop fuzzy programming languages for implementation fuzzy algorithms that accommodate fuzzy data? Opinions vary. In the author's view, programmers (and they have the last word) have learned poorly how to cram the fuzzy world into the strictly determined computer. Figs. 6.41, 6.42, 6.43, 6.44
        and 6.45 are an example.

        Ñîäåðæàíèå ðàçäåëà