#4 Customer suggestions for Expression Evaluator enhancements

open
nobody
7
2013-01-15
2003-02-11
Anonymous
No

Exported from Bugzilla, issue 2928.

--- Comment added on 4/16/2002 1:53:45 PM ---
Customer writes:

Subject: TStExpression questions
Date: Tue, 16 Apr 2002 17:42:21 +0200

Dear TurboPower team,
I am using the SysTools 3.03(4) TStExpression component within the
recalculations of a numerical table.
Means a array of double gives some data and another array is calculated
using the TStExpression. In principle everything works fine, but I have
some questions left:

1. The expression can contain column data e.g A(1) for the first value
of the first column. The accessing function fill fire a EIndexOutOfRange
exception if the function is called with a wrong row number. But as I
call the AnalyzeExpression only a "numeric error" is fired. It would be
very helpful if the original cause for those errors would be handed over
by the error handler of the Expression unit.

2. It would be nice if one could register functions with same name but
different count of parameters e.g. "A" for the "cell with current row"
and the one above as cell with specified row. It is possible to add a 0
parameter function and a 1 parameter function with the
TStExpression.AddFuction… but with calling the 1 parameter function a
expression error is fired. It would be easy for the parser to detect if
a "(" is following the name identifying 0 and 1 parameter functions.
Thus why this error?

3. The AnalyzeExpression always is parsing the expression creating the
call stack and deriving the result. It would be nice if one could add
functionality for consecutive calls. E.g. in the above table example the
expression will not change, but be called for lots of data. Thus it
would be nice to have separate calls for e.g. "ParseExpression" and
"GetExpressionResult". This would speed up the processing time
enormously.

--- Comment added on 6/6/2002 4:18:37 PM ---
> 1. The expression can contain column data e.g A(1) for the first value
> of the first column. The accessing function fill fire a EIndexOutOfRange
> exception if the function is called with a wrong row number. But as I
> call the AnalyzeExpression only a "numeric error" is fired. It would be
> very helpful if the original cause for those errors would be handed over
> by the error handler of the Expression unit.

There's nothing built into the Expression Evaluator to distinguish
row-column data such as you describe, how have you implemented that?
Are you treating it as a custom function taking one parameter?

> 2. It would be nice if one could register functions with same name but
> different count of parameters e.g. "A" for the "cell with current row"
> and the one above as cell with specified row. It is possible to add a 0
> parameter function and a 1 parameter function with the
> TStExpression.AddFuction… but with calling the 1 parameter function a
> expression error is fired. It would be easy for the parser to detect if
> a "(" is following the name identifying 0 and 1 parameter functions.
> Thus why this error?

What you're asking for is called "function overloading" in the lingo of
programming language interpreters or compilers.

Offering such a feature involves "delayed interpretation" of tokens
parsed from the expression. The Evaluation Engine doesn't presently
include much support for that.

I'll look into what might be involved in providing the feature, but I
can't say that seems like a high priority.

> 3. The AnalyzeExpression always is parsing the expression creating the
> call stack and deriving the result. It would be nice if one could add
> functionality for consecutive calls. E.g. in the above table example the
> expression will not change, but be called for lots of data. Thus it
> would be nice to have separate calls for e.g. "ParseExpression" and
> "GetExpressionResult". This would speed up the processing time
> enormously.

Providing something like you suggest would involve persisting the
"evaluation tree" in some fashion with variable references intact.

Presently the Evaluation engine performs variable replacement in-line as
the expression is parsed, there's no provision for keeping track of
variables within the context of an unevaluated expression; further the
engine discards parts of the expression it is done with (to conserve
memory) as it evaluates.

Discussion


Log in to post a comment.