Method and Apparatus for Computing With Terms Having Units

This inventions relates to method and apparatus for carrying out mathematical computations, such as with computers and calculating devices. More particularly, this invention relates to carrying out mathematical computations with terms that include a scalar part and a unit part such as length, mass, time, etc.

Mathematical computations often involve physical terms that have units such as a length, a temperature, a voltage, etc. In the process of carrying out a computation with multiple terms, units may be converted to a dimensionally consistent unit, such as inches to feet, or cancelled if the same unit appears in both the numerator and denominator of the final result. Conventional calculating devices such as calculators and computers are not equipped to manage physical units in mathematical computations. The manipulation of physical units is typically limited to providing conversion factors for converting a scalar associated with one type of unit to a scalar associated with another type of unit, such as converting 18 inches to 1.5 feet.

Mathematical computations involving physical units are thus split into two steps. First, one must write out the computations manually, usually with pencil and paper, and then resolve the units using conversion factors. Then a calculating device is used to perform the numerical calculations and the conversions. This two-step method is not only slow but is also prone to error. In attempting to resolve the units one can mistakenly combine dimensionally inconsistent units, such as inches and gallons, and not catch the error.

An object of the invention, therefore, is to provide an improved method of performing mathematical computations with terms having units which overcomes the drawbacks of prior methods.

A second object of the invention is to provide a calculating environment in which physically dimensioned quantities can be computed with the same operations and logic as scalar quantities.

A third object of the invention is to provide such a calculating environment in which dimensional consistency is automatically checked and maintained.

A fourth object of the invention is to provide a means for combining a scalar with a unit to create a single entity that may be used as a term in mathematical computations.

In accordance with these objects, a method in a calculating device of managing units in mathematical computation includes associating a scalar entry and a unit entry. In the present embodiment, they are combined to create a unit object having a scalar part and a unit part. In the present embodiment, the unit object is created from a character string entered into a calculating device. Syntactic elements of a unit object are identified within the character string, and a constituent object representing each syntactic element is provided in memory of the calculating device. The unit object is then created from the constituent objects.

In mathematical computation such as addition or multiplication, each unit object is first disassembled into its scalar part and unit part. A new scalar part is then calculated according to the computation from the scalar part of each unit object operand. A new unit part is also calculated according to the computation from the unit part of each unit object operand. The new scalar part and new unit part are then combined to create a new unit object representing the results of the computation.

To simplify computation with unit objects, a user interface for the calculating device may be provided. Creating a unit object then comprises entering a scalar part into a calculating device; displaying a units menu wherein each entry represents a type of unit; displaying a submenu of related units of a type selected from the units menu; and combining, in response to selection of a related unit, the entered scalar part with the selected related unit to complete the unit object.

The foregoing and other objects, features, and advantages of the invention will become more apparent from the following detailed description of a preferred embodiment which proceeds with reference to the accompanying drawings.

FIG. 1 is a pictorial view of a calculator as one embodiment of apparatus programmed according to the invention.

FIG. 2 is a block diagram of the architecture of the calculator of FIG. 1.

FIG. 3 is a flowchart of a method for creating a unit object.

FIG. 4 is a flowchart of a method for multiplying two unit objects together.

FIG. 5 is a flowchart of a method for dividing one unit object by another.

FIG. 6 is a flowchart of a method for collecting and cancelling like terms from the numerator and denominator of unit sequences.

FIG. 7 is a flowchart of a method for adding/subtracting two unit objects.

FIGS. 8A and 8B are illustrations of a user interface that appears on the display screen of the calculator of FIG. 1 for choosing units via menu keys.

FIG. 9 is a flowchart of the unit menu key logic for selecting a unit for a unit object.

FIG. 10 is a series of screen displays showing the multiplication and division of unit objects.

FIG. 11 is a series of screen displays showing the addition of two unit objects.

