Re: [Bug-jel] Data type of compiled expressions

[Konstantin L. Metlov]

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.