From 10ee276c2796222021dd14cb6d630bcb776cd4ef Mon Sep 17 00:00:00 2001
From: Avik Sengupta
RPN tokens are mapped to Eval classes. (Class hierarchy for the Evals @@ -55,8 +55,7 @@ ValueEval objects which are set into the AreaEval and RefEval (ok, since AreaEval and RefEval are interfaces, the implementations of AreaEval and RefEval - but you'll figure all that out from the code)
-OperationEvals for the standard operators have been implemented and - basic testing has been done
+OperationEvals for the standard operators have been implemented and tested.
FunctionEval is an abstract super class of FuncVarEval. The reason for this is that in the FormulaParser Ptg classes, there are two Ptgs, FuncPtg and FuncVarPtg. In my tests, I did not see FuncPtg being used so there is no corresponding FuncEval right now. But in case the need arises for a FuncVal class, FuncEval and FuncVarEval need to be isolated with a common interface/abstract class, hence FunctionEval.
@@ -65,120 +64,124 @@So here is the fun part - lets walk through the implementation of the excel - function... AVERAGE()
+ function... SQRT()public Eval evaluate(Eval[] operands) {}
for (int i=0, iSize=operands.length; i<iSize; i++) {...}
if (operands[i] == null) continue;
singleOperandEvaluate(..)
to do conversions of different value eval types to one of: NumericValueEval,
+ BlankEval and ErrorEval. The conversion logic is configured by a ValueEvalToNumericXlator instance which
+ is returned by the Factory method: getXlator(..)
The flags used to create the ValueEvalToNumericXlator
+ instance are briefly explained as follows:
+ BOOL_IS_PARSED means whether this function treats Boolean values as 1,
+ REF_BOOL_IS_PARSED means whether Boolean values in cell references are parsed or not.
+ So also, EVALUATED_REF_BOOL_IS_PARSED means if the operand was a RefEval that was assigned a
+ Boolean value as a result of evaluation of the formula that it contained.
+ eg. SQRT(TRUE) returns 1: This means BOOL_IS_PARSED should be set.
+ SQRT(A1) returns 1 when A1 has TRUE: This means REF_BOOL_IS_PARSED should be set.
+ SQRT(A1) returns 1 when A1 has a formula that evaluates to TRUE: This means EVALUATED_REF_BOOL_IS_PARSED should be set.
+ If the flag is not set for a particular case, that case is ignored (treated as if the cell is blank) _unless_
+ there is a flag like: STRING_IS_INVALID_VALUE (which means that Strings should be treated as resulting in VALUE_INVALID ErrorEval)
Strings are ignored. Booleans are ignored!!! (damn Oo.o! I was almost misled here - nevermind). Actually here's the info on Bools: +
Strings are ignored. Booleans are ignored!!!. Actually here's the info on Bools: if you have formula: "=TRUE+1", it evaluates to 2. So also, when you use TRUE like this: "=SUM(1,TRUE)", you see the result is: 2. So TRUE means 1 when doing numeric calculations, right? Wrong! Because when you use TRUE in referenced cells with arithmetic functions, it evaluates to blank - meaning it is not evaluated - as if it was string or a blank cell. eg. "=SUM(1,A1)" when A1 is TRUE evaluates to 1. - So you have to do this kind of check for every possible data type as a function argument for any function before you understand the behaviour of the function. The operands can be entered in excel as comma separated or as a region specified like: A2:D4. Regions are treated as a single token by the parser hence we have AreaEval which stores the ValueEval at each cell in a region in a 1D array. So in our function if the operand is of type AreaEval we need to get the array of ValueEvals in the region of the AreaEval and iterate over each of them as if each of them were individual operands to the AVERAGE function. + This behaviour changes depending on which function you are using. eg. SQRT(..) that was + described earlier treats a TRUE as 1 in all cases. This is why the configurable ValueEvalToNumericXlator + class had to be written.
-Thus, since sometimes, Excel treats - Booleans as the numbers 0 and 1 (for F and T respectively). - Hence BoolEval and NumberEval both implement a common interface: - NumericValueEval (since numbers and bools are also valid string - values, they also implement StringValueEval interface which is - also implemented by StringEval).
-- The ValueEval inside an AreaEval can be one of: - NumberEval, BoolEval, StringEval, ErrorEval, BlankEval. - So you must handle each of these cases. - Similarly, RefEvals have a property: innerValueEval that returns the ValueEval at the referenced cell. The ValueEval inside a RefEval can be one of: NumberEval, BoolEval, StringEval, ErrorEval, BlankEval. So you must handle each of these cases - see how excel treats each one of them. -
- +Note that when you are extending from an abstract function class like + NumericFunction (rather than implementing the interface o.a.p.hssf.record.formula.eval.Function directly) + you can use the utility methods in the super class - singleOperandEvaluate(..) - to quickly + reduce the different ValueEval subtypes to a small set of possible types. However when + implemenitng the Function interface directly, you will have to handle the possiblity + of all different ValueEval subtypes being sent in as 'operands'. (Hard to put this in + word, please have a look at the code for NumericFunction for an example of + how/why different ValueEvals need to be handled) +
Automated testing of the implemented Function is easy. + The source code for this is in the file: o.a.p.h.record.formula.GenericFormulaTestCase.java + This class has a reference to the test xls file (not /a/ test xls, /the/ test xls :) + which may need to be changed for your environment. Once you do that, in the test xls, + locate the entry for the function that you have implemented and enter different tests + in a cell in the FORMULA row. Then copy the "value of" the formula that you entered in the + cell just below it (this is easily done in excel as: + [copy the formula cell] > [go to cell below] > Edit > Paste Special > Values > "ok"). + You can enter multiple such formulas and paste their values in the cell below and the + test framework will automatically test if the formula evaluation matches the expected + value (Again, hard to put in words, so if you will, please take time to quickly look + at the code and the currently entered tests in the patch attachment "FormulaEvalTestData.xls" + file). +