Shift operator muse be "unified". about muparserx HOT 7 CLOSED

rev 198 fixes 15 << -2 = 3.75 issue.

Moreover, MSDN states that << behavior is "undefined" if right operang is 
non-positive, e.g. 15 << -2 results in undefined behavior. I think ecDOMAIN 
could suit such an situation pretty well.

Let me know your minds and i will implement then correct behavior:

1. right operand cannot be negativ -> ecDOMAIN
2. right operand is 0 -> left operand is returned
3. overflow detection which is done for << and >> does not need one.

The short answer would be: Please take Mathematica (Wolfram alpha as a 
reference), Matlab, Octave as a reference (all of them allow negative operands).

The more detailed Version is:
MSDN is refering to the C/C++ Standard. It merely means that the standard 
doesn't say anything about how compiler vendors should treat negative operands 
so they are free to do whatever they want. So a standard compliant 
implementation of c++ is allowed to crash and burn your system if it sees a 
negative operand. That doesn't necessarily make it a very good standard 
compliant compiler as there is nothing intrinsicly undefined in the problem 
itself.

I'd define the following set of requirements for shift operations that are as 
universal as possible (given the constraint of not having arbitrary precision):

- Shift operations work only with integer values
- the return value of a shift operation must represent an integer value and 
each digit of the return value must be known for sure as to allow conversion to 
a binary number. If this can't be guaranteed (and only then) an overflow 
exception should be raised.
- the operations a << b and a >> -b are equivalent
- the operations a >> b and a << -b are equivalent
- the first operand may be a negative number 

Here is my reasoning for this:
From a human perspective negative operands are pretty useless but so is 
shifting by 0 and if we forbade negative operands why not 0 too?. No human user 
should shift a value to the left by -2 because well, that looks pretty stupid. 
There is however nothing undefined to it i'm against imposing arbitrary 
restrictions to the domain. muparserx may end up being the backend of an 
application which may automatically generate expressions. Such an application 
may automatically create expression like "a << b" and as b is a variable it may 
end up being negative or even be required by an algorithm to be negative 
assuming a negative operand will reverse the shifting direction. A thought that 
is completely rational. If a domain error would be thrown despite being able to 
provide a result the client code would needlessly have to work around this 
issue.

Okay, now we have that - sign behavior more-or-less correct, have you tried my 
fix? it should work, works for me. :)

Yes, seems to work in general but there was a minor issue left with shifting 
negative values. I applied a minor fix in order to correct this. I think this 
was the last problem here so applied the code th shr as well to make sure both 
operators use the same logic.