Home Page ] [ Eiffel Archive ] [ Eiffel Classes and Clusters ]

Arc de Triomphe clipart (2486 bytes)Formula Parsing Cluster

Written by F J Alonso.

formulap.zip (10,839 bytes)

The Formula Parsing Cluster

This small cluster was born from the need to resolve small formulae in the style of

X + ( STEP * 2 ) / KERF

that are defined in a parametric CAD - CAM system actually under development.

Use of more complex libraries like EiffelLex or EiffelParse (let alone YOOC...) seemed like overkill for such a small task, so this (micro)cluster was developed on the fly to solve positional references related to a working area or slab of material, in a new approach to parametric design. Instead of giving precise numerical positions, these are entered as formulae which use named variables such as thickness, width and length. In this way, if a part to be machined has, say, six holes in it proportionally spaced, the proportion is kept constant if overall dimensions are changed. In actual parametric systems a new part program is generated for any dimensional change, but you need to define a 'pattern program' telling which items are fixed or variable.

The cluster contains the following classes:

The parser allows the definition of named variables only limited by system resources, and works as follows:

Once an instance of the parser is created, new variables can be defined by means of

set_var ( name : STRING; value : DOUBLE )

also, the value of an existing variable can be obtained by

get_var ( name : STRING ) : DOUBLE

Setting the value of an existing variable implies the re-evaluation of the actual expression. Recalculation is also forced by the command

set_expression ( ns : STRING )

The usual way to employ the formula parser is

evaluate_string ( ns : STRING ) : DOUBLE

which set ns as the actual expression, evaluates it, and returns the result.

The parsing process goes this way:

Any character not matching any of these groups is rejected and the process stopped with the corresponding error flag and message.

As can be seen from the source code, this generation process is conceptually similar to the workings of a finite state machine (as the vast majority is, by the way).

Finally, just one final lexem of type solved literal remains in the list, containing the result of the whole evaluation process.

As stated above, this cluster was developed on the fly and in a hurry, strictly to solve a punctual need. So it needs still some homework to consolidate it to a really useful tool. Among other things, (math) functions (sin, cos, etc...) could be implemented, just by means of a new lexem identified by a left parenthesis after a sequence of characters, now identified as a variable name. The sequence of lexems until the closing right parenthesis would be the argument(s) to such function, so it is rather a special case of parenthesis level recognition.

The main structure -linked list of lexems- could be substituted by some kind of tree, the so called abstract syntax tree (AST) employed as a basis for compilers. Then it can be solved from leafs to nodes left-right and down-up, but I do not see any clear advantage in doing so, at least for such a small complexity task.

Also, the error catching system is designed mainly to debug the client classes, so it is rather crude and primitive.

Included with this cluster, but not directly related, goes the class tokenizer. It is a mere string dissector that returns a linked list of strings -tokens- given a character to be used as the separator and the string -line of text- to process. It is a very simple utility, but I found it very useful when having to deal with some kinds of textual information stored in files by some CAD - CAM systems ( IGES, WaveFront formats and the like... ).

The cluster has been developed and tested under ISE's Eiffel rel. 3.3.9. Porting to SIG's Visual Eiffel should be automatic if using the Base libraries licensed by ISE. Otherwise, the main issue is replacing the linked list container by any other suitable structure. As I do not have any Tower license, I cannot assure portability to their implementation but this code is just Eiffel, isn't it?

No benchmarks have been applied on the code but it is fast enough in the 'real life' final system it belongs to. (Under Win95 on Pentium 150Mh with 16Mb ram I cannot see any speed penalty for evaluating formulae instead of working with real values. Today, 'Speed' when applied to CAD-CAM systems is rather a matter of graphic cards, RAM and storage access, not raw calculations).


All this code is to be considered as licensed under the usual terms of the GNU / FSF agreement, any version.

About the Author

F. J. Alonso is a freelance consultant and developer of industrial and CAD - CAM systems written in Eiffel. Has been Project Manager for some European Community projects under supervision of the U.S. Dep. of Defence ( Project TOMI, Tools for the Open Microprocessor Initiative, dealing with the Very High Speed Microprocessor Hardware Definition Language, VHDL ) and is specialized in programming and support systems for numerically controlled machine-tools.

Now working on the S.A.F.E., Simple Application Framework in Eiffel for CAD-CAM, which is an attempt to build a complete taxonomy of machining processes with all the complementary libraries to help developing applications in the field,

Email to: fja@arrakis.es

Postal address:

F. J. Alonso
Av. de Reus, 17

Home Page ] [ Eiffel Archive ] [ Eiffel Classes and Clusters ]