FIG. 12 is a series of screen displays showing a the conversion of a unit object from one unit to another dimensionally consistent unit that is predefined.

FIG. 13 is a series of screen displays showing the conversion of a unit object from one unit to another dimensionally consistent unit that is not predefined.

The following description is given in the context of a calculating device such as a calculator or computer. However, it will be appreciated by those skilled in the art that the invention to be described may be employed wherever it is desirable to perform mathematical computations with terms that have physical units.

The invention employs a data entity referred to hereafter as a "unit object," which has a scalar part and a unit part. For example the term "3.sub.-- ft" is a unit object. The units may be of any type recognizable by the calculating device, such as predefined base units or user-defined additions to the base collection. Unit objects are entered and displayed in the format "number.sub.-- units", where "number" is an ordinary real number and "units" is an algebraic expression containing unit names and one or more of the symbols *, /, , (, ). Predefined and user-defined unit names may be prefixed with letters to indicate powers of ten, such as "m" for milli and "p" for pico. Ambiguities between predefined units and units created with a prefix and a unit are resolved in favor of predefined units (e.g. "min" is minute, not milli-inch).

FIG. 1 shows a calculator 20 which is programmed to manage units in mathematical computations according to the invention. The hardware and architecture of the calculator 20 (shown in FIG. 2) may be of conventional design. The calculator includes an entry means such as a keyboard 22 and a display means such as an LCD display 24. On the face of the keyboard are a plurality of keys that each have a number of functions. Relevant to the present invention are several of the keys that have unique functions. A UNITS key 26 is used for activating a units menu in a shifted operation. The shift is accomplished by first pressing the left shift key 28. Other keys of note include a right shift key 30, a NXT key 32, and a row of menu keys 34. In response to activating the units menu, the menu keys are assigned to labels 36 that appear at the bottom of display 24, as will be further described hereafter.

The architecture of calculator 20 includes a central processing unit (CPU) 38 to which are connected via various buses the keyboard 22, the display 24 and memory in the form of ROM 42 and RAM 44. The instructions for operating the CPU are written and stored in the ROM 42 in a conventional manner. The RAM 44 is available for storing data entered via the keyboard 22 and generated by the CPU 38 in the process of manipulating units according to the invention.

Of course, any equivalent calculating device may be used, such as a general purpose computer. Equivalent to the keyboard would be any data entry device such as a mouse. Equivalent to the LCD display would be any type of display device such as a CRT, hard copy device, etc.

In the present embodiment, a unit management program stored in the ROM 42 employs a data stack in the RAM 44 on which a multiplicity of data types can be placed. The program implements a unit object as a data-class composite object, containing atomic objects of several types representing the syntactic elements of the unit object. Operations pop their operands off the top of the data stack and return their results to the top of the data stack.

Referring to FIG. 3, a unit object parser 45 within the unit management program takes a string representation of a unit object entered by a user via the keyboard 22 and creates a unit object from it. In the process, the parser identifies the syntactic elements of a unit object and pushes atomic objects representing these syntactic elements onto the stack. Table I, below, shows the syntactic elements of a unit object that are detected by the parser and their atomic object representation on the data stack:

The stack items umEND, um/, um*, um and umP are distinct pointers used by the unit management program. The stack items scalar % and exponent % represent real (floating point) objects containing the values of the scalar and exponent, respectively. The stack item prefixC represents a character object containing the prefix character. The stack item unit$ represents a string object containing the unit symbol.

FIG. 3 illustrates the steps taken by the parser 45 in creating unit objects, with each step indicated herein by a numeral in parentheses. The parser first gets the character string to be parsed, such as "3.sub.-- ft", entered via the keyboard 22 (46). It then identifies the syntactic elements of a unit object from the character string (48). The parser then pushes atomic objects representing the syntactic elements onto the data stack (50). It finishes by creating a data-class composite object containing the constituent atomic objects and replacing these constituent objects on the stack with the newly constructed composite object, a unit object (52).

