Suggested enhancements and possible bug(s)

Mar 28, 2010 at 11:28 PM
Edited Mar 28, 2010 at 11:34 PM

Hi Sébastien,

   Firstly a big thankyou for making an excellent utility (I can see it saving me literally weeks of work).
  
I hope to use the expression evaluator to evaluate boolean expressions in a Forest modelling application.

Suggested Enhancements

1. I altered the grammer very slightly in NCalc.g so that identifiers can contain dots (i.e. '.'). For example in my application it would be possible for users to enter an expression of the form:

      Tree.height > 50 or Tree.diameter > 100
  
   This is not a big deal but is more natural way of specifying attributes on a certain entity (i.e. Tree in the example above).

   Also it is more consistent with the grammer for NAMES which allows dots (or any character between square brackets).
  
   The change to the grammer was :

ID
 :  LETTER (LETTER | DIGIT | '.')*
 ;

Unfortunately I was not able to run the unit tests to verify that I hadn't broken any existing functionality.

The NCalc.Tests didn't seem to be included in the source download - is this intentional?

2. Another enhancement (which I have not made but which would be very useful) is to enhance error handling so that if an expression is invalid it is possibly for a developer to position the cursor on and/or highlight the part of the expression which is in error. Also it would allow the developer to build the error message which is displayed to the user (for example the curent error message includes the line number but in my case the expression is always just a single line so in my cas the line number is unnecessary). Maybe the Error property on the Expression class could return an instance of an error class which in turn has a line number and character number properties (as well as a string error message property). I realise that this is not always possible, but would be very useful when it is.

It would also be great if the EvaluationException class had the same properties.

3. Another nice to have would be if the 'in' function was instead a binary operator so you could write expressions of the form :

      if( 1 in [1,3,5], true, false )

 

Possible Bug(s)

The following expressions don't seem to be handled as I would expect:

1. 'abc' * 2

   I get the exception :
   System.FormatException: Input string was not in a correct format.
    at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolea n parseDecimal)
    at System.Number.ParseDecimal(String value, NumberStyles options, NumberFormatInfo numfmt)
    at System.Decimal.Parse(String s)
    at NCalc.Numbers.ConvertIfString(Object s) in D:\NCalc\Evaluant.Calculator\Numbers.cs:line 13
    at NCalc.Numbers.Multiply(Object a, Object b) in D:\NCalc\Evaluant.Calculator\Numbers.cs:line 408
    at NCalc.Domain.EvaluationVisitor.Visit(BinaryExpression expression) in D:\NCalc\Evaluant.Calculator\Domain\EvaluationVisitor.cs:line 156
    at NCalc.Domain.BinaryExpression.Accept(LogicalExpressionVisitor visitor) in D:\NCalc\Evaluant.Calculator\Domain\BinaryExpression.cs:line 40
    at NCalc.Expression.Evaluate() in D:\NCalc\Evaluant.Calculator\Expression.cs:line 274
    at NCalc.Play.Program.Main(String[] mainArgs) in D:\NCalc\Evaluant.Calculator.Play\Program.cs:line 31

 I would expect operators which only can be applied to numeric values to detected and an appropriate error message given (ideally identifying the value in error).
 
2. true + 2

   I get null returned from the Expression.Evaluate() method.

   I would expect that an exeption to be thrown as I am mixing incompatible types with the '+'


Thanks,
Joel.