Author Topic: Math operations in module system  (Read 2297 times)

Offline Winter

  • I am Tek Jansen!
  • Administrator
  • *****
  • Posts: 476
  • MBX Forum owner
    • View Profile
    • Street of Eyes: The Writing of Ryan A. Span
Math operations in module system
« on: September 27, 2007, 10:09:08 AM »
The maths ones I can do you, Winter - which ones are you concerned with?

As for the damage model, Ron, I assume you caught the bit where Armagan said he was changing the armour metrics in the new version (cf. here), and that since you mention testing on dummies this isn't the issue here.  Perhaps he's put in a multiplicative effect on Strength or something, to go with this?

All the new ones that got introduced, apart from sin cos and tan. I have recently learned basic trigonometry. :P

Offline Hellequin

  • Journeyman
  • ***
  • Posts: 254
    • View Profile
Math operations in module system
« Reply #1 on: September 27, 2007, 11:33:50 AM »
Sure.

By my count that's val_clamp, val_abs, store_sqrt, and store_pow.  The fixed_point stuff isn't clear to me as yet, but I'll touch on it at the end.

val_clamp - This operation takes a value and forces it into a range.  Whatever values the first argument may have had before, after the val_clamp it will be no lower than the second argument (the minimum value) and it will be strictly less than the third argument (the maximum value).  This is 100% equivalent to calling (val_min, <value>, (<upper_bound> - 1)), then (val_max, <value>, <lower_bound>).

val_abs - Absolute value.  If <value> is positive or zero, it's unchanged.  If negative, the negative sign is stripped off, and the result (now positive) is returned.

store_sqrt - Square root.  Stores the square root of the second argument.  Note that this uses "fixed point" values, see below.