The following examples illustrate the structure of a unit object. In these examples the unit object is listed as its atomic constituents enclosed in matching double colon (::) and semicolon (;). String objects are enclosed in double quotes (") and character objects are encoded in single quotes. (`).

The unit management program distinguishes between a unit object and a general data-class composite object by the pointer umEND positioned at the end of the unit object.

Unit management operations such as those described in the following sections receive their operands from and return their results to the data stack. Some of these operations need to manipulate the atomic constituents of one or more unit object operands. To do this, such an operation replaces a unit object operand by its constituent atomic objects and a trailing integer count serving as a delimiter of the atomic objects within a single unit object. After manipulating the atomic constituents, the operation then collects the remaining objects into a resultant unit object. Some operations accept both real and unit objects as operands. When both types of operands are present, these operations interpret a real operand as a unit object operand with the unit "1".

The method of managing units in a mathematical computation thus comprises the following steps. A user enters a character string into calculator 20 combining a scalar part and a unit part to create a unit object having a scalar part and a unit part. This may be repeated several times until the unit objects for the computation are created, such as the addition of two terms. Each unit object employed in the mathematical computation is then disassembled into its scalar part and unit part. The unit management program then calculates in accordance with the computation a new scalar part from the scalar part of each object. Similarly, the program calculates in accordance with the computation a new unit part from the unit part of each object. The unit management program then combines the new scalar part and new unit part to create a new unit object representing the results of the computation.

The detailed steps of the method for various computations are described below.

A unit management operation (labeled EXTN in the present embodiment) creates a composite object from objects on the data stack by popping the first item from the stack, which is assumed to be an integer count N, popping the next N items, copying those N items into a data-class composite object, and pushing the newly created composite object to the stack. The unit management program uses this operation to construct a unit object from its atomic constituents by pushing an item count and then calling EXTN.

A unit management operation (labeled INNERCOMP in the present embodiment) replaces a unit object lying on the top of the data stack by its constituent object elements, followed by an integer count of the number of the constituent elements. The unit management program uses INNERCOMP to disassemble a unit object into its atomic constituents when that act is required.

The following sequence illustrates how a unit object is first destroyed, then recreated, using INNERCOMP and EXTN:

A unit management operation UM* multiplies two unit objects and returns a unit object product. Another operation UM/ divides two unit objects and returns a unit object quotient. These operations, to be described below, employ a structure known as a unit sequence.

The unit sequence of a unit object consists of the sequence of atomic elements of the object representing the unit part of that object, followed by an integer count of the number of those atomic elements. The unit sequence thus contains all of the atomic elements of the unit object except for the scalar real object and the pointer umEND. The following examples illustrate various unit sequences:

To simplify the computation, the unit part's numerator and denominator are manipulated separately during unit object multiplication and division. To do this, UM* and UM/ separate a unit sequence into numerator and denominator unit sequences, dropping the pointer um/. If a unit part does not have a denominator, the empty unit sequence, consisting of only the integer 0 is used. The following examples illustrate how a unit sequence is split into its numerator and denominator unit sequences:

To aid in the readability of data stack notation, the unit sequence stack notation is the sequence of items enclosed in square brackets ([]), omitting the integer count. For clarity, the sequence of items between brackets is replaced by a descriptive name. An empty unit sequence is represented by empty brackets, such as in the following examples:

FIGS. 4 and 5 illustrate the method used by unit management operations UM* and UM/. Table II, below, includes internal procedures used by these two unit management operations:

Referring to FIG. 4, the multiplication operation is illustrated. With the two unit objects entered as operands, the scalar product is first computed (54) and the result is stored as an atomic object on the data stack. The numerator and denominator unit sequences are obtained from each unit object (56). The product's raw numerator and denominator sequences are computed (58). Units common to both the numerator and denominator sequences are collected and canceled (60) to reduce the sequences. To obtain the product's unit sequence, the numerator unit sequence is divided by the denominator unit sequence and then stored on the stack (62). The product unit object is then constructed from its scalar and unit sequence (64).

The division operation, illustrated in FIG. 5, is similar. The scalar quotient is computed from the scalar parts of the two unit object operands (66). The numerator and denominator unit sequences are obtained from each unit object (68). The quotient's raw numerator and denominator sequences are computed (70). Units common to both the numerator and denominator sequences are collected and cancelled (72) to reduce the sequences. To obtain the quotient's unit sequence, the numerator unit sequence is divided by the denominator unit sequence (74). The quotient unit object is then constructed from its scalar and unit sequence (76).

A base unit is either a predefined unit or a user-defined unit. It is desirable when multiplying or dividing units to collect together base units appearing in common in the numerator or the denominator unit expression, and to cancel base units appearing in both the numerator and denominator unit expressions. This improves the readability of the unit expression. For example:

The internal procedure CCUnits collects and cancels matching base units having common prefixes between a numerator and a denominator unit sequence.

A triple consists of three atomic elements corresponding to a prefix, base unit, and exponent. A special multiple sequence such as a triple sequence is a sequence of triples followed by a sequence count that corresponds to a numerator or denominator unit sequence. Each base unit in the unit sequence is represented in the triple sequence by its prefix character, base unit string, and exponent real objects found in the unit sequence. The sequence of these objects in the triple sequence is the same as that in the unit sequence. If a base unit has no prefix, a null string object is used in place of a prefix character object. If a base unit has no exponent a real number object, having the value one is used as its exponent. The other objects in the unit sequence (umP, um , um*) are omitted. The stack notation for a triple sequence is similar to that for a unit sequence. For example:

Two triples match if they have equal prefix character and base unit string objects. A triple is distinct in a sequence if no other triple in the sequence matches it.

CCUnits first transforms its numerator and denominator unit sequences into triple sequences, collects and cancels matching triples within these triple sequences, and then transforms the resulting triples into unit sequences.

FIG. 6 summarizes the method used by CCUnits. Table III, below, includes internal procedures used by this unit management operation:

FIG. 6 illustrates the steps for collecting and cancelling like units. The numerator and denominator unit sequences are first transformed into triple sequences and matching triples are collected (78). Matching triples from the numerator and denominator sequences are cancelled (80). The numerator and denominator sequences are then transformed into numerator and denominator unit sequences (82).

Many arithmetic operations in mathematical computation require that the units of each operand or term be dimensionally consistent. For example, three feet cannot be added to, subtracted from or compared meaningfully to three gallons. To check for dimensional consistency, a unit table is maintained internally for each unit. Each table entry includes the unit name, conversion factor to SI units, and quantity data that defines the base unit types comprising that unit. The table is organized such that unit names with the same length are grouped together for faster access.

The quantity data with the unit table provides for checking dimensional consistency. For example, to verify that gallons can be converted to acre*ft, the quantity data for each unit must be compared. Gallons is a volume unit, and volume is derived from three length units multiplied together. Acre*ft is the product of an area and a length. Since an area is the product of two lengths, acre*ft represents a three-length unit, and is therefore consistent with any other volume unit, including gallons.

FIG. 7 illustrates a method performing such arithmetic operations while checking for the dimensional consistency of the units or each object. Although the flowchart describes addition/subtraction, similar steps are employed for performing object comparisons such as %CH, %T, =, ==, <, >, >=, <=, etc. In the present embodiment, unit objects entered into the calculator 20 are stored in memory registers that are represented on the display 24 as levels 1-4. Each time an entry is made, the previously entered objects are moved to a higher level, such as from level 1 to level 2 in FIG. 1. The order of entry determines the unit dimension of the result, which matches those of the latest (level 1) entry. In the first step, the level 2 unit object is converted to the units of the level 1 unit object, if possible (84). Dimensional consistency is determined by comparing quantity data for the level 2 unit object against quantity data for the level 1 unit object (86). If the units are inconsistent in dimension, then the operation aborts and an error signal is flashed on the display 24 (88). If the quantity data match, the scalar part of the level 2 unit object is multiplied by an appropriate conversion factor and then added to the scalar part of the level 1 unit object to produce a scalar sum (90). The scalar sum is then combined with the unit from the level 1 object to create the resultant unit object (92).

The steps in FIG. 7 represent internal procedures similar to those shown in FIGS. 4 and 5, except for the conversion step. The process for converting the level 2 unit object works by processing each of the syntactic elements contained within the unit object. As described earlier, the syntactic elements are stored as atomic objects on the data stack. Conversion of units may also be employed independently, using predefined units or user-defined units. The unit object to be converted is entered and then the conversion process may be invoked by pressing a key or sequence of keys on keyboard 22 to select the desired unit. Dimensional consistency is checked, the scalar part of the unit object is converted to a new value, and the unit part is changed to the desired unit. For predefined units, the unit can be selected from a menu (or spelled out), as will be described with reference to FIG. 12. For compound units, the user keys in the unit, presses a specific key for such conversions, as will be described with reference to FIG. 13. The conversion process is particularly described in the pseudocode appearing in Appendix I.

Managing units according to the invention as described may be simplified through the provision of a menu-based user interface. The program for displaying the various menus of the interface is store in ROM 22. It is executed by the CPU 38 to display the menus on the display 24 in response to key entries from the keyboard 22.

The unit management system of the present invention supports eight unit quantities, corresponding to SI-defined fundamental base measurements; length, mass, time, temperature, amount of substance, luminous intensity, electrical current, and one extra for user-defined quantities (such as currency). All derived units (that is, units other than those in these categories) are made up of a combination of these base quantities. Regardless of the combinations of individual units in two different compound units, the compound units will be dimensionally consistent if their underlying base quantities are the same.

FIG. 8A illustrates the first portion of a units menu 87 that is displayable on the display 24 for selecting types of units for unit objects and related units within each type. The menu 87 is shown in rows of six entries each, corresponding to the six menu keys 34 on the keyboard 22 in FIG. 1. The first row is activated by successively pressing the left shift key 28 and the units menu selection key 26 (labeled UNITS). Successive rows are activated by pressing key 32 (labeled NXT) one or more times until a row with the desired entry is visible.

Each menu key 34 then corresponds to a second portion of the units menu, a sub-menu with entries representing physical units that fall in the category type described by the pressed menu key. For example, in the second row, menu key 34a is assigned to the PRESSURE submenu. Pressing the key 34a activates the PRESSURE submenu 89, which is shown in FIG. 8B. Submenu 89, in turn, has two rows of six entries each, each row of which may be activated by pressing the NXT key 32 a number of times.

Once a submenu such a submenu 89 has been selected, the menu keys 34 behave as follows. Pressing an unshifted menu key 34 enters into a computer register or calculating stack a normalized, predefined unit object (scalar value one) corresponding to the key label. This normalized unit object is then multiplied by a previously entered number or unit object. Thus to enter "25.sub.-- psi", for example, digit keys "2", "5"are pressed to enter a scalar part into memory. Then menu key 34a for "psi" is pressed to enter the predefined unit object comprising a scalar part of value and unit part "psi" into memory,. Upon its entry, the predefined unit object is multiplied times the scalar part to create the derived unit object. Arbitrary unit powers and compound multiplicative units can be entered by successive presses of other unit menu keys.

Pressing a "convert" key (which in the present embodiment may be a simple keyboard shift key) enters a normalized unit object (scalar value 1) corresponding to the key label, then converts the first entered unit to the units specified by a following dimensionally consistent unit, returning the converted unit for further computation or conversion. Thus to convert 25.degree. C. to Fahrenheit, press the digit keys "2", "5", ".degree.C.", "Convert" and ".degree.F.".

Pressing an alternate shift or "divide" key, followed by a menu key enters a normalized unit object (scalar value 1) corresponding to the key label, then executes a divide (/) of a previous unit by the following unit. This allows for the entry of compound units in which one or more unit names are to be entered in the denominator.

FIG. 9 illustrates the program logic defining the menu key action. With a submenu displayed, the program waits for the press of a key (91). If the key pressed is not a menu key (93), such a digit key for entering the scalar value, the key's function is carried out (94). When a menu key 34 is pressed, the scalar value is multiplied by the selected unit to create a unit object (96). Several options are now possible. If no shift key is pressed (98) before another menu key is pressed, then the present unit object is multiplied (100) by the next unit entered to create another unit for the object, such as "ft 2". If the shift key 28 is pressed (102), the present unit object is divided (104) by the next unit entered to create another unit for the object, such a "m/s". If the shift key 30 is pressed, then the unit of the present unit object is converted (106) to the next unit entered, assuming it is dimensionally consistent with the present unit. If no menu key press follows, then the present unit object is complete as it is. The program has an error-reporting step (108), in which an incorrect operation is reported (110) to the user with a displayed message indicating the nature of the error.

How the interface works with the unit management program is illustrated by example in FIGS. 10-13. FIG. 10 is a series of screen displays showing the creation of a unit object from the multiplication and division of other unit objects. First the LENG submenu is selected and the unit objects "50.sub.-- ft" and "45.sub.-- ft" are multiplied together. Following the method illustrated in FIG. 4, the product "2250.sub.-- ft 2" is produced and displayed at level 1 on the display 24. The TIME submenu is then selected and the unit object "3.2.sub.-- d" is entered and then divided into "2250.sub.-- ft". The result is shown in the display 24 as "703.125.sub.-- ft 2/d."

FIG. 11 is a series of screen displays showing the creation of a unit object from the addition of two unit objects. First the FORCE submenu is selected and the unit object "0.4.sub.-- lbf is entered as the first term. The second term, "11.9.sub.-- dyn" is entered from the same submenu, forcing "0.4.sub.-- lbf" into level 2. As the second term is being entered, the unit management program checks via the respective quantity data for dimensional consistency, which exists since both terms are from the same submenu. On pressing the addition key, the scalar of the level 2 unit object is converted to a new value based on the unit of the level 1 unit object, and the two scalars are added together to produce the sum of "177940.76461.sub.-- dyn".

FIG. 12 is a series of screen displays showing a method for converting a unit object from one unit to a dimensionally consistent unit that is predefined. To convert "10.sub.-- atm" to "inHg", for example, the PRESSURE submenu 86 is selected and "10.sub.-- atm" is entered. To convert to inches of mercury, the appropriate row of the PRESSURE submenu is activated and then the left shift key 28 and the menu key assigned to "inHg" are successively pressed. The result is the conversion of "10.sub.-- atm" to "299.212598425.sub.-- inHg", as shown on display 24.

FIG. 13 is a series of screen displays showing a method for converting a unit object front one unit to a dimensionally consistent unit that is not predefined, such as "qt/h". A compound unit object "12.sub.-- ft 3/min" is entered via several submenus. A new unit expression is created by first entering a scalar to distinguish the previous entry and then the constituent unit parts of the new unit, such as "1.sub.-- qt/h" in the second screen display. The level 2 unit object is the original unit object. The level 1 unit object contains the new unit expression. The number part of the level 1 unit object is ignored. The unit conversion is then executed by calling up a menu that contains a CONV label and pressing the assigned menu key 34. The conversion results in display of a mew unit object "21543.8961039.sub.-- qt/h".

Having illustrated and described the principles of the invention in a preferred embodiment, it should be apparent to those skilled in the art that the invention can be modified in arrangement and detail without departing from such principles. We claim all modifications coming within the spirit and scope of the following claims. ##SPC1##