My first idea was just to repeat this example. Before I started I made a short analysis of the topic “calculator” discovering some interesting points. Using calculators I imagined that something like a standard user interface existed. I have been sometimes confused when getting into my hands a new calculator whose behavior is different to other ones. Anyway, I never worried much about this as my interest is limited to very simple operations. If my calculations are a bit longer or more complex I use spreadsheets.

Let’s then define the calculator to be designed. The simplest calculator possesses the keys:

• to define the operands: digits (0..9), number sign (±) and decimal point (.)

• to define the operations: add (+), subtract (-), multiply (*), divide (/), equals (=)

It has a display to show the operand typed in and the calculation result.

The few calculators I had at hand are similar but the use of the keys is not standardized:

• the role of keys C and CE are interchanged; sometimes they get other names

• the equals key (=) allows sometimes the calculation to be continued

• the continuation of calculation after termination may be done using operation keys +-*/

The calculation scheme of Samek’s example adheres to the standard one: an actuation of an operation key (+-*/) is unique and defines the next operation, the following actuation of operation keys are ignored and the calculator awaits the operand. The limitation has been introduced to show that in such a case it is possible to use the key “-” in a double role: as an operation key (subtract) and as a sign of the operand. The other simplification is the priority of operations: they are performed in the sequence in which they are entered, let’s call it the “arithmetic for dummies”. It means that typing “1+2*3=” you get 9 instead of the expected 7. Maybe for people who terminated their education in the first class of the grammar school such calculations make sense but most of us respect the usual priority of arithmetic operations and such calculator would be rather useless for them. Imagine you want to calculate your shopping expenses: a piece of butter, 4 bottles of beer, 3 bars of chocolate, etc; no chances to do it with such a calculator (unless it has an add-to-memory feature of course). You find this kind of arithmetic in “simple” calculators. A curiosity of the Windows calculator is that in the Standard mode uses the “arithmetic for dummies” and if you switch to the Scientific mode it uses the arithmetic priority rules. Strange, the use of normal arithmetic is considered as a scientific approach! This limitation in the Samek example is obvious: to make the example as simple as possible, otherwise it will be too difficult. This is a artificial example, used to explain how to use statecharts in UML design. Obviously, UML statecharts does not work for any more practical problem.

As we prefer to work with examples taken from practice I had to decide which calculator from the few ones on my table and screen should be emulated. Eventually, I decided to design the calculator similar to one found on any computer running Windows.

Playing a little bit with this calculator I have found it has rather strange behavior in some situations. It is fairly easy to get the calculator to produce random results without any indication that the only way out is to reset it using the key “C”. For instance, trying “2/0+” you get expected “Cannot divide by 0″ but continuing with keys “CE” and “=” you get 10 (!). Maybe it is the code number of the software bug! Typing “2/0”= you get the same expected “Cannot divide by 0″ but continuing with keys “CE” and any new operand the calculator is in a loop generating “Cannot divide by 0″ which is in a way better. Of course the only solution is again the reset with the key “C”. Another example: “5+9/=” produces 10 which corresponds to “5+=” the pretended algorithm of using equals key “=”. But typing “5+9/CE=” produces an error message “Cannot divide by 0” (i.e. the clear key introduces 0 as an operand!). And now try “5+9/0=CE” and you get 100!

The calculator has another problems with unexpected sequences of operation keys. For instance, if you type “2+7*=” you get 4 (in Scientific mode). The Windows calculator manifests also a specific behavior after terminating the calculation with the equals key “=”. Repeating the key “=” performs the last operation using the result and the last operand; effectively it is the cash register function which is done normally using the key “+”. But if you change the operation and continue with the key “=” it continues using in the first step the last result as both operands. No idea what is this function for. I could not find any explanation of the described (faulty?) behavior in the voluminous Help which describes many obvious topics but does not explain how the calculator is to behave in the above described situations. In this situation the calculator ignores also entered numbers without informing the user about it. So if you type for instance”1+2=” you get 3. Entering then “4=” you get 5 which is OK in relation to the cash registration function but is confusing for the user who entered 4 having something else in mind. Investigating more carefully the behavior after entering the key “=” you will find also an algorithm that explains the strange result of previously shown operation “2+7*=”. This algorithm says: forget the last operator and operand and perform the cashier function. This might explain the behavior but what is this functionality for? Of course, the results in examples discussed in this section are different for Scientific and Standard modes. A possible use for this feature is to calculate compound interest: try 1.06 * = = = = = ; each = shows the effect of an extra 6% compound interest.