store_pow - Power or exponent.  The comment in module_operations is incorrect for this - it's a copy-paste from store_sqrt above it.  Raises one value to the power of a second value.  The last argument is the exponent - the power - and the middle one is the base - the thing being squared, cubed, or otherwise exponentiated.  Thus for example (store_pow, ":result", 5, 2) would put 25 into the result var - five squared.*  If the last argument had been three instead, the result would be 125 - five cubed.
*[With a fixed_point_multiplier of 1 (the default), technically.  You almost certainly don't want to ever use this operation with fixed_point_multiplier set to any other value unless that turns out to enable decimal values, and even then with extreme care.  For example, 5^2 (= 25) is hardly equivalent to one-tenth of 50^20 (= almost 10 million billion billion billion)!]


As I said, fixed_point_multiplier is unclear to me.  I'm still figuring out exactly how Armagan's using it.  It appears to be a way to affect how much precision you obtain from various activities like square roots and position_get_x calls.  For instance, it's clear that with a multiplier of 1, we're talking integer math and positions in meters, not centimeters.  (I'm picturing ported Schattenlander potions flying kilometers away unless I get this right!)  Thus if I were standing 275cm in Y from a scene prop, called a pair of (position_get_y) and subtracted them, I'd get an answer of 2.  If I asked for the square root of twelve I'd get three.  It appears that a fixed point multplier higher than this is used to get better precision, mostly for intermediate calculations since ultimately we still need an integer value.  If I set the multiplier to 100 and did those two operations again, I'd get 275 from the position_y subtraction, and... um... 346 from the square root (root 12 = 3.64).  In either case, if I didn't do anything else with it and just ran convert_from_fixed_point on my answer, the influence of the multiplier would go away; I'd end up with 2 and 3, respectively, again.  What this lets us do, though, is add (say) a pair of square roots together, and lose less of our rounding in the process.

I think.

Offline Winter

  • I am Tek Jansen!
  • Administrator
  • *****
  • Posts: 476
  • MBX Forum owner
    • View Profile
    • Street of Eyes: The Writing of Ryan A. Span
Re: Math operations in module system
« Reply #2 on: September 28, 2007, 03:35:24 AM »
val_clamp - This operation takes a value and forces it into a range.  Whatever values the first argument may have had before, after the val_clamp it will be no lower than the second argument (the minimum value) and it will be strictly less than the third argument (the maximum value).  This is 100% equivalent to calling (val_min, <value>, (<upper_bound> - 1)), then (val_max, <value>, <lower_bound>).

So what exactly will the value be after val_clamp? A random number within lower_bound, upper_bound? Or will it be lower_bound if lower or upper_bound if higher?

Also, where would you use a val_clamp? I'm not seeing any particular application in my scripts yet.

Regards,
Winter

Offline Hellequin

  • Journeyman
  • ***
  • Posts: 254
    • View Profile
Re: Math operations in module system
« Reply #3 on: September 28, 2007, 09:11:32 AM »
Your second option proferred - it'll be equal to lower bound if lower than that, it'll be the value unaltered if it's between lower and upper bounds, and it'll be the upper limit (upper bound minus one) if it's at the upper bound or beyond.

To pick an example usage:  You have a script which selects a merchant at random from the merchants list.  However, not all merchants are created equal, you've got 'em ordered by nicest to nastiest, and some towns have a modifier (tend to have a nicer or nastier merchant than the norm).  One way to do that would just be:

(store_random_in_range, ":merch", merchants_begin, merchants_end),
(party_get_slot, ":modifier", "$g_encountered_party", merchant_qual_modifier_slot),
(val_add, ":merch", ":modifier"),
(val_clamp, ":merch", merchants_begin, merchants_end),

It's handy because it means that instead of maintaining careful "data range integrity" throughout a series of operations, reasoning out by what means it could escape its expected bounds and covering those individually, we can insert one operation and ensure that it'll produce an answer in the range we're looking for.

Offline Winter

  • I am Tek Jansen!
  • Administrator
  • *****
  • Posts: 476
  • MBX Forum owner
    • View Profile
    • Street of Eyes: The Writing of Ryan A. Span
Re: Math operations in module system
« Reply #4 on: October 12, 2007, 06:19:44 AM »
store_pow - Power or exponent.  The comment in module_operations is incorrect for this - it's a copy-paste from store_sqrt above it.  Raises one value to the power of a second value.  The last argument is the exponent - the power - and the middle one is the base - the thing being squared, cubed, or otherwise exponentiated.  Thus for example (store_pow, ":result", 5, 2) would put 25 into the result var - five squared.*  If the last argument had been three instead, the result would be 125 - five cubed.
*[With a fixed_point_multiplier of 1 (the default), technically.  You almost certainly don't want to ever use this operation with fixed_point_multiplier set to any other value unless that turns out to enable decimal values, and even then with extreme care.  For example, 5^2 (= 25) is hardly equivalent to one-tenth of 50^20 (= almost 10 million billion billion billion)!]


As I said, fixed_point_multiplier is unclear to me.  I'm still figuring out exactly how Armagan's using it.  It appears to be a way to affect how much precision you obtain from various activities like square roots and position_get_x calls.  For instance, it's clear that with a multiplier of 1, we're talking integer math and positions in meters, not centimeters.  (I'm picturing ported Schattenlander potions flying kilometers away unless I get this right!)  Thus if I were standing 275cm in Y from a scene prop, called a pair of (position_get_y) and subtracted them, I'd get an answer of 2.  If I asked for the square root of twelve I'd get three.  It appears that a fixed point multplier higher than this is used to get better precision, mostly for intermediate calculations since ultimately we still need an integer value.  If I set the multiplier to 100 and did those two operations again, I'd get 275 from the position_y subtraction, and... um... 346 from the square root (root 12 = 3.64).  In either case, if I didn't do anything else with it and just ran convert_from_fixed_point on my answer, the influence of the multiplier would go away; I'd end up with 2 and 3, respectively, again.  What this lets us do, though, is add (say) a pair of square roots together, and lose less of our rounding in the process.

I think.

You know, from watching fixed_point_multiplier used in the code and with the info in header_operations, it really does look as if it's just for enhancing maths precision (i.e. saving decimal values from rounding).
« Last Edit: October 12, 2007, 06:25:06 AM by Winter »