Search
Mistral EC
Mistral USA
Forty years ago, when Mistral set out to achieve what everyone and their cousin insisted was impossible, we faced a dilemma.
There is no point in publishing computer programs, intended to be used for designing engineering projects valued from a few hundred up to multi-million Dollars/Pounds, if they are right only 99.999% of the time. They had to be 100% accurate 100% of the time. Following five ball busting years of intensive R & D, consulting and recruiting the help of some of the acknowledged best brains in our industry, along with countless sleepless nights, Mistral proved all its dissenters to be totally wrong.
Why so difficult to introduce what in computer programming parlance is 'Error Trapping'? The systems by which the computer program, that is the 'software', detects that a user is asleep at the wheel and makes a mistake. By entering an erroneous figure or selects an incompatible item from a multiple choice selection menu. The difficulty stems from making that Error Trapping 'dynamic'. In other words to constantly adapt, in real time, as a project design is evolving.
Let's start by making this simple. A clever Polish mathematician, we believe was Emil Leon Post (1897-1954) but stand to be corrected, or Post may have been just one of a few, worked out that with just 7 single and double figure integers it was possible to identify the precise geographic location, age and gender of every living person on Planet Earth.
Add an eighth integer and it would be possible to locate every grain of sand on the planet, including its chemical composition, mass and depth.
With our programs, in some cases we were facing having to present up to forty or so questions, let's call them 'variables' in front of the operator. Let's even call many of these variables integers, before the software could completely compute a sought after solution. Forty inputs, for all intents and purposes is capable of isolating and identifying everything, past and present in the entire universe. Infinity then, for all practical definitions. If you don't believe us then try it. With just one single item, let alone billions of elements, mixtures, compounds, gases, solids and liquids.
Place a single grain of rice on the first square of a chess board. Double that, that is place two on the next square. Continue doing that, simply doubling the quantity on each successive square. Until you have covered all 64 squares.
Take a guess as to how much rice you have at the end of the exercise. A barrel load? A truck load? A train load? No. You would have enough rice to cover China a metre or more deep. Good luck trying to prove us wrong!
Another minor problem creeps in. Computer programs generally comprise questions demanding input or answers. Program operators are often instructed to input answers to questions in a successive list. At least in a succession of questions in the most simplistic and naïve of computer programs. Fine. Except what counts as a viable answer? Asking an engineer to identify what temperature or quantity of a contributory component they wish to use as a starting point is all very well. Except in the absence of any input the program will use what it already can 'see' and thus 'read'. A fundamental flaw in computer architecture is that a question (or variable) awaiting input and which hasn't yet been provided sees 'null', that is 'nothing' and interprets this as 0 (zero). Big mistake. Easy enough for a programmer to set a question and apply limits as to acceptable answers, say from +50 degrees Celsius down to -40 degrees Celsius. But 0 degrees Celsius is a viable 'number'. 0 Celsius is lower than 1 Celsius and higher than -1 Celsius, but it is a viable number nonetheless (other than when a divisor). So a user forgets or omits to enter the figure they require to use for their project and the program merrily continues, 'assuming' that 0 Celsius is what is required for example. There are hundreds even thousands more of similar situations to this example.
Earlier in this discourse it is stated that many, indeed most computer programs are simplistic, naïve successions of inputs, collected from the program user or operator, who, having completed all inputs finally hits a key or button instructing the program to commence computing, so as to come up with a result. Fairly basic stuff and frankly not all that useful. Not much of an improvement over using a pocket calculator along with a library of reference tables and a slide rule. What if the operator wants to trace back through their list of thirty or forty inputs and edit, that is change just one single input? A problem here is that in basic 'error trapping' this does not take account of the fact that changing a single input could have, inevitably does have, implications upon other inputs and which both preceded and succeeded the edit change. In other words, inputs more often than not define the acceptable range, that is the upper and lower limits of other inputs. Result? Disaster! The sort of thing which AI comes up with and as far as we can see AI always will. Sobering if AI is being used to navigate or even pilot an Airbus A380 airliner with three hundred happy tourists admiring the view of the Alps 20,000 feet below! Or is that 2,000 feet below? And don't say there are other check systems onboard aircraft and such a thing couldn't happen. It already has happened, more than once. Ask Boeing.
To make things even more complicated for ourselves, all Mistral programs, ulike the plethora of amateur 'Linear' progression software, run in 'Parallel mode'. Meaning that input can be entered in any order, including even edits. While programs suggest which might be the most logical order the suggested order can be safely ignored. To put this into context please think on this for one moment. A perhaps macabre analogy but highly illustrative for all that.
Clearly a solution to this conundrum was required and the solution was relatively simple. Mistral intentionally pre-loads and introduces chaos into all its tens of thousands of available input fields, before a user or operator has even got beyond their first input. The clever part being Mistral knew what chaos it had introduced and thus built in the automatic arithmetic antidotes. The panacea. Similar to Fuzzy Logic. Whatever, Mistral invented it!
In forty years and literally billions of calculation results, involving estimated trillions of Dollar/Pounds, across practically every civilised country in the world, to say nothing of human lives dependent upon critical safety standards exposing them to ultra high pressure, volatile and poisonous exotic gasses, and finally of course trillions of kilowatts of electrical power saved (enough to make any hysterical, unqualified, truant schoolgirl weep for evermore), Mistral has never been proven to supply an erroneous result. Trust us, Mistral has faced challengers, because saving energy is big business these days. But Mistral has never been beaten. The food you, and your clients, and their customers safely ate today, yesterday and tomorrow is also a testament to that.
Beat that ChatGPT.
Bringing benefits of computerisation to our RAC industry - without the commonly associated problems.
More reading:- Dynamic Error Trapping.
Close and return to previous page