88 replies to this topic

[i30817]

If you're doing all that for strings you are implementing a (probably buggy, no offense), parser and interperter on top of the other.

I think that if you're going to use muParserSSE for the maths (and it seems the right choice) should add a EvalString trigger for your string variables so there is "single responsability" for the functions.

You can setup this trigger based on printf ⁻ without the variable number of arguments, so you'd need to use assign as a replacement for those.
EvalString("@1, @1 and @2")
All the variables used in those would be assumed to be strings so could even be referenced by another symbol (and have a different "variable array") - unsure if it needs position since it there is only one string allowed in triggers?
If you want to use a number here from something that is naturally parsed as a int (say a e[3+5] on a assign), using the STR mode on the assign will try to convert to string and put it the string pool.

0x411A Assign(S:Statement*,I:Type*ArgType,I:Local*)
0x411B Eval(S:Expression*, /*maybe I:Type*ArgType */,I;Loc*)
0x411C EvalString(S:String* /*maybe I;Loc* */)

Leave the Eval only for int and math expressions. You can use them with strings anyway with e[] on the assignment, if STR Mode on Assign will try to convert to string.
Isn't it better?

If you want Eval("something", y), where y is the argument number from the trigger to replace, and "something" is a string type:
-First, the library must parse the "something"

No longer needed with the other scheme above, just straightforward string expansion. For the int expressions, sure, but that would happen anyway.

-Second, I have to search ahead
-Third, I need to check if the argument exists
...
-Finally, if type is valid, I will modify the value

Yes

-Fourth, I need to parse the trigger construction to check type

Table of TRIGGER.IDS names and arguments types built at startup?

Edited by i30817, 02 May 2012 - 04:32 AM.

[Ascension64]

I think that if you're going to use muParserSSE for the maths (and it seems the right choice) should add a EvalString trigger for your string variables so there is "single responsability" for the functions.

There is an issue with muParserSSE in that the .dll requires Visual C++ redistributables to be supplied. MathPresso requires AsmJit.dll. For this implementation, what useful features does one have over the other?

0x411A Assign(S:Statement*,I:Type*ArgType,I:Local*)
0x411B Eval(S:Expression*, /*maybe I:Type*ArgType */,I;Loc*)
0x411C EvalString(S:String* /*maybe I;Loc* */)

Leave the Eval only for int and math expressions. You can use them with strings anyway with e[] on the assignment, if STR Mode on Assign will try to convert to string.
Isn't it better?

It really is the same. Your EvalString("foo", x) would behave exactly the same as my Eval("foo", STR, x).

No longer needed with the other scheme above, just straightforward string expansion. For the int expressions, sure, but that would happen anyway.

Really just the same as my Eval("foo", INT, x). Note that even with your method, a special case needs to be made for something like your Eval("@1", x).

Table of TRIGGER.IDS names and arguments types built at startup?

If you sorely want some trick to make the .BAF code look easier, it is simple enough for the_bigg to implicitly identify which argument and which type you want when you put the Eval() inside of another trigger. Just as effective pre-processor-wise

Edited by Ascension64, 02 May 2012 - 05:03 AM.

[i30817]

There is an issue with muParserSSE in that the .dll requires Visual C++ redistributables to be supplied. MathPresso requires AsmJit.dll. For this implementation, what useful features does one have over the other?

Just making the observation that neither has strings, string operators or functions operating on strings.
But muParserSSE does have lots of useful functions (and the min and max operators). It doesn't look like mathpresso has any embedded functions.

Really just the same as my Eval("foo", INT, x). Note that even with your method, a special case needs to be made for something like your Eval("@1", x).

The string evaluation library would just return a error since the variable would not be recognized since it's memory location wasn't registered (since it's a string).

I understand now why you're going with the 2nd argument - it just bugs me that different types of substitution will use the same function although they do different things.

Edited by i30817, 02 May 2012 - 08:57 AM.

[i30817]

Just thought of something rather nice muParserSSE seems to have that mathpresso doesn't beside the functions - boolean expressions.
Sure, you can use the E, LT and GT triggers for that too, no problem - and maybe it's better to go barebones if it requires additional dlls, your choice.

edit: and if you use the svn here (can compile it):
http://muparser.svn....443&view=markup

it also has if then else " a < b ? a : b" and && and || operators.
edit2: seems like it was added and removed. bah.

Edited by i30817, 02 May 2012 - 10:12 AM.

[Ascension64]

Just making the observation that neither has strings, string operators or functions operating on strings.

Fair enough. I think both try to treat strings as some variable, and hence an undefined variable error results. Yet to test though.

But muParserSSE does have lots of useful functions (and the min and max operators). It doesn't look like mathpresso has any embedded functions.

MathPresso doesn't have all that much documentation, but it has the following functions (and the ability to define a certain amount of custom functions):

• min(x, y), max(x, y), avg(x, y)
  
• ceil(x), floor(x), round(x)
  
• abs(x)
  
• reciprocal(x)
  
• sqrt(x), pow(x, y)
  
• log(x), log10(x)
  
• sin(x), cos(x), tan(x), sinh(x), cosh(x), tanh(x), asin(x), acos(x), atan(x), atan2(x)

Also, MathPresso does not implement the ^ and % operators. Someone has since made a doublepresso fork that includes these operators.

I understand now why you're going with the 2nd argument - it just bugs me that different types of substitution will use the same function although they do different things.

Sort of. While the treatment for int and string differs, both functions still replace some argument in the next valid trigger.

Just thought of something rather nice muParserSSE seems to have that mathpresso doesn't beside the functions - boolean expressions.
Sure, you can use the E, LT and GT triggers for that too, no problem - and maybe it's better to go barebones if it requires additional dlls, your choice.

Not sure where you would use boolean expressions. Eval() doesn't itself cause the trigger block to be true or false.

[i30817]

yeah, you're right about the boolean expr, since there is no trigger that takes a 0 and returns false and 1 and returns true (or whatever's the convention) - that's why i thought a new isTrue trigger a good idea (but only if the library supports boolean expr).

If "a < b" etc, returns a int you could maybe compare it to 0 with EQ. What really hurt was no functions and the "x ? a : b" construct (which would be very useful!), though i don't think it's finished in the muParserSSE svn (i haven't tried it or tried to compile, it's only the changelog that says it's there, but i didn't see any obvious function in the parser source file).

So if you say it's easy to add functions to mathpresso (also to the other i guess), it makes no major difference.
% is useful though - if you can't use the fork, a function for the same thing would be nice.


Are you going to try some kind of performance test? I worry that jits are supposed to be used with code caches. Maybe mathpresso has a simple one, (probably) not. It's possible they are only faster than a straight interpreter if you have some kind of caching - they even mention that changing the arguments requires recompilation (which is what worries me, you'll be always recompiling when there's actually no need most of the time). If it was only the expression that required compilation, a cache would be "easy", just map locations to compiled code. As it isn't, you could maybe replace the strings by real values (concrete) values, make that string a key for a compiled code, and use that as cache -> when the arguments change -> requires recompilation (and clearing the old value somehow).
Only maybe the library is already doing what i said above under the covers...

BTW:

reciprocal(x)

doesn't inspire me with confidence if the author couldn't add unary operators to his parser.

Edited by i30817, 03 May 2012 - 07:10 AM.

[Ascension64]

The current description of the two triggers.

0x411A Assign(S:Statement*,I:Type*ArgType,I:Local*)
Assigns a value determined by Statement of the type Type from ARGTYPE.IDS (INT integer, or STR string) to a local trigger block variable
The general form of Statement is "prefix[params]"

"prefix" can be:
* 'c' - assigns a constant value; params is a number, e.g. c[1], or string, e.g. c[FOO]
* 'e' - assigns the value of an expression; params is an expression, e.g. e[6 + 7]; see 0x411B Eval() for the format of Expression
* 'id' - assigns the index of a IDS file value; params is file.value, e.g. id[EA.CHARMED]
* 's' - assigns the value of the stat specified of the current object; params is the stat name, e.g. s[LEVEL]
* 'tn' - assigns the value of a 2DA file value by coordinates; params is file.x.y, e.g. tn[IMPORT01.0.0]
* 'ts' - assigns the value of a 2DA file value by column and row name; params is file.column.row, e.g. tn[IMPORT01.ITEMS.1]
* 'v' - assigns the value of a variable; params is name.scope, e.g. [foo.GLOBAL]

"params" values containing #<num> and @<num> are replaced by the integer and string values, respectively, stored in local trigger block variables of index "num"
The range of "num" is 0 to 24

This trigger does not evaluate and does not count as a trigger in an OR() block

0x411B Eval(S:Expression*,I:Type*ArgType,I:Loc*)
Overwrites the (Loc)th argument of type Type from ARGTYPE.IDS (INT integer, or STR string) in the next trigger with the value returned by Expression
Expression is a math expression that can use the following symbols:
=+-*/%^()
min(x, y), max(x, y), avg(x, y)
ceil(x), floor(x), round(x)
abs(x)
reciprocal(x)
sqrt(x), pow(x, y)
log(x), log10(x)
sin(x), cos(x), tan(x), sinh(x), cosh(x), tanh(x), asin(x), acos(x), atan(x), atan2(x)

Any text in Expression of form #<num> and @<num> is replaced by the integer and string values, respectively, stored in local trigger block variables of index "num"
The range of "num" is 0 to 24

This trigger does not evaluate and does not count as a trigger in an OR() block
This trigger does not overwrite values of the OR(), NextTriggerObject() and Assign() triggers
This trigger does not cancel the NextTriggerObject() trigger

Edited by Ascension64, 05 May 2012 - 03:01 AM.

[i30817]

Hmmm?
"* 'c' - assigns a constant value; params is a number, e.g. c[1], or string, e.g. c[FOO]"

Why? Isn't putting that constant on the right Eval equivalent?
You forgot to mention that a @var can't be used in a INT eval or a math expression on a String Eval (without doing it in the assignment anyway).


edit: = symbol ... interesting, mathpresso has assignments.

Edited by i30817, 06 May 2012 - 02:37 AM.

[Ascension64]

Hmmm?
"* 'c' - assigns a constant value; params is a number, e.g. c[1], or string, e.g. c[FOO]"

I kept it in mainly for easy testing. It doesn't have much practical use. I can get rid of it once I'm happy with the way things work.

You forgot to mention that a @var can't be used in a INT eval or a math expression on a String Eval (without doing it in the assignment anyway).

True. Currently a warning is spurted but TobEx will try to make a type conversion.