Some thoughts here about "modes" and why it is not really a good thing on a calculating machine of that caliber. (I use 0.999945.... here just because I am too lazy to write all digits each time.)

When doing mathematics one does not first set the brain to some "exact" or "approximate" mode. We just use the right symbols. A mathematical assertion is clear and unambiguous not because of setting modes but because of the strict language it uses. (Even its inconsistencies are clear. ;-)) This language is made of symbols like numbers, letters, indices, operators, etc. (And we try to keep clarity along with strictness using the least possible concepts and the lest possible symbols.) For example, one could write Det(AM1)=1 or Det(AM1)≈0.999945.... but never Det(AM1)=0.999945..... since the determinant of AM1 is *not* equal to 0.999945.... It is only *approximately* equal to 0.999945.... , which is expressed using ≈ and not = .

The above example, translated to the language of the HP50G would mean that the statement Det(AM1)=0.999945..... is true under the additional premise of approximate mode. In this case using approximate mode is like writing the symbol "≈" . So one could also say that the mathematical symbol "≈" is available on the machine by using approximate mode.

But: As we see here and in so many other examples the usage of modes is anything but clear. The result of the operations in this example can imply that Det(AM1) *is* actually 0.999945..... , and then additional consideration of the state of flag -54 corrects the statement to "Det(AM1) is approximately 0.999945.....". In this case it not so difficult for the user to keep in mind the states of the related flags, but in many many other examples one has to remember many more things that are valid implicitly. In other words the explicitness of the statement is lost. Compare for example the explicit clarity of statements like:

Det(AM1)=1

or

Det(AM1)≈0.999945....

with the implicit clarity of:

Det(AM1)=0.999945.... | approximate mode and usage of tiny elements

where the part "| approximate mode and usage of tiny elements" is not explicitly written but kept as a setting under the numerous modes of the machine.

To make it even more complicated just multiply some numder of AM1 with the variable X and retry the cases in my last message. A completely different behavior just because of the presence of a variable in the matrix.

It seems that the concept of modes was OK for machines with limited RAM that offered some few flags for angles or number representations, but I doubt that this concept is a good choice for a CAS with much RAM. There are many too many things for the user to be aware of, and this makes lowers unnecesserily the clarity. The part "| approximate mode and usage of tiny elements" is simply the symbol "≈" - not really an economic translation, is it? And also not quite obvious when there is no kind of announciator for usage or not of tiny elements. And even less obvious when it is not visible anywhere in the machine what actually "tiny" means, but that's a very long story. (The explanation about "tiny" in the manual is only a tiny part of this long story, which can be used against this statement too. ;-)) And even less less obvious when we take symbolic variables in the matrix. And, and and....

All the above is of course more of an issue about user friendliness through consistency, but there is also a second but: Using so many flags and modes and states introduces hidden dangers against consistency due to unexpected interferences. To make it even worse, the different types of operations like commands, operations, functions, analytic functions, programms etc., the behavior of which is influenced by the modes, don't really help to avoid confusion. Just consider the several representations of a complex number on the HP50G in combination with all the relevant modes under usage of the power function. You will get a lot of possible sub-cases and a lot of possible different results for one and the same mathematical thing, namely (a,b)^c. In many of these cases the result is absolutely correct but in many others of these cases the result is at least not easily understanable. It is not right and it is not wrong and it is both at the same time.

The above is much like the Toolbox of the Mac before OS X. Thousands of functions doing the same thing a bit different - sometimes so, sometimes the other way around, according to "modes". Nobody could manage it consistently anymore and so it started showing severe inconsistencies that were not avoidable. And so the only right decision was to through it away and start from scratch for something else. This brought us OS X. Much more consistent and with much less hidden dangers that can evolve to catastrophes. (I wonder how long it will take until it starts declining under its own growing weight.)

So,

a) just consider the HP50G in exact mode and enter 1 1 + . The result is 2, so it is OK.

b) Now switch to approx mode and enter 1 1 + . The result is 2. since entering the two 1s (without the decimal point) converted them both to 1. For me it is also OK.

c) Now switch to exact mode, enter 1 1, then switch to approx mod and press +. You get 2, an integer and not a real though you are in approx mode. Let's accept that as a consistent result because we are operating with integers, and let's say that integer results should be obtained when integer arguments are used - no matter of mode.

d) But now switch to exact mode, enter 0 1 'X' 'X', then switch to approx mode and integrate. You get 0.5 and not 1/2. Hmm... is that consistent when we have accepted (c)???

You see where it goes to.

Ciao.