Customizing muparser

Defining parser constants

Parser constants can either be values of type double or string. Constness refers to the bytecode. Constants will be stored by their value in the bytecode, not by a reference to their address. Thus accessing them is faster. They may be optimized away if this is possible. Defining new constants or changing old ones will reset the parser to string parsing mode thus resetting the bytecode.

The Names of user defined constants may contain only the following characters: 0-9, a-z, A-Z, _, and they may not start with a number. Violating this rule will raise a parser error.

[DLL interface]

// Define value constants _pi
mupDefineConst(hParser, "_pi", (double)PARSER_CONST_PI);  

// Define a string constant named strBuf
mupDefineStrConst("strBuf", "hello world");

See also: samples/example2/example2.c.

[Parser class interface]

// Define value constant _pi
parser.DefineConst("_pi", 3.141592653);

// Define a string constant named strBuf
parser.DefineStrConst("strBuf", "hello world");

See also: samples/example1/example1.cpp.

Querying parser constants

Querying parser constants is similar to querying variables and expression variables.

[DLL interface]

Due to the use of an temporary internal static buffer for storing the variable name in the DLL version this DLL-function is not thread safe.
int iNumVar = mupGetConstNum(a_hParser);

for (int i=0; i < iNumVar; ++i)
{
  const char_type *szName = 0;
  double fVal = 0;
  mupGetConst(a_hParser, i, &szName, fVal);
  std::cout << "  " << szName << " = " << fVal << "\n";
}

See also: samples/example2/example2.c.

[Parser class interface]

The parser class provides you with the GetConst() member function that returns a map structure with all defined constants. The following code snippet shows how to use it:

mu::valmap_type cmap = parser.GetConst();
if (cmap.size())
{
	mu::valmap_type::const_iterator item = cmap.begin();
	for (; item!=cmap.end(); ++item)
		cout << "  " << item->first << " =  " << item->second << "\n";
}

See also: example1/example1.cpp.

Defining parser variables

Custom variables can be defined either explicit in the code by using the DefineVar function or implicit by the parser. Implicit declaration will call a variable factory function provided by the user. The parser is never the owner of its variables. So you must take care of their destruction in case of dynamic allocation. The general idea is to bind every parser variable to a C++ variable. For this reason, you have to make sure the C++ variable stays valid as long as you process a formula that needs it. Only variables of type double are supported.

Explicitely defining variables

Explicitely in this context means you have to do add the variables manually it in your application code. So you must know in advance which variables you intend to use. If this is not the case have a look at the section on Implicit creation of new variables.

Defining new Variables will reset the parser bytecode. Do not use this function just for changing the values of variables! It would dramatically reduce the parser performance! Once the parser knows the address of the variable there is no need to explicitely call a function for changing the value. Since the parser knows the address it knows the value too so simply change the C++ variable in your code directly!

[DLL interface]

The first parameter is a valid parser handle, the second the variable name and the third a pointer to the associated C++ variable.

double fVal=0;
mupDefineVar(hParser, "a", &fVal);

See also: samples/example2/example2.c.

[Parser class interface]

The first parameter is the variable name and the second a pointer to the associated C++ variable.

double fVal=0;
parser.DefineVar(<"a", &fVal);

See also: samples/example1/example1.cpp.

Implicit creation of new variables

Implicit declaration of new variables is only possible by setting a factory function. Implicit creation means that everytime the parser finds an unknown token at a position where a variable could be located it creates a new variable with that name automatically. The necessary factory function must be of type:

double* (*facfun_type)(const char*, void*)

The first argument to a factory function is the name of the variable found by the parser. The second is a pointer to user defined data. This pointer can be used to provide a pointer to a class that implements the actual factory. By doing this it is possible to use custom factory classes depending on the variable name.

Be aware of name conflicts! Please notice that recognizing the name of an undefined variable is the last step during parser token detection. If the potential variable name starts with identifiers that could be interpreted as a function or operator it will be detected as such most likely resulting in an syntax error.

The following code is an example of a factory function. The example does not use dynamic allocation for the new variables although this would be possible too. But when using dynamic allocation you must keep track of the variables allocated implicitely in order to free them later on.

double* AddVariable(const char *a_szName, void *pUserData)
{
	static double afValBuf[100];  
	static int iVal = -1;

	iVal++;

	std::cout << "Generating new variable \""
              << a_szName << "\" (slots left: " 
              << 99-iVal << ")" << endl;
	
	// You can also use custom factory classes like for instance:
	// MyFactory *pFactory = (MyFactory*)pUserData;
	// pFactory->CreateNewVariable(a_szName);
  
	afValBuf[iVal] = 0;

	if (iVal>=99)
		throw mu::ParserError("Variable buffer overflow.");
	else
		return &afValBuf[iVal];
}

