Missing logic and math operators

[bar0n3ashura]

Hello,
I finally had the time to get back to my goal of integrating muParser into an existing application.
A few months back I needed to extend the value type with a timestamp, which was successfully achieved by defining a sample class type with a value and timestamp, then adding a using clause like as follows:
using value_type = Sample;
This allowed me to get the help from the compiler to identify all the math operators and functions that needed to be adjusted to compute values correctly, and to be in the position to later define operators taking time as an input for computation as well as the value.

Now I started checking what the library itself provides in terms of ready-made operators and functions, and noticed that some 'basic' operators are not available.
So far, I already added the logical not operator '!' by invoking DefineInfixOprt and defining the corresponding function in MathImpl, and it works fine; today I noticed that:

• '&'/'|' bitwise AND and OR, are not defined, as builtin operators, although they appear in enum EOprtPrecedence
• '^' is used for power, but I would prefer it to be bitwise XOR
• '%' modulus operator is not available

Questions time :)
Is there a reason, other than indivdiual choice, for the above operators to be missing in the list of builtin operators?
Is there any advice in adding such operators? Better to add them as DefineOprt, or better to tamper the library code to extend the list of built-in operators?

I am also going to repeat myself: I really like the library as it is. I still prefer sticking with muParser rather than muParserX, due to the highlighted better runtime performance. I MAY consider in the future trimming some code inside the library for features I definately will not need, although such features are useful for a library with larger goals.

Thanks for your attention

Have a Nice Day :)

[beltoforion]

Some operators may not be available because everyone has a different preference or need. Binary operators are not supported because the underlying default type is a floating point value. Bitwise operators do not work on floating point values.

muparser does not have a type system and cannot check wether a given equation makes sense. To be absolutely save one would need to introduce an int function and make sure binary operators can only be applied to the output of the int function. That looks odd in an equation. Alternatively one could implement the binary operator in a way that it simply converts the parameters to int. If you do this do not use (int) casting because your input may be something like "9.9999999999997". You dont want to truncate that to 9. Use a round function instead.

In short its a can of worms i did not want to open in muparser because there is no satisfying solution. I put that solution into muparserx. However if anyone else wants to open that can of worms they would still need a different operator precedence so I added it.

[bar0n3ashura]

Thanks for the reply

I agree on everything.

Just a quick note about bitwise operators and floating point values: I am using double as the underlying default type, which is supposed to support up 53 bits of mantissa with exponent value 0. This means that:

• I could support bit-wise operators for u32 numbers, through the simple cast.
• I cannot support bitwise operators for 64 bit integer numbers.

In our limited and controlled scenario, bitwise operators (eventual functions) will include a simple check to ensure that arguments are greater than 0 and lower that the largest u32 value; if check fails, exception will be thrown.

I already wrote a quick test to verify that in each architecture where code might be deployed, the expected double to u32 cast actually works as expected.

[bar0n3ashura]

PS. I usually try my best to make sure that I dont make mistakes and I dont overlook things. This often leads me to ask for confirmations... if you wish not to be disturbed, in the future I will restrict myself from asking further questions and/or advice about muParser library :)

Thanks Again! :D

[beltoforion]

Please feel free to keep asking questions, after all this is what this discussion forum is for. There is absolutely nothing wrong with that. I just cannot guarantee that I am able to reply in a timely manner or at all. But even if I cannot respond other people may be seeing your post and be able to respond.

You figured out the limitations on your own and I agree that you can create a safe implementation if you add the apropriate checks. That is probably the best way to proceed.