RE: Data type of compiled expressions

Konstantin,

Thanks for your suggestions. The 3-argument compile is definitely what I
should be using and solves my problem (and a couple others) perfectly. It
had been quite a long time since I wrote the initial code using JEL so I
didn't think to look through the APIs again.

I do need to make use of the resolver interface, as I do some fairly complex
dynamic resolution. I simplified my example quite a bit.

I'm wondering if there are still performance improvements to be gained by
using the evaluate_int (for example) if I am going to construct a Java
object from the primitive or does this basically amount to the same as just
using evaluate?

Thanks and regards,
Mike.

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Konstantin L. Metlov
Sent: Thursday, November 28, 2002 4:34 AM
To: Mike Squance
Cc: '[email protected]'
Subject: Re: [Bug-jel] Data type of compiled expressions


Dear Mike,

Thank you for your message. I can assure you that I have no plans to
abandon JEL, it will remain supported by me for a long period of time.
In the worst case of circumstances beyond my control, anyone will be able
to take over my role, because JEL is Free Software and essentially all its
sources are released (there are no secrets). Should the worst happen I can
even transfer my copyright to the new reliable maintainer, so that he can
continue with the current business model.

The fact that there were no new releases for about 6 months is connected
with my feeling that JEL had reached a kind of feature saturation.  In my
CVS there are some changes, which reduce the size and improve performance
slightly more, but I just don't feel they are significant enough to
release a new version at this time. I'm also not aware of any bugs, should
one be found the new version will be released immediately.

In the situation you've described I'd say JEL behaves as intended (e.g. it
tries to preserve as much of the original types as possible). And, since
in the conditional there is no necessity to unwrap objects in order
determine the result type and to compile it -- unwrapping is not done. To
get the behaviour you want (e.g. to guarantee a certain result type, so
that you do not have to check it at all) it is better to use the
three-argument version of "compile". E.g. in your example replace

 expr=gnu.jel.Evaluator.compile("RAW2",lib);

by

 expr=gnu.jel.Evaluator.compile("RAW2",lib,Integer.TYPE);

This will make JEL convert the result into "int" automatically, and
generate a compile-time message if it can't (for example when expression
is "RAW1+1.5F"), suggesting the user to insert explicit type conversion
(e.g. "round(RAW1+1.5F)").

If you fix the result type, as described above, it becomes possible to use
.evaluate_int(...) method of your compiled expression directly with no
checks of .getType(). If you do so, the performance of your application
may increase significantly.

Also, if you have only a fixed set of variables (e.g. RAW1, RAW2 and no
more) -- it is possible to avoid using the so-called "Dynamic Variables
Interface" (e.g resolver) and just add them into a class as public members
of type "int", making that class a part of JEL's dynamic library. This way
the number object creations will be reduced, further improving
performance of your application.

If you may have a variable number of RAW variables of the same type it is
still possible to improve performance by placing them into an array (to be
accessed within expressions as RAW[0], RAW[1], etc...).

Thank you for your interest in JEL !

With the best regards,
                          Konstantin.





_______________________________________________
Bug-jel mailing list
[email protected]
http://mail.gnu.org/mailman/listinfo/bug-jel