See also: samples/example1/example1.cpp.

In order to add a variable factory use the SetVarFactory functions. The first parameter is a pointer to the static factory function, the second parameter is optional and represents a pointer to user defined data. Without a variable factory each undefined variable will cause an undefined token error. Factory functions can be used to query the values of newly created variables directly from a database. If you emit errors from a factory function be sure to throw an exception of type ParserBase::exception_type all other exceptions will be caught internally and result in an internal error.

[DLL interface]

mupSetVarFactory(hParser, AddVariable, pUserData);

See also: samples/example2/example2.c.

[Parser class interface]

parser.SetVarFactory(AddVariable, pUserData);

See also: samples/example1/example1.cpp.

Querying parser variables

Keeping track of all variables can be a difficult task. For simplification the parser allows the user to query the variables defined in the parser. There are two different sets of variables that can be accessed:

  • Varaiables defined in the parser
  • Variables used in the current expression

Since the usage of the necessary commands is similar the following example shows querying the parser variables only.

[DLL interface]

For querying the variables used in the expression exchange mupGetVarNum(...) with mupGetExprVarNum(...) and mupGetVar(...) with mupGetExprVar(...) in the following example. Due to the use of an temporary internal static buffer for storing the variable name in the DLL version this DLL-function is not thread safe.

// Get the number of variables
int iNumVar = mupGetVarNum(a_hParser);

// Query the variables
for (int i=0; i < iNumVar; ++i)
{
  const char_type *szName = 0;
  double *pVar = 0;
  mupGetVar(a_hParser, i, &szName, &pVar);
  std::cout << "Name: " << szName << "   Address: [0x" << pVar << "]\n";
}

See also: samples/example2/example2.c.

[Parser class interface]

For querying the expression variables exchange parser.GetVar() with parser.GetUsedVar() in the following example.

// Get the map with the variables
mu::Parser::varmap_type variables = parser.GetVar();
cout << "Number: " << (int)variables.size() << "\n";

// Get the number of variables
mu::Parser::varmap_type::const_iterator item = variables.begin();

// Query the variables
for (; item!=variables.end(); ++item)
{
  cout << "Name: " << item->first << " Address: [0x" << item->second << "]\n";
}
See also: example1/example1.cpp.

Setting custom value recognition callbacks

The parser default implementation (muParser.cpp) scans expressions only for floating point values. Custom value recognition callbacks can be used in order to implement support for binary, hexadecimal or octal numbers. These functions are called during the string parsing step and allow client code to scan portions of the original expressions for special values. Their callback functions must be of the following type:

bool (*identfun_type)(const char_type*, int*, value_type*);

If the parser reaches an a position during string parsing that could represent a value token it tries to interpret it as such. If that fails the parser sucessively calls each of the external value recognition callbacks in order to give them a chance to make sense out of what has been found. If all of them fail the parser continues to check if it is a variable or another kind of token.

In order to perform the task of value recognition the callback functions take a const char pointer, a pointer to int and a pointer to double as their arguments. The const char pointer points to the current position in the expression string. The second argument is a pointer to an integer value representing the index of that position relative to the start of the expression string. This value must be increased by the length of the value entry if one has been found. In that case the value must be written to address pointed to by the third argument which is of type double. The return value is of type bool and indicates whether a value was found or not.

The following code snippet shows a sample implementation of a function that reads and interprets binary values from the expression string. For this sample to work binary numbers must be preceded with a # (i.e. #1000101).

bool ParserInt::IsBinVal(const char_type *a_szExpr, int *a_iPos, value_type *a_fVal)
{
	if (a_szExpr[0]!='#') 
		return false;

	unsigned iVal = 0, iBits = sizeof(iVal) * 8;
	for (unsigned i=0; (a_szExpr[i+1]=='0'||a_szExpr[i+1]=='1')&& i<iBits; ++i)
	{
		iVal |= (int)(a_szExpr[i+1]=='1') << ((iBits-1)-i);
	}

	if (i==0) 
		return false;

	if (i==iBits)
		throw mu::ParserError("Binary to integer conversion error (overflow).");

	*a_fVal = (unsigned)(iVal >> (iBits-i) );
	*a_iPos += i + 1;

	return true;
}

Once you have the callback you must add it to the parser. This can be done with:

[DLL interface]

mupAddValIdent(hParser, IsBinVal);

See also: samples/example2/example2.c.

[Parser class interface]

parser.AddValIdent(IsBinVal);

See also: src/muParserInt.cpp.

