[ET Trac] [Einstein Toolkit] #798: allow calculations in parameter assignments in parameter files

[Einstein Toolkit]

#798: allow calculations in parameter assignments in parameter files
--------------------------+-------------------------------------------------
  Reporter:  rhaas        |       Owner:        
      Type:  enhancement  |      Status:  review
  Priority:  optional     |   Milestone:        
 Component:  Cactus       |     Version:        
Resolution:               |    Keywords:        
--------------------------+-------------------------------------------------

Comment (by rhaas):

 The expression code uses a macro to actually do the math, so I have to use
 the same operator/function for both integers and reals. The way that it is
 written right now, it ends up being:
 {{{
 int retval = fmod(a,b)
 }}}
 if both a and b are of integer type. This is identical to a%b I think
 since C will automatically truncate the double to an integer. It actually
 has the the added benefit that it does not have the implementation defined
 behaviour for b<0 that a%b has. If any of a or b is real then retval is a
 double value.

 I could use {{{**}}} for exponentiation I think, but it might require a
 bit of rewriting. Right now I don't have to distinguish between {{{*}}}
 and {{{**}}}}, all operators are uniquely determined by a single character
 (even {{{&&}}} and {{{||}}}). I don't believe that this assumption is
 hard-coded anywhere but would have to test. Probably straightforward.

 The way that the macros are written, they don't support two-argument
 functions. All functions are treated as unary operators. Adding two
 argument functions will require changing the reverse polish notation
 generator and evaluator since the meaning of parenthesis changes depending
 on whether they follow a two-argument function or not (right now there is
 no difference between parenthesis around function arguments and just
 grouping ones).

 -inf is supported (it ends up as -(inf) I think since I only group the -
 sign with numbers).

 No bitwise operations are supported (mostly because the macro would balk
 at {{{((double) a) & ((double) b)}}} ({{{!}}} is the boolean not). {{{&&}}
 and {{{|||}}} are supported (and documented :-), even though the majority
 of this functionality existed in Cactus before but was only used for the
 accumulator parameters).

 I use '_' and '@' in the table since I need to encode each operator as a
 string for the RPN parser (which translates them into the OP_XXX codes).
 '_' is the unary '-' and '@' is the unary '+'. I cannot leave them '-' and
 '+' since the RPN generator looks only at the token string not at context.
 Having the replacement the same length as the original makes live simpler
 (this is reason for the horrible use of a hard-coded state '10' in 594).

 I like the suggestions and am impressed you actually waded through the
 code.

 So in order is time to implement from little work to a bit of work:

 1. {{{&}}} and {{{|}}} if we can live with a cast to (long int) for the
 double's
 1. {{{^}}} -> {{{**}}} this would free {{{^}}} for the bitwise exlusive or
 1. test cases
 1. two-argument functions, requires some changes to parenthesis handling
 (different behaviour after name or after operator), and likely some new
 type of binary operator and code to handle it in the RPN generator.

 I am sure there are fully featured evaluators out there (in fact GNU
 libmatheval comes to mind, which even features derivatives), though that
 might be overkill.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/798#comment:13>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit