beltoforion / muparserx Goto Github PK

The machinery currently used in muparserx for storing and extracting different 
types at run time doesn't seem as flexible as boost::any (nor as generic? see 
for example issue 36), perhaps muparserx could switch to using boost::any? 
Boost::any seems to be header-only and licensing shouldn't be an issue.

What steps will reproduce the problem?
1. Run latest sample from svn.
2. Enter expression "void = 15" (without "").
3. See the result.

What is the expected output? What do you see instead?
I expect that "void" cannot be used as name for variable, because "void" is 
ToString() output of variables with type VOID.

The above expression is instead true and 15 is assigned to void.

What steps will reproduce the problem?
1. expressions "1i" and "1n" got errors.

What is the expected output? What do you see instead?
the expected output is "i" and "1e-6", but I got errors.

What version of the product are you using? On what operating system?
muparserx 3.0.2 and osx 10.9

What steps will reproduce the problem?
1. enter sin(pi)
2. wait
3. wait

What is the expected output? What do you see instead?


Well, numerically correct result is 0, but engine returns "very small number" 
which is caused by "incorrect" double precision number representation. Do you 
have any ideas on how to solve this? I would suggest either implementing "more 
accurrate" float-number data type or there could some kind of number "rounding".

Value class has functions with different names for returning values of 
different types which is awkward to use from generic code. I suggest adding a 
generic Get function which uses a correct existing function to return a value 
based on the functions template parameter. Something like:

template <class T> T Get(const T& given_value);

where T decides which existing function to call:

template<class T>
typename std::enable_if<
  std::is_integral<T>::value,
  T
>::type Get(const T& given_value) {
  return this->GetInteger(given_value);
}

template<class T>
typename std::enable_if<
  std::is_floating_point<T>::value,
  T
>::type Get(const T& given_value) {
  return this->GetFloat(given_value);
}

etc.

What steps will reproduce the problem?
1. Compile example
2. Use any function which calls GetParent (e.g. "list_fun()")
3. Observe assertion error on m_pParent == NULL


What is the expected output? What do you see instead?

List of functions, see above.


What version of the product are you using? On what operating system?

Linux ntjk 2.6.37.6-0.9-desktop #1 SMP PREEMPT 2011-10-19 22:33:27 +0200 x86_64 
x86_64 x86_64 GNU/Linux
muParserX 2.1.0

Please provide any additional information below.

Can be fixed by making GetParent a const function and using 
SetParent(GetParent()) in Clone() on cloned instance first; tested, solves the 
problem, function works as intended.

Hi,

I'm curious to know if there is any plan to release a new version for muparsex 
(minor release). We're using the library in the ORFEO ToolBox and there are 
patchs which were added to muparserx after last release. Currrently we're 
relaying on the trunk to make it works with OTB. It could facilitate if we can 
provide directly a pointer to a source package

Don't know if there are major ongoing issues which block this.

Thank you in advance.

Best regards,

Manuel

What steps will reproduce the problem?
1. Use an expression like (1e-15 + 1e-15*i)^2
2. The resulting imaginary part is 0, but should not be so.

What is the expected output? What do you see instead?
Expected result is 0 for real and 2e-30 for imag. But get 0 for imag too.

What version of the product are you using? On what operating system?
v3.0.3

Please provide any additional information below.
The following code from OprtPowCmplx::Eval seems somewhat broken in this 
scenario. Should the epsilon compare be ignored for complex?


    // Problem: -2^3   will introduce small imaginary parts due to computational errors.
    //                  -1^0.5 will introduce small real parts due to computational errors.
    //
    // Fix: If roots of negative values are calculated (exponents are non integer) or complex numbers
    //      are involved the complex version of pow is used. The float version is used otherwise.
    if (arg[0]->IsComplex() || arg[1]->IsComplex() || (arg[0]->GetFloat()<0 && !arg[1]->IsInteger()) )
    {
      cmplx_type res = std::pow(arg[0]->GetComplex(), arg[1]->GetComplex());

      // remove obviousely bogus real/imaginary parts from the result
      if (std::abs(res.imag()) < std::numeric_limits<mup::float_type>::epsilon())
        res = res.real();
      else if (std::abs(res.real()) < std::numeric_limits<mup::float_type>::epsilon())
        res = cmplx_type(0, res.imag());


These epsilon compares will kick-in for small numbers too. Should they also be 
used in a more relative way?

Could you please change scope of m_VarDef and CheckName in class ParserXBase to 
protected?

What version of the product are you using? On what operating system?
2.3.1

Try min, max or sum function.

min() -> returns number but should encounter an error, you simply cannot get 
minimum of nothing, same with max and similar with sum.

I recommedn you to create constraint on minimum parameter count. For example 
like in my fix.

What steps will reproduce the problem?

I tried to evaluate the following expressions to determine the precedence of 
the unary minus operator:

muParserX> -3^2
ans = 9
9 (int)
muParserX> -2^3
ans = -8
-8 (int)
muParserX>

What is the expected output? What do you see instead?

I would have expected -3^2 to evaluate to -9 since the negation operator should 
have precedence below the exponentiation operator. Excel works the same way, 
but 

What version of the product are you using? On what operating system?

2.1.4 Mac OS X + WIndows 7


Please provide any additional information below.

这东西效率很低呀，我试了一下，大概RECV=2,RECV1=1,RECV<=RECV1 
&& RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && RECV<=RECV1 && 
这样的表达式，执行1w次eval()需要耗费30s，

I have managed to integrate your muparser into my C# project but am looking to 
have the option to aggregate over arrays.

What I am trying to do is:

AllAges is a variable defined as array of doubles.

Then call:

sum(AllAges)

This does not appear to work in the muparser but am hoping it will work in 
muparserx. I have got the source and built it but all I get is an EXE. Is it 
possible to integrate the muparserx version into C#.net?

Thanks in advance.

What steps will reproduce the problem?
1. Try to run this code:
mup::ParserX parser(mup::pckCOMMON | mup::pckNON_COMPLEX | mup::pckMATRIX | 
mup::pckUNIT);
mup::Value value2{3, 0};
mup::Variable variable2{&value2};
parser.DefineVar("v2", variable2);
parser.SetExpr("v2[0]*v2[0], v2[1]*v2[1], v2[2]*v2[2]");
try {
    const auto& temp = parser.Eval();
} catch(mup::ParserError &e) {
    cout << e.GetMsg() << endl;
}

What is the expected output?
No exception.

What do you see instead?
Exception: Unexpected comma found at position 11.

What version of the product are you using?

3.0.1, macosx


If this is indeed supported the documentation does not mention it: 
https://code.google.com/p/muparserx/wiki/Using

I tried Eval(int) but that gave a compilation error:
error: no matching function for call to 'mup::ParserX::Eval(int&)'
note: candidate is:
const mup::IValue& mup::ParserXBase::Eval() const

What steps will reproduce the problem?

This code doesn't compile: mup::Variable variable;


What is the expected output?

I'd expect the following code to work, which collects all objects related to 
parsing a specific expression together:
std::tuple<
    std::string,
    mup::ParserX,
    mup::Value,
    mup::Variable
> objects;

I don't see how I can initialize Variable in objects with a pointer to Value in 
objects without invoking a default constructor for Variable at some point.


What version of the product are you using?

3.0.1

The following c++ code illustrates the problem

ParserX p;
p.SetExpr(_T("sum(1,2)/sum(3,4)")); // evaluates ok
p.SetExpr(_T("sum(1,2)/sum(3,4,5)")); // crashes muParser on evaluation
Value result = p.Eval();
console() << result << "\n";

What is the expected output? What do you see instead?
Instead of evaluating to (in this example) 0.25, the evaluation crashes 
muParserX

What version of the product are you using? On what operating system?

2.0 version of muParserX
OS: Windows XP (Visual Studio 2005) and MacOS (QT 4.7.3)

What steps will reproduce the problem?
1. Run the attached program using:
 ./test "Var1" 100000000 2>&1 > /dev/null
2. In a different terminal run:
top
3. Watch the %MEM column 

What is the expected output? What do you see instead?
The used memory by "test" is always increasing and it shouldn't

What version of the product are you using? On what operating system?
MuparserX 2.1.2
Linux Kernel 3.1.10-1.16

Please provide any additional information below.
The source test.c is also attached

What steps will reproduce the problem?
1.make

What is the expected output? What do you see instead?
lib

parser/mpOprtCmplx.cpp:309:24: error: ‘numeric_limits’ is not a member of 
‘std’

What version of the product are you using? On what operating system?
gentoo

Please provide any additional information below.
include <limits>

What steps will reproduce the problem?
1. Import project into NetBeans via distributed Makefile.
2.
3.

What is the expected output? What do you see instead?

This compiler warning:

parser/mpMatrix.h: In member function ‘mup::Matrix<T>& 
mup::Matrix<T>::Transpose() [with T = mup::Value]’:
In file included from parser/mpTypes.h:53:0,
                 from parser/mpIToken.h:41,
                 from parser/mpICallback.h:43,
                 from parser/mpIOprt.h:42,
                 from parser/mpOprtMatrix.h:44,
                 from parser/mpOprtMatrix.cpp:35:
parser/mpOprtMatrix.cpp:56:24:   instantiated from here
parser/mpMatrix.h:395:7: warning: operation on 
‘((mup::Matrix<mup::Value>*)this)->mup::Matrix<mup::Value>::m_nRows’ may be 
undefined

What version of the product are you using? On what operating system?

v2_1_2

Win 7 Pro 64 bit (but NetBeans compiles for cygwin)


Please provide any additional information below.

Is this warning expected?

look et mpError.h, line 158

ErrorContext(EErrorCodes a_iErrc,
             int a_iPos,
             string_type a_sIdent,
             char_type cType1,
             char_type cType2,
             int nArg);

You are saying that cType1 is expected type and cType2 is the actual type, but 
if i invoke this exception in my application by 

throw ParserError(ErrorContext(ecTYPE_CONFLICT_FUN, GetExprPos(), GetIdent(), 
'i', arg_1->GetType(), 1));

where arg_1->GetType() returns 'c', then i get error like in picture, as you 
see, "i" and "c" in error message should be switched

solution: either change comments on lines 169 and 170 or tweak strings in 
ParserErrorMsg::ParserErrorMsg()

Source code files are not encoded in UTF-8. UTF-8 is internationally used 
encoding for source files and there is no reason to avoid it. Consider 
translating files into UTF-8.

From a program I'm writing which uses muparserx to assign values to simulation 
variables from a configuration file:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000003 in ?? ()
(gdb) up
#1  0x000000010003d56a in mup::Variable::GetRows (this=0x10050b8e0) at 
parser/mpVariable.cpp:248
248     return m_pVal->GetRows();
(gdb) 
#2  0x0000000100066d61 in mup::OprtIndex::Eval (this=0x10050c7b0, ret=..., 
a_pArg=0x10050ca38, a_iArgc=1)
    at parser/mpOprtIndex.cpp:61
61              int rows = a_pArg[-1]->GetRows();
(gdb) 
#3  0x000000010002b30e in mup::ParserXBase::ParseFromRPN (this=0x100506d48) at 
parser/mpParserBase.cpp:1090
1090              pIdxOprt->Eval(val, &idx, nArgs);
(gdb) 
#4  0x000000010002ae6d in mup::ParserXBase::ParseFromString (this=0x100506d48) 
at parser/mpParserBase.cpp:1004
1004      return (this->*m_pParserEngine)();
(gdb) 
#5  0x0000000100028521 in mup::ParserXBase::Eval (this=0x100506d48) at 
parser/mpParserBase.cpp:243
243   return (this->*m_pParserEngine)();
(gdb) 
#6  0x000000010000b9ab in 
pamhd::boundaries::Variable_To_Option_Vector<Mass_Density>::get_parsed_value<dou
ble> (
    this=0x100506d30, given_position=..., given_time=0) at source/boundaries/variable_to_option_vector.hpp:722
722             const auto& evaluated = this->parser.Eval();

Some values for variables above:
print rows
$3 = 1
print m_pVal
warning: RTTI symbol not found for class 'mup::Variable'
$4 = (IValue *) 0x7fff5fbff0e8



When calling parser.Eval() the expression is r[0] + r[1] + r[2] + t where r and 
t are
this->parser.DefineVar("r", this->r_var);
this->parser.DefineVar("t", this->t_var);
and set to
this->r_val = mup::Value(3, 0); r_val[0] = 1; r_val[1] = 2; r_val[2] = 3;
this->t_val = doube(0);
before calling Eval().


What steps will reproduce the problem?

The program I received this from is complicated, I might be able to make a 
simplified test. If not I'll probably upload the whole thing to github.


What version of the product are you using?

3.0.1 compiled with -g instead of -O3. I get the same result with -O3 but 
without any line numbers in muparserx.

What steps will reproduce the problem?
1. Load latest code from svn.
2. Try to compile example with gcc 4.7.2-4.
3. Seek errors.

What is the expected output? What do you see instead?
Everything gets compiled with few warnings. Compilation fails with several 
errors.

What version of the product are you using? On what operating system?
Latest from svn, LINUX. MSVC compiles ok, BUT generally (as every c++ 
programmer knows) MSVC compiler really sucks (compared to gcc).

Please provide any additional information below.
http://pastebin.com/dMdFTJnL

Can not change value cache size from outside, because m_cache member is private 
and there is no configure function. 

What version of the product are you using? On what operating system?
Version 2.3.1

I am trying to build muparserx for mingw using cross compilation (MXE)

For now; I had patch against current release to cross compile
Even the build exits with 0 status, that isn't working as I am building shared 
libs.

Now for muparser there is muParserDLL.h to deal with windows dll generation and 
very buid/makefile.mingw to ease the process

For muparserx there is no such thing and the existing makefile is ok with linux 
but not with windows. 

You can see [1], my patch is adding CMake build system just because it was easy 
for me to deal with shared, static, mingw, gcc etc..
Also the issue of using cpp98 is also addressed

If you are interested, I could contribute cmake build to muparserx and also 
patches to allow mingw compiler.

If changing to cmake doesn't sound good, then could you provide some help to 
make muparserx dll on windows using mingw

[1] https://github.com/rashadkm/mxe/blob/master/src/muparserx-1-cpp98.patch
[2] http://mxe.cc/

There are certain inconsistencies concerning numerical overflows. Just 
binary/hexa -> decimal conversions are protected against overflows (error is 
thrown when numbers overflow).

But it could be good to guard overflows for all operations: basically just try 
to evaluate "19 << 222". Apparently, negative result is incorrect.


Solution: there are ways to detect overflows. I do it by 
http://pastebin.com/MTuyje6s, i added additional exception type, this is 
generally enough + it is easy to do special checks eg. for factorial where you 
expect numbers <1;+INF). What do you think about it?

What steps will reproduce the problem?
1. The following code throws:
mup::ParserX parser(mup::pckALL_NON_COMPLEX);
mup::Value value1{0};
mup::Variable variable1{&value1};
parser.DefineVar("v1", variable1);
parser.SetExpr("2147483648");
try {
    cout << parser.Eval().GetInteger() << endl;
} ...

What is the expected output? What do you see instead?

The value is only 2^31, shouldn't values up to 2^64-1 be supported for unsigned 
(long long) integers? Is it possible to specify the type of the variable at 
compile-time (and get a parsing error if it is not used as such in the 
expression)?

Currently I'm planning to use std::enable_if<std::is_integral<... and 
enable_if<is_floating_point<... to use either parser.Eval().GetInteger() or 
parser.Eval().GetFloatingpoint() to return the correct value from the parser. 
It would be nice if all types if integers and floating points were supported...


What version of the product are you using? On what operating system?

3.0.1

What steps will reproduce the problem?
1. Value x = 1; Value y = comple<double>(0,1);
2. x+=y; x-=y; fail

What is the expected output? What do you see instead?
+=: expect 1+1i but get 1
-=:  expect 1-1i but get 1

What version of the product are you using? On what operating system?
mac osx 10.9

Please provide any additional information below.
This failure is due to no type conversion after += or -= is performed.
This bug is fatal when we perform matrix-matrix multiplication between real 
matrix and pure imaginary matrix.

It would be nice if more standard math functions were available such as:
http://en.cppreference.com/w/c/numeric/math/atan2
http://en.cppreference.com/w/c/numeric/math/fmod
http://en.cppreference.com/w/c/numeric/math/remainder

What steps will reproduce the problem?
Evaluating something like (-0.27 + 0.66*i)^2 gives wrong output.


What version of the product are you using? On what operating system?
muParserX 2.1.6

Please provide any additional information below.
The problem lies on OprtPowCmplx::Eval which tries to remove the bogus results 
comparing the imaginary and real parts with the smallest numeric limits. If 
some part of the number is negative it'll consider it a bogus result and 
eliminates it. The solution is to take the absolute value.

What steps will reproduce the problem?

The following c++ code illustrates the problem

ParserX p;
p.SetExpr(_T("1 == ??.??.???? ??:00:00.000")); // crashes muParser on 
evaluation in Release only
Value result = p.Eval();

What is the expected output? What do you see instead?
Instead of exception with error, the evaluation crashes muParserX

What version of the product are you using? On what operating system?

2.3.1 version of muParserX
OS: Windows 7 Professional (Visual Studio 2010)

What steps will reproduce the problem?

mup::ParserX p(mup::pckALL_NON_COMPLEX);
p.SetExpr("0.0");
p.Eval();

The Eval() throws an exception that the period "." is not a valid token.  

I tracked it down to the code in DbpValReader::IsValue.  Specifically, the 
existing code is

  bool DblValReader::IsValue(const char_type *a_szExpr, int &a_iPos, Value &a_Val)
  {
    stringstream_type stream(a_szExpr + a_iPos);
    float_type fVal(0);
    std::streamoff iEnd(0);

    stream >> fVal;
    iEnd = stream.tellg();   // Position after reading

    if (iEnd==-1)
      return false;

    a_iPos += (int)iEnd;

If the stream reads to the end of the string, then tellg will return -1 
regardless of whether the value was correctly interpreted.  The better way is 
to check the failbit explicitly.

  bool DblValReader::IsValue(const char_type *a_szExpr, int &a_iPos, Value &a_Val)
  {
    stringstream_type stream(a_szExpr + a_iPos);
    float_type fVal(0);

    stream >> fVal;
    if(stream.fail())
      return false;

    if(stream.eof())
      {
        a_Val=cmplx_type(fVal,0.0);
        a_iPos=strlen(a_szExpr);
        return true;
      }

    std::streamoff iEnd(stream.tellg());   // Position after reading

    a_iPos += (int)iEnd;


What version of the product are you using? On what operating system?

muparserx v2_0_1, though the code seems to be the same in the repository.
Debian testing
g++ 4.6

C++11 has functions for generating various random numbers, it would be nice if 
those were available in expressions. For example if an expression has normal(0, 
1) then whenever a value is obtained from the expression it would be a random 
number from a uniform normal distribution with a mean of 0 and standard 
deviation of 1. I think it would be enough to use a single random source for 
all expressions to keep the implementation relatively simple:
std::mt19937 random_source;
random_source.seed(1);
and when returning a value for normal(a, b) expression:
std::normal_distribution<> norm(a, b);
return norm(random_source);

What steps will reproduce the problem?
1. Checkout muparserx from SVN
2. Compile using latest Intel compiler

What is the expected output? What do you see instead?
The Intel compiler being fairly standard, I would expect that it compiles fine.

Instead it complains that the override keyword is not recognised by the part of 
the standard supported by the latest Intel compiler.

What version of the product are you using? On what operating system?
Latest SVN version on Linux. GCC 4.7 works fine, 4.6 doesn't, Intel doesn't.

Removing the overrides (should not change the behaviour of the program) or 
including the header with:

#ifdef __INTEL_COMPILER
#define override
#endif
#include "mpParser.h"

fixes the issue

Please provide any additional information below.

I also had to tweak a bit the Makefile in order to make gcc 4.7 compile it. 
Patch attached

What steps will reproduce the problem?
Equate (-3)^(1/3)

What is the expected output? What do you see instead?
Output
Real: -nan(0x8000000000000)
Imag: 0.0

Expected:
Real: -1.259921049894873
Imag: 0.0

What version of the product are you using? On what operating system?
muparserx_v2_1_3

I am using muParserX 2.1.4.

When using string variables, there is an issue with the back slash character. 
It seems that muParser interprets this as an escape character. Is this a bug or 
intended behaviour ? Is there a syntax I can use to un-escape ?

compiling and running example.cpp illustrates the issue:

muParserX> strlen("b\a")
ans = 3
3 (int)
muParserX> strlen("b\")
                  ^
Unterminated string starting at position 7 (Errc: 16)

What steps will reproduce the problem?
1. Download latest release of muparserx from 
http://articles.beltoforion.de/article.php?a=muparserx&p=download&s=idPageTop&ad
=1#idPageTop

2.unzip archive and the release folder is muparserx 3.0.3 as opposed to the 
archive name muparserx 3.0.2

What is the expected output? What do you see instead?

download an archive with 3.0.3?


What version of the product are you using? On what operating system?




Please provide any additional information below.

What steps will reproduce the problem?

It doesn't seem to be possible to have ?: in an expression except if it's the 
last one.
This:
abs(y) < 0.25 ? (-1) : (1) + 1
gives either -1 or 2 as an answer not 0 and 2 as might be expected from the 
parentheses and this doesn't work:
(abs(y) < 0.25 ? -1 : 1)
Unexpected parenthesis "(" found at position 1....
(Which also precludes e.g. (x+y)*(x+y), etc.)

So seems it's impossible to have e.g. two independent ?:s in an expression:

(abs(x) < 1 ? -1 : 1) + (abs(y) < 1 ? 1 : -1)
abs(x) < 1 ? (-1) : (1) + abs(y) < 1 ? 1 : -1


What version of the product are you using? On what operating system?
3.0.3, macosx

What steps will reproduce the problem?
1. Evaluate the expression "1+2,3" or "1,3"

What is the expected output? What do you see instead?
I would expect a syntax error, but both expressions evaluate to "3".

What version of the product are you using? On what operating system?
I am using 2.1.4 on windows 7

What steps will reproduce the problem?
1. Start latext example from sources
2. type in a+1
3. press ENTER

What is the expected output? What do you see instead?
3.22 is expected, 3.2200000000000000002 is what i got

Please use labels and text to provide additional information.
On Windows 7 + MinGW 4.7. Not tested in other compilers/oses.

What steps will reproduce the problem?
1. Build provided example
2. Input math expression consisting of ONE SPACE (" ").
3. Hit enter (evaluate expression).

What is the expected output? What do you see instead?
Application does not crash and expression gets evaluated.

What version of the product are you using? On what operating system?
Latest code from from git. Every OS (Linux and Windows).

Given the expression:

c + 7 * b * (a + c)

with c defined as a constant of value 10 (e.g. c=10)

After evaluating this expression with Eval() or GetExprVar(), the RPN obtained 
with the function GetRPN() will contain a list of tokens (TokenPtr<IToken>) 
that were found within the expression. 

The token with identity "c" will appear twice in the RPN. 
OK.

However the token member m_nPosExpr, obtained via GetExprPos(), for the first 
listed token "c" is incorrect: it contains the position of the second token "c" 
(18 instead of 0). m_nPosExpr of the second token C is correct.

This seems to be an issue for constants that appear multiple times in an 
expression.

I would expect that:

a) 15 << -2 returns the same result as 15 >> 2.

OR PERHAPS

b) using negative integer as "shifter" (e.g. 15 << -2) will not be allowed. It 
does not make sense to shift left by "minus two" bits, logically.

Nontheless, current behavior of << was not correct, it returns 3.75 for 15 << 
-2 which is incorrect, i fix this.

But we have to think about << >> anyway. I would suggest behavior B as its more 
strict and strictness is good sometimes.

muparserX version 2.1.1
-----------------------

In function   

bool StrValReader::IsValue(const char_type *a_pszExpr, int &a_iPos, Value 
&a_Val)

in file

mpValReader.cpp

The line

if (sBuf[iEnd-1]!='\\') break;

should be changed into 

if (iEnd == 0 || sBuf[iEnd-1]!='\\') break;


Otherwise for empty strings (e.g. "") sBuf[-1] will cause a memory exception.

When creating a string representation of a matrix, with the following code in 
mpIValue.cpp

  string_type IValue::ToString() const
  {
    stringstream_type ss;
    switch (GetType())
    {
    case 'm':  
          {
            const matrix_type &arr(GetArray());

           // if (arr.GetRows()>1)
              ss << _T("{");

            for (int i=0; i<arr.GetRows(); ++i)
            {
              if (arr.GetCols()>1)
                ss << _T("{");

              for (int j=0; j<arr.GetCols();++j)
              {
                ss << arr.At(i, j).ToString();
                if (j!=arr.GetCols()-1)
                  ss << _T(", ");
              }

              if (arr.GetCols()>1)
                ss << _T("}");

              if (i!=arr.GetRows()-1)
                ss << _T("; ");
            }

            // if (arr.GetRows()>1)
              ss << _T("} ");
          }
          break;


I wonder if it would be better to not test for 
"if (arr.GetRows()>1)" at the start and end of the string build (I have 
commented the two lines above).

Right now the output for a matrix of 1 value is just

value

however I think it should be 

{value}

even if the matrix has only one value, in order to make a difference with the 
non-matrix 

value

I spotted this while parsing something like

Var1 == 1 && Var2 == 2
--
The probable cause is that in mpOprtBinCommon.h many operators have a wrong 
priority. 
In that file you see that the priority of inline defined classes (such as 
OprtEQ) is set equal to 2, instead (I suppose) of prRELATIONAL1

The same applies to relation operators below (prRELATIONAL2).

Also I guess (but I'm not sure) that the MUP_BINARY_OPERATOR definitions in 
that file are not correct. 

 MUP_BINARY_OPERATOR(OprtBAnd, _T("and"),  bool_type, _T("less than"), 1, oaLEFT, a&&b)

should that line have a priority value taken from the EOprPriority enumeration, 
instead of "1"?

What steps will reproduce the problem?
1. Download latest code svn
2. Compile example with latest GCC

What is the expected output? What do you see instead?
Everything compiles OK. Compilation fails on file mpPackageUnit.cpp. GCC 
complains that it cannot ENCODE character "µ" on line 78. 

What version of the product are you using? On what operating system?
Latest from svn, GCC-based compilers

Please provide any additional information below.
Actually, used file encoding is NOT ok on all platforms (except Windows). 
Properly set GCC is able to encode UTF-8/16 and other major encoding. I had to 
manually revert encoding of file to UTF-8 to successfully compile. I recommend 
primary developer to change his default encoding in Visual Studio settings and 
revert encoding of current files (if he is not able to do that, i can help - 
unix tool recode does thhat job in one minute).