Removing variables or constants

Removing variables and constants can be done all at once using ClearVar and ClearConst. Additionally variables can be removed by name using RemoveVar. Since the parser never owns the variables you must take care of their release yourself(if they were dynamically allocated). If you need to browse all the variables have a look at the chapter explaining how to query parser variables.

[DLL interface]

// Remove all constants
mupClearConst(hParser);

// remove all variables
mupClearVar(hParser);

// remove a single variable by name
mupRemoveVar(hParser, "a"); 

See also: samples/example2/example2.c

[Parser class interface]

// Remove all constants
parser.ClearConst();

// remove all variables
parser.ClearVar();

// remove a single variable by name
parser.RemoveVar("a");

See also: example1/example1.cpp

Defining parser functions

The parser allows the definition of a wide variety of different callback functions. Functions with a fixed number of up to ten numeric arguments, functions with a variable number of numeric arguments and functions taking a sinlge string argument plus up to two numeric values. In order to define a parser function you need to specify its name, a pointer to a static callback function and an optional flag indicating if the function is volatile. Volatile functions are functions that do not always return the same result for the same arguments. They can not be optimized.

The static callback functions must have of either one of the following types:

// For fixed number of arguments
value_type (*fun_type1)(value_type); 
value_type (*fun_type2)(value_type, value_type); 
value_type (*fun_type3)(value_type, value_type, value_type); 
value_type (*fun_type4)(value_type, value_type, value_type, value_type); 
value_type (*fun_type5)(value_type, value_type, value_type, value_type, value_type); 
// ... and so on to up to 10 parameters

// for a variable number of arguments
//   first arg:   pointer to the arguments
//   second arg:  number of arguments
value_type (*multfun_type)(const value_type*, int);

// for functions taking a single string plus up to two numeric values
value_type (*strfun_type1)(const char_type*);
value_type (*strfun_type2)(const char_type*, value_type);
value_type (*strfun_type3)(const char_type*, value_type, value_type);

[DLL interface]

When using the DLL version it is necessary to call a separate function for each type of callback. The following is a list of possible choices.

// Add functions taking string parameters that cant be optimized
mupDefineStrFun1(hParser, "StrFun1", pStrCallback1, false); 
mupDefineStrFun2(hParser, "StrFun2", pStrCallback2, false); 
mupDefineStrFun3(hParser, "StrFun3", pStrCallback3, false); 

// Add an function with a fixed number of arguments
mupDefineFun1(hParser, "fun1", pCallback1, false);             
mupDefineFun2(hParser, "fun2", pCallback2, false);             
mupDefineFun3(hParser, "fun3", pCallback3, false);    
mupDefineFun4(hParser, "fun4", pCallback4, false);             
mupDefineFun5(hParser, "fun5", pCallback5, false);             

// Define a function with variable number of arguments
mupDefineMultFun(hParser, "MultFun", pMultCallback);

See also: samples/example2/example2.c.

[Parser class interface]

Defining callback functions by using the parser class directly is easier since there is only a single member function that is used for all kinds of callbacks. Since this member function is defined as a template internally it automatically associates the right code to any given type of callback. (As long as this type is listed above)

parser.DefineFun("FunName", pCallback, false)

See also: samples/example1/example1.cpp; src/muParserInt.cpp.

Defining parser operators

The parser is extensible with different kinds of operators: prefix operators, infix operators and binary operators. Operators can be applied to numerical values only (not to string constants).

  • Postfix operators are operators that succeed values. For instance the factorial operator (a! = a*(a-1)...*2*1). Another application for postfix operators is their use as multipliers that can be used for implementing units.
  • Infix operators are operators like the unary minus which serves as a sign or the logical not "!(a<9)".
  • Binary operators can be defined in order to supplement or replace the built in binary operators they require an additional parameter, the operator priority.

Unary operators

Both postfix and infix operators take callback functions of type fun_type1 like the following:

value_type MyCallback(value_type fVal) 
{
	return fVal / 1000.0;
}

For defining postfix operators and infix operators you need a valid parser instance, an identifier string, and an optional third parameter marking the operator as volatile (non optimizable). In the dll Interface the last parameter is not optional and represented by an integer (0 means do not optimize). The last parameter is merely a hint for the parser. It is not guaranteed that optimization will take place. If a function is marked as being optimizable function calls may be replaced with a precomputed result if the parser detects that the argument is a constant. This is safe for functions as long as they always return the same result when fed with the same input parameter. (An example where optimization is not desired is a function returning random numbers.)

[DLL interface]

// Define an infix operator
mupDefineInfixOprt(hParser, "!", MyCallback, 0);

