Integration Questions

[Colin Doncaster]

Hi there -

Thanks for releasing this great little library, I had a few integration questions based on how we might use it in place of our own expression library.

Is there any way of doing a preflight evaluation of an expression to know what variables it might use/need? For example, if a user enters

$x + $y + 1

it would be nice to be able to evaluate an expression, if it's inValid it could return a list of missing variables. I would see this as an optimization for a system like ours where an expression might rely on a variable that is the result of some dependency, but I only really want to evaluate that dependency when it's actually needed.

I also couldn't help notice that your GUI uses a curve input to set values in the expressions - is this a two way street? If the expression is updates does the UI widget know and update it's values? If so, how would I query an expression to find out a specific values, is there a function that returns a SeExpr::SeCurve?

Is there any sort of SIMD optimization or would this fall outside the scope of how SeExpr should be used? Or have you found it's speed to be sufficient for most of the data sets you're working with?

Cheers,
Colin

[brentb]

On May 11, 6:55 am, Colin Doncaster <colin.doncas...@gmail.com> wrote:
> Is there any way of doing a preflight evaluation of an expression to know what variables it might use/need?

> it would be nice to be able to evaluate an expression, if it's inValid it could return a list of missing variables.

To implement vars you must override the resolveVar function which is
called during parsing. GIven that, you can easily just keep track of
the vars in your implementation. Alternatively, you can call the
usesVar() method after the fact. There's no method currently to get
the list of var refs, but it would be easy to add.

> I also couldn't help notice that your GUI uses a curve input to set values in the expressions - is this a two way street?  If the expression is updates does the UI widget know and update it's values?

Yes, the UI updates both ways. We parse the expression whenever the
text changes to find editable local vars and build widgets to match
that. When the widget is manipulated, we then do surgery on the
expression text based on positional info determined during parsing.
This parsing currently using simple regex logic that is specific to
the UI and is outside the expression library. We're considering
adding support to the SeExpression class to do this sort of parsing-
for-editing natively.

> Is there any sort of SIMD optimization or would this fall outside the scope of how SeExpr should be used?  Or have you found it's speed to be sufficient for most of the data sets you're working with?

In our applications the speed has generally been quite good but
there's certainly room for improvement and there are times when we'd
like it to be faster, e.g. when we're doing expressions per particle
per shading point (or volume step) in our particle renderer we need
all the speed we can get. We don't currently do SIMD and we don't
match native C++ performance. We're experimenting with native code
gen using LLVM and we're considering other ways to optimize things.