Version history

What's new in v4.5.2

• Fixed several optimizer bugs.
• Fixed compilation problems with Visual Studio 2013 and gcc.

What's new in v4.5.1

• Reverted the automatic C++11 detection to a precompiler macro setting (FP_SUPPORT_CPLUSPLUS11_MATH_FUNCS) because not all compilers yet fully support the C++11 math functions.
• Fixed a potential duplicate symbol problem that happens with explicit template instantiations.

What's new in v4.5

• Removed support for the "eval()" function from the supported syntax. (This function was too dangerous, too difficult to maintain internally, not very useful, and more or less a gimmick in the first place.)
• Removed several of the conditional compiling macro definitions, namely FP_SUPPORT_TR1_MATH, FP_ENABLE_EVAL, FP_EVAL_MAX_REC_LEVEL, FP_NO_EVALUATION_CHECKS and FP_EPSILON.
• The epsilon value used in comparisons is now set with a member function of FunctionParser (which allows setting different values for different versions of the parser).
• The math functions previously turned on with FP_SUPPORT_TR1_MATH are now automatically used if __cplusplus indicates that C++11 is in use.
• Fixed some compilation problems with clang++.

What's new in v4.4.3

• Added support for user-specialized function pointer objects for user-defined functions (besides the existing support for raw C++ function pointers). See documentation for details.

What's new in v4.4.2

• Complex-only internal functions were being not properly disabled in the non-complex versions of the parser, causing mayhem if they were called from those.

What's new in v4.4.1

• Added missing documentation on complex literals.
• Fixed problem when using std::complex with TR1 math functions enabled. (TR1 does not define any new math functions for std::complex even though C++0x does. When attempting to use them, the implementation of TR1 in the current gcc misbehaves instead of giving a compiler error. This has now been replaced with the equivalent formulas using standard math functions.)
• Fixed some compilation issues in the development version of the library (which happened with certain combinations of disabled parsers and compiler settings).

What's new in v4.4

• Added support for std::complex (of type double, float and long double) as the numerical type, along with new complex-specific functions.
• Removed all dependencies on C99 functions, making the non-double versions of the library usable with older compilers (such as Visual Studio 2005). (But consult the documentation on the long double literal parsing accuracy.)
• Several minor bugfixes.
• Fixed some compilation issues with gcc 4.6.

What's new in v4.3

• Function syntax enhancement: Added possibility of defining new variables in the function string itself. (See documentation for details.)
• Fixed some bugs in the optimizer (among others, "atan2(-x,-y)" was being wrongly optimized into "atan2(x,y)"

What's new in v4.2

• The Optimize() method now works also with the float and long double versions of the library.
• Some new optimizations added.
• There was a call to the C99/C++0x function isinf() in the optimizer which made it not compile with some compilers. This call has been removed.

What's new in v4.1

• Official support for hexadecimal literals (for all the parser types). Previously there was support only if the strto...() C library functions happened to support them (which is a non-standard extension of those functions). See documentation for details.
• Significant amount of new optimizations performed by Parse().
• Minor bugfixes.

What's new in v4.0.5

• Fixed bugs and deficiencies in the MpfrFloat class:
  • All existing values became NaN if the MpfrFloat::setDefaultMantissaBits() was called.
  • MpfrFloat::const_e() was incorrectly calculated.
  • The value of MpfrFloat::someEpsilon() is more sensible now (more proportional to the precision of the mantissa).

What's new in v4.0.4

• Some new optimization rules in both Parse() and Optimize().
• Fixed some optimizer bugs (among others, functions of the form "a()|b()|c()", where a, b and c are user-defined functions, were wrongly optimized.)
• The utility programs in the development package are now separately licensed under the GPL. (This doesn't affect the library itself, which is still LGPL.)

What's new in v4.0.3

• New optimization rules in both Parse() and Optimize().
• Fixed optimizer bugs: Functions of the form "cosh(x^2)" and "-x<3" were wrongly optimized.

What's new in v4.0.2

• Fixed bug which caused functions like "x*4/2" to be parsed incorrectly.
• Fixed bug with functions of type "cosh(asinh(x))" which potentially caused a stack corruption.

What's new in v4.0.1

• Minor bugfixes and documentation corrections.
• Some new optimizer rules (among others, calls to other FunctionParser instances are now inlined, eliminating the call altogether).

What's new in v4.0

• Added support for different numerical types: double, float, long double, long int, multiple-precision floating point numbers using the MPFR library, and arbitrary precision integers using the GMP library. (Note that it's not necessary for these two libraries to exist in the system in order to use the Function Parser library with the other numerical types. Support for these libraries is optionally compiled in using preprocessor settings.)
• Optimizations to the Parse() method, making it 15-30% faster with most inputs.
• The Parse() method now performs significantly more bytecode optimizations than before, without compromising parsing speed.
• Several new optimization rules added to the Optimize() method.
• Switched to the LGPL license.

What's new in v3.3.2

• Fixed an incompatibility with MS Visual Studio which caused the optimizer to enter an infinite loop with some input functions (VS interprets bitfields slightly differently from gcc). Also minor additions and fine-tuning of the optimizer.

What's new in v3.3.1

• Fixed some incompatibilities with MS Visual Studio introduced with the refactored optimizer.

What's new in v3.3

• The Parse() method now performs more exhaustive constant folding (calculating constant expressions at parse time) than before. Also integral powers (eg. like "x^4") are now more optimized at parse time, resulting in faster evaluation even without a call to the Optimize() method (although the latter will sometimes still result in an even better result). The speed impact of this on the Parse() method has been kept minimal.
• More refactoring of the optimizer, making the Optimize() method significantly faster than in the previous version. Also new and more exhaustive rules have been added, resulting in better results in certain cases (eg. when using basic operators in very complex functions).
• Added utility member functions to parse a function so that the variables in the function are deduced automatically. The found variables are returned to the caller if requested.

What's new in v3.2.1

• Fixed bugs in optimizer: Functions in the form "log(-x)" and certain integral powers (eg. "x^14") were optimized incorrectly. (In the case of the integral powers, the error manifested itself when x==0.)
• Fixed some incompatibilities which made the library not compile with MSVC.
• Fixed major crash in FunctionParser::Eval() which happened if it was called without FunctionParser::Parse() having been called successfully (or at all). (Now it always returns 0.0 in such situations.)
• Changed FunctionParser::ErrorMsg() to return an empty string rather than a null pointer if the previous parsing was successful. (Its return value was never intended to be used as a check for success anyways. FunctionParser::GetParseErrorType() can be used for this purpose, if necessary.) This is to avoid potential crashes in the calling program if it assumes that this function always returns a valid string.

What's new in v3.2

• The FP_SUPPORT_ASINH and FP_NO_ASINH precompiler constants have been replaced with a more generic FP_SUPPORT_TR1_MATH_FUNCS precompiler constant, which enables other similar functions as well. Consult the documentation on this subject for details.
• The "asinh", "acosh" and "atanh" functions are now always available in the function syntax regardless of whether FP_SUPPORT_TR1_MATH_FUNCS has been defined or not. (If it's not, then they will be calculated using equivalent formulas.)
• Significant refactoring of the optimizer code, and addition of numerous new optimization rules (related to the abs() function in diverse situations, some exponentiation, logarithm and hyperbolic trigonometry optimizations, and others).
• Fixed bug in the optimizer which caused functions like "sqrt(x*x)" and "(x*x)^0.25" to be optimized incorrectly (for negative values of x).

What's new in v3.1.5

• Added a new RemoveIdentifier() function to the class which can be used to remove existing constants, units and user-defined functions.

What's new in v3.1.4

• Added new optimizer rules (among others, one which groups common factors of subexpressions, ie. it optimizes functions of the form "a*b+a*c" into "a*(b+c)", where a, b and c are any expressions).
• Added support for compiling without evaluation checks (because it's impossible to catch all possible error situations in the first place). See the documentation for more info.
• Dropped the plain text documentation file in favor of the html file.

What's new in v3.1.3

• Fixed a bug in the optimizer which manifested itself at least in gcc 4.4

What's new in v3.1.2

• Fixed the bugs in the new optimizer code, and thus the new optimizer has been restored.
• Small bugfixes and fine-tuning to make the library more compatible with other compilers (especially MSVC++).

What's new in v3.1.1

• Due to several bugs in the new optimizer, the old optimizer (from the library version 3.0.3) has been temporarily restored until these bugs are fixed. The other new library features are not affected.

What's new in v3.1

• The optimizer has been completely rewritten. The new optimizer contains more and better optimization rules than before, and is more easily extensible.
• The Parse() function now precalculates simple constant expressions which can be calculated without compromising parsing speed. For example the input function "x+7/2" will be byte-compiled into the equivalent of "x+3.5". (Note that precalculation of constant expressions at parse time is limited and doesn't work in all possible situations. For example a function like "x+1+2" cannot be precalculated into "x+3" because of the way single-token lookahead recursive descent parsing works. The Optimize() function will do a much more comprehensive optimization work.)
• A new development version of the library is available. The development version of the library contains the full optimizer sources, an extensive regression testbed, a Makefile and other tools.
• Fixed bug: The size of the internal stack was incorrectly calculated in certain situations where a user-defined function taking 0 parameters was used. In some rare circumstances this could potentially cause an out-of-boundaries array access.
• A new HTML version of the documentation is available. Also a small clarification about authorship and crediting was made to the usage license.

What's new in v3.0.3

• Fixed bug that caused functions like "-if(x, 1, 2)" to be parsed incorrectly. (This bug is a very old one, and caused by the change related to the unary minus in the version 2.7 of the library.)
• Changed version numbering to a more logical format.

What's new in v3.0.2

• Added support for specifying a delimiter character. (See fparser.txt for more details.)

What's new in v3.0.1

• Improved UTF8 support, and minor tweaking and fixes.

What's new in v3.0

• Rewrote the parser from scratch. It uses the same parsing technique as the old parser (iow. it's a recursive descent parser), but because of simplification, refactoring and optimizations the new Parse() function is over 5 times faster than the old one for most inputs.
• Support for UTF8-encoded unicode characters in user-defined variable, constant, unit and function names.
• Unit names are no longer in a distinct namespace from all the other names. Thus now unit names must also be distinct from everything else.
• Added the pow() function (which takes two parameters) to the function syntax. Its behavior is identical to that of the ^ operator.

What's new in v2.84

• Changed all precompiler constant names to have the FP_ prefix, to make them more consistent and lessen the danger of name collisions. (This breaks backwards compatibility.) Also added support for all the compiling options to be configurable without having to modify the fpconfig.hh file. Consult the documentation about conditional compiling below.
• Made FP_DISABLE_EVAL to be defined by default (previously it was undefined by default). The "eval()" function is way too dangerous and rarely useful, so it's better for it to be disabled by default.
• If another function parser was given to a parser with AddFunction(), and during evaluation that other parser produced an eval error, the calling parser would ignore it. Now the calling parser will return the same eval error (and 0 as the return value of the function).
• Fixed a bug in the optimizer which caused things like "max(0, min(-2,0))" to be wrongly optimized (the return value was wrong).

What's new in v2.83

• Fixed bug in the optimizer which caused functions like "x-y*1" to crash.

What's new in v2.82

• Fixed bug in the optimizer which caused a crash with some functions.

What's new in v2.81

• Added support for units (see help on the AddUnit() method).
• Added support for optionally making the Eval() function thread-safe with a precompiler constant.
• Fixed optimizer bug that caused things like "acos(0)" to misbehave.

What's new in v2.8

• Put the compile-time options to a separate file fpconfig.hh.
• Added comparison operators "!=", "<=" and ">=".
• Added an epsilon value to the comparison operators (its value can be changed in fpconfig.hh or it can be completely disabled there).
• Added unary not operator "!".
• Now user-defined functions can take 0 parameters.
• Added a maximum recursion level to the "eval()" function (definable in fpconfig.hh). Now "eval()" should never cause an infinite recursion. (Note however, that it may still be relevant to disable it completely because it is possible to write functions which take enormous amounts of time to evaluate even when the maximum recursion level is not reached.)
• Separated the optimizer code to its own file (makes developement easier).

What's new in v2.71

• Fixed a couple of syntax errors which slipped through in the v2.7 distribution version:
  • non-standard semicolons at the end of namespace blocks
  • a compilation error which happens if SUPPORT_OPTIMIZER is disabled
• Included a simple example program.

What's new in v2.7

• Changed precedence rules for unary minus and the power operator (^) to make it closer in functionality to the power "operator" in mathematics (ie. superscript):
  • Consecutive power operators at the same precedence level are evaluated from right to left. That is, for example "2^3^4" is now evaluated as if it had been written as "2^(3^4)" (and not as "(2^3)^4" like in previous versions).
  • The unary minus in the base of the power has now a lower precedence than the power operator. That is, "-2^3" will be evaluated as if written as "-(2^3)", ie. the result is "-8" (and not "8" like in previous versions). The unary minus in the exponent is still evaluated first because of the right-left precedence change above (that is, "-2^-3" is evaluated as "-(2^(-3))").
• Fixed a bug in the copy-on-write engine.

What's new in v2.63

• Some tiny fixes to make the library more compatible with BCB4.

What's new in v2.62

• Only an addition to the usage license. (Please read it.)

What's new in v2.61

• Tiny bug fix: Tabs and carriage returns now allowed in the function string.

What's new in v2.6

• Added a new method: GetParseErrorType(). This method can be used to get the type of parsing error (which can be used eg. for customized error messages in another language).
• Added working copy constructor and assignment operator (using the copy-on-write technique for efficiency). See the "Usage" section for details.
• Fixed a problem with the comma operator (,): Comma is not allowed anymore anywhere else than separating function parameters. In other words, comma is not an operator anymore (just a parameter separator).

What's new in v2.51:

• Tiny fixes to make it work with gcc 2.x (which is still sadly common).

What's new in v2.5:

• A new AddConstant() method for adding constants to the parser.
• Two AddFunction() methods for adding user-defined functions to the parser.
• The library can now handle trigonometrical angles either in radians (default) or degrees with an optional parameter of Parse().
• New functions added: cot(), csc() and sec().
• Enhancements and bug fixes to the Optimize() method (please consider it still as experimental).

What's new in v2.4:

• A new Optimize() method which tries to simplify the bytecode so that it will be evaluated faster. Please note that this is still experimental.
• New functions added: atan2() and log10().
• Two new more detailed syntax error messages (previously simply "Syntax error").

What's new in v2.3:

• Variable names can now have digits and underscores (but they can't begin with a digit).
• Parsing speed optimizations. The Parse() method can be even 40% faster than in the previous version. (Please be aware that the new parser has not been thoroughly tested; bugs are possible.)
• A new "semi-undocumented" debugging function for printing the bytecode of the current function (in an asm-like syntax). Mostly useless from the user's point of view.

What's new in v2.22:

• Fixed a tiny bug which made the class to misbehave when an error occurred during parsing.

What's new in v2.21:

• A tiny fix to make the library work with Borland C++ Builder 4.

What's new in v2.2:

• Support for long variable names (NOTE: Unfortunately this breaks backwards compatibility.)
• New functions: min(), max(), if(), eval().
• Support for recursive calls (with if() and eval()).
• New operators (mainly for use with if(), but can be used anywhere): '=', '<', '>', '&' and '|'.

What's new in v2.1:

• Parsing speed optimization.

  I implemented the parser from the scratch using a known parsing algorithm from classical compiler techniques, thus replacing my old ad hoc parser.

  The parser should be much faster now, specially with long functions with lots of parentheses (specially when the expressions inside parentheses are very long).

  I made a test with the function "((2*(5+x*(cos(y-x)/3+2)/4)+1)/4+x)-1" in a Sun Ultra 5 computer. The version 2.0 of the library parses it in approximately 0.21 ms, while the new version 2.1 parses it in 0.115 ms. (I performed the test by parsing the function 100000 times and then dividing the total time by that.)

  Needs lots of testing to make sure that it works!

What's new in v2.0:

• Slight changes in the interface.
  I'm sorry for the lost backwards compatibility, but the v1.x way of taking the parameters was just awful - I made it better this time.
  These changes are:
  • Parse() takes the function as a const std::string& (this is fully backwards compatible).
  • Parse() takes the variables as a const std::string& (eg. "xy"). The old way of taking variable number of parameters was just a too awful hack.
  • The Eval() function taking a variable number of parameters has been removed. Although it was a bit easier to use, it was a hack and led to inefficient code (internally the parameters were put inside a dynamically allocated array anyways, and that's not the most efficient way of doing it; it's much more efficient that the user uses a statically allocated local array).
  These changes are not radical, so don't get too alarmed. I'm sure that changing old code to this new interface is trivial.
• Added the modulo operator (%) and a new function int().
• I hope that now, at last, all the problems with parsing functions with similar beginnings (eg. acos() vs. acosh()) are gone. Needs more testing, though...

What's new in v1.3:
(Thanks to Roland Schmehl for these bug reports).

• The library parsed wrongly sinh, cosh and tanh (confused them with sin, cos and tan and then reported a syntax error for the 'h').
• The library parsed an expression like "-cos(x)+cos(y)" like if it was "-(cos(x)+cos(y))" instead of "(-cos(x))+cos(y)" as it should. Fixed.
• The library didn't parse correctly numbers in the form "1e-2". Fixed.
• Added some explanations at the end of the fparser.txt file.

What's new in v1.21:

• Fixed several memory leaks (thanks to Stephen Agate for the bug report).

What's new in v1.2:

• If you define the identifier NO_ASINH (see the beginning of fparser.cc), then support for the functions asinh, acosh and atanh will be removed (they are not part of the ANSI C standard and thus not supported by most compilers).
• A tiny bug fixed.

What's new in v1.1:

• Fixed bug that made a negated function (eg. "-sin(x)") crash.