// Define a postfix operators
mupDefinePostfixOprt(hParser, "M", MyCallback, 0);

See also:samples/example2/example2.c.

[Parser class interface]

// Define an infix operator
parser.DefineInfixOprt("!", MyCallback, 0);

// Define a postfix operators
parser.DefinePostfixOprt("m", MyCallback, 0);

See also:samples/example1/example1.cpp.

Binary operators

muParser has 15 Built in binary operators but sometimes it might be necessary to add additional custom binary operators. Examples are shl or shr, the "shift left" and "shift right" operators for integer numbers. You can bind any callback of type fun_type2 as a binary operator to muParser. The operator can then be defined by using the functions mupDefineOprt respectively DefineOprt:

[DLL interface]

mupDefineOprt(muParserHandle_t handle,
              const muChar_t ident,
              muFun2_t function, 
              muInt_t precedence,
              muInt_t associativity,
              muBool_t optimizeable);

See also:samples/example2/example2.c.

[Parser class interface]

ParserBase::DefineOprt(const string_type ident,
                       fun_type2 function,              
                       unsigned precedence,
                       EOprtAssociativity associativity,
                       bool optimizeable);

See also:samples/example1/example1.cpp.

For the definition of binary operators the following Parameters are required:

handle
This parameter exists only in the dll interface and must be a valid parser handle.
ident
A string representing the operator identifier. By default muParser restricts the set of characters useable in operator identifiers. You can modify this set by using the function DefineOprtChars.
function
The second parameter is a function pointer to a static callback function of type fun_type2. This is the place were you have to implement your operator logic.
precedence
An integer value determining the operator precedence. When dealing with multiple operations involving binary operators without using brackets this value determines which operator is excuted first. The binary operator with the higher precedence values is executed first. For instance: In the expression 2 + 3 * 4 the result is 14 since the multiplication has a higher precedence value than the addition. For convenience muParser defines the enumeration EOprtPrecedence. This enumeration lists the precedence values used by muParsers internally defined operators. You can use the values listed there as reference when implementing custom operators but in order to not restrict the possible precedence values the function parameter itself is an integer value rather than an enumerator of type EOprtPrecedence
enum EOprtPrecedence
{
	// binary operators
	prLOR     = 1,
	prLAND    = 2,
	prLOGIC   = 3,  // logic operators
	prCMP     = 4,  // comparsion operators
	prADD_SUB = 5,  // addition
	prMUL_DIV = 6,  // multiplication/division
	prPOW     = 7,  // power operator priority (highest)
	
	// infix operators
	prINFIX   = 6,  // Signs have a higher priority than ADD_SUB, but lower than power operator
	prPOSTFIX = 6   // Postfix operator priority (currently unused)
};
associativity
The operator associativity determines how operators of the same precedence are grouped in the absence of parentheses. Operators can either be left or right associative. For instance consider the expression 5^4^3^2. Depending on the operator associativity this expression could either be interpreted as 5^(4^(3^2)) which correctly implements the power operator as a right associative operator or alternatively one could also evaluate: ((5^4)^3)^2 The parser defines the following enumeration to represent associativity values:
enum EOprtAssociativity
{
  oaLEFT  = 0,  // left associative operator
  oaRIGHT = 1   // right associative operator
};
(When using the dll interface you have to use the integer values instead of the enumerator)
optimizeable
This parameter determines whether the operator always returns the same result when fed with the same input. Normally this is the case so it should be true. There are very few scenarios where an operator does not always return the same values when fed with the same input (i.e. when random number generation is involved)

Finally i'd like to point out that if you encounter confilcts with built in operators or simply don't need the built in operators at all they can easily be deactivated using the EnableBuiltInOprt(bool) function. If you call this function you must add binary operators manually. After all without any operators you won't be able to parse anything useful. User defined operators come with approximately 10% decrease in parsing speed compared to built in operators. There is no way to avoid that. They cause an overhead when calling theeir callback functions. (This is the reason why there are built in operators)

// disable all built in operators
parser.EnableBuiltInOprt(false);

Localization

Sometimes it is necessary to change decimal separator, argument separator or thousands separator to match a certain locale. The following functions can be used for this purpose:

[DLL interface]

// german localization
mupSetArgSep(hParser, ';');
mupSetDecSep(hParser, ',');
mupSetThousandsSep(hParser, '.');

// reset to defaults
mupResetLocale();

See also: samples/example2/example2.c.

[Parser class interface]

// german localization
parser.SetArgSep(';');
parser.SetDecSep(',');
parser.SetThousandsSep('.');

// reset to defaults
parser.ResetLocale();

See also: samples/example1/example1.cpp.