What's new in v4.5.2
What's new in v4.5.1
FP_SUPPORT_CPLUSPLUS11_MATH_FUNCS) because not all compilers yet fully support the C++11 math functions.
What's new in v4.5
"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.)
FP_SUPPORT_TR1_MATHare now automatically used if
__cplusplusindicates that C++11 is in use.
What's new in v4.4.3
What's new in v4.4.2
What's new in v4.4.1
std::complexwith TR1 math functions enabled. (TR1 does not define any new math functions for
std::complexeven 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.)
What's new in v4.4
long double) as the numerical type, along with new complex-specific functions.
long doubleliteral parsing accuracy.)
What's new in v4.3
"atan2(-x,-y)"was being wrongly optimized into
What's new in v4.2
Optimize()method now works also with the
long doubleversions of the library.
isinf()in the optimizer which made it not compile with some compilers. This call has been removed.
What's new in v4.1
strto...()C library functions happened to support them (which is a non-standard extension of those functions). See documentation for details.
What's new in v4.0.5
MpfrFloat::const_e()was incorrectly calculated.
MpfrFloat::someEpsilon()is more sensible now (more proportional to the precision of the mantissa).
What's new in v4.0.4
care user-defined functions, were wrongly optimized.)
What's new in v4.0.3
"-x<3"were wrongly optimized.
What's new in v4.0.2
"x*4/2"to be parsed incorrectly.
"cosh(asinh(x))"which potentially caused a stack corruption.
What's new in v4.0.1
What's new in v4.0
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.)
Parse()method, making it 15-30% faster with most inputs.
Parse()method now performs significantly more bytecode optimizations than before, without compromising parsing speed.
What's new in v3.3.2
What's new in v3.3.1
What's new in v3.3
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.
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).
What's new in v3.2.1
"log(-x)"and certain integral powers (eg.
"x^14") were optimized incorrectly. (In the case of the integral powers, the error manifested itself when
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.)
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
FP_NO_ASINHprecompiler constants have been replaced with a more generic
FP_SUPPORT_TR1_MATH_FUNCSprecompiler constant, which enables other similar functions as well. Consult the documentation on this subject for details.
acosh" and "
atanh" functions are now always available in the function syntax regardless of whether
FP_SUPPORT_TR1_MATH_FUNCShas been defined or not. (If it's not, then they will be calculated using equivalent formulas.)
abs()function in diverse situations, some exponentiation, logarithm and hyperbolic trigonometry optimizations, and others).
"(x*x)^0.25"to be optimized incorrectly (for negative values of
What's new in v3.1.5
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
care any expressions).
What's new in v3.1.3
What's new in v3.1.2
What's new in v3.1.1
What's new in v3.1
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.)
What's new in v3.0.3
-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.)
What's new in v3.0.2
What's new in v3.0.1
What's new in v3.0
Parse()function is over 5 times faster than the old one for most inputs.
pow()function (which takes two parameters) to the function syntax. Its behavior is identical to that of the
What's new in v2.84
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.
FP_DISABLE_EVALto 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.
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).
"max(0, min(-2,0))"to be wrongly optimized (the return value was wrong).
What's new in v2.83
What's new in v2.82
What's new in v2.81
Eval()function thread-safe with a precompiler constant.
acos(0)" to misbehave.
What's new in v2.8
<=" and "
fpconfig.hhor it can be completely disabled there).
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.)
What's new in v2.71
What's new in v2.7
^) to make it closer in functionality to the power "operator" in mathematics (ie. superscript):
"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).
"-2^3"will be evaluated as if written as
"-(2^3)", ie. the result is
"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
What's new in v2.63
What's new in v2.62
What's new in v2.61
What's new in v2.6
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).
,): 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:
What's new in v2.5:
AddConstant()method for adding constants to the parser.
AddFunction()methods for adding user-defined functions to the parser.
Optimize()method (please consider it still as experimental).
What's new in v2.4:
Optimize()method which tries to simplify the bytecode so that it will be evaluated faster. Please note that this is still experimental.
What's new in v2.3:
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.)
What's new in v2.22:
What's new in v2.21:
What's new in v2.2:
&' and '
What's new in v2.1:
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
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:
Parse()takes the function as a
const std::string&(this is fully backwards compatible).
Parse()takes the variables as a
"xy"). The old way of taking variable number of parameters was just a too awful hack.
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).
%) and a new function
acosh()) are gone. Needs more testing, though...
What's new in v1.3:
(Thanks to Roland Schmehl for these bug reports).
What's new in v1.21:
What's new in v1.2:
What's new in v1.1: