You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The handling of numbers types could be more tollerant/intelligente. Not only casting to double. This could be used for easy and simple formulas, without the neet of a exact type casting.
For example it could cast automatically to the type given in the generics. And it could detect floating point and integer types. And the parser could detect as good as possible what type is needed.
Like for example
evaluator.Evaluate<double>("123 + (255 << 4) + -0b11 * 0.5")
Automatically to
evaluator.Evaluate<double>("(double)( (double)123 + ((ulong)255 << (int)4) + (long)-0b11 * (double)0.5 )")
or
evaluator.Evaluate<int>("123 + (0xff << 4) + -0b11 * 0.5")
Automatically to
evaluator.Evaluate<int>("(int)( (ulong)123 + ((ulong)0xff << (int)4) + (long)-0b11 * (double)0.5 )")
? Maybe even this, by simply use the integer part? With the hope that the user know what he is doing.
123 & 2.5
Or
125.5 << 2.5
The text was updated successfully, but these errors were encountered:
The handling of numbers types could be more tollerant/intelligente. Not only casting to double. This could be used for easy and simple formulas, without the neet of a exact type casting.
For example it could cast automatically to the type given in the generics. And it could detect floating point and integer types. And the parser could detect as good as possible what type is needed.
Like for example
The text was updated successfully, but these errors were encountered: