Глава 6.9.6. A genuinely optimum fire bucket - часть 3

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.

Содержание  Назад  Вперед