The calculator seems also to have difficulties with operation on and presentation of floating point numbers. By typing the sequence “9- sqrt =” you get 6 (as expected). By repeating the Equal sign you expect to get values decreasing by 3. It works but the 0 value is not correctly displayed. Namely the results are: 3, -3,46391…e-37, -3, -6, etc. I have not investigated this problem further as the numerical computation is not my favorite topic but it is a rather strange effect.

To get a more complete picture I have taken another calculator that I have in my drawer and repeated the same exercises getting different results but also partly erroneous!

I have to admit that after that experience I was a bit shocked. I have been convinced that a calculator is a mature product delivering correct results, not only for operations like 2+2. Obviously the software in these tested examples fails in “unexpected” situations. It is more or less a known problem in software implemented according to “use cases”, where the adequacy of the set of “cases” is left to the good will, time and ability of programmers.

After that introductory work I decided to take the problem seriously and design it with StateWORKS. I have been convinced that it is possible to get a calculator which behaves as required in all situations. I will present it in few steps. You find the discussion in the Case study section in a document “Calculator”.

]]> http://www.stateworks.net/2009/08/calculator/feed/ 1 http://www.stateworks.net/2008/03/what-is-a-state-machine/ http://www.stateworks.net/2008/03/what-is-a-state-machine/#comments Mon, 03 Mar 2008 06:00:00 +0000 Ferdinand Wagner http://stateworksnet.cmarc.net/2008/03/what-is-a-state-machine/ Our web site contains several technical notes and papers that discuss some aspects of software engineering associated with the concept of a finite state machine. On introducing our blog we have decided to present you a few topics covered by a group of our documents. We started with the Mealy and Moore models of a finite state machine, honoring the fact that it is a favorite topic according to visitors’ statistics. The topic that we would like to present you today is “What is a state machine”.

The concept of a state machine is old; its definition belongs to the basics of Automata Theory. In principle it seems to be a simple definition and requires understanding of the “state” concept. In spite of its simplicity the concept has been deformed, corrupted, misunderstood and up now the well known misunderstandings about a state machine result in a relatively modest use of the state machine idea in the specification and design of software. In our publications we try to indicate that a state machine is so well defined (see for instance the book or the technical note and the the already mentioned document about Moore and Mealy models) that it does not require re-definitions or (mis-)interpretations, especially that:
- a flow chart is not a state machine
- a Petri net is not a state machine
- a statechart is not a state machine
- there is no need to define an incomplete state machine under a new name (see for instance the technical note)
- it is possible to create a complex control system modeled by a system of state machines
to name only some topics discussed in our documents.
We are convinced that the concept of a finite state machine is one of the strongest ideas in the world of modelling control tasks in general and specifically in the design of a software control flow. A typical implementation of software control flow using the if-then-else and switch like mechanisms supported by numerous flags is a primitive style of development difficult to understand and accept in the 21 century.

Mealy and Moore models are the basic models of state machines. A state machine which uses only Entry Actions, so that its output depends on the state, is called a Moore model. A state machine which uses only Input Actions, so that the output depends on the state and also on inputs, is called a Mealy model. The models selected will influence a design but there are no general indications as to which model is better. Choice of a model depends on the application, execution means (for instance, hardware systems are usually best realized as Moore models) and personal preferences of a designer or programmer. In practice, mixed models are often used with several action types.