Re: GDL Notice: Arithmetic Operators / Quasi-Formulae

[Eric McDonald <mcdonald at phy dot cmich dot edu>]

Hello Xconq Game Designers,

On Mon, 2004-06-21 at 00:46, Eric McDonald wrote:

>     (village (food orc-food) ((+ 50 (- 200 50)) (/ 0 100)))

>  In the last 4
> declarations, all of the storage capacity for 'orc-food' is always 100,
> despite the different methods of calculating it.

Not quite true. The first of the last four (included above) actually
yields an 'orc-food' of 0, not 100.

>   Some things to note:
> (1) I still consider this experimental. Although my testing did not
> reveal any bugs (__well, it did, but I fixed them :-), there may be some
> lurking in the code that handles the operators. Please kick the tires
> some and tell me what you think about it.

I fixed the problem that I mentioned earlier.
  (- x (y z))
actually was fine, but:
  (- (y z) x)
and:
  (- (a b) (c d))
were not. But, they are now fixed.
Unless someone finds a bug with this stuff, I am going to consider it
official.

> (3) There is no limit on the number of operands that can be supplied to
> the operators.

For example:
(village food (+ 50 50 75 25))   ; evaluates to 200
(define HUMAN_BURDEN_CAP (/ 400 5 2 1 1))       ; evaluates to 40

> (9) The "bell" (not yet added) is "(- n)", which will decrement n by 1.
> (10) The "whistle" (not yet added) is "(+ n)", which will increment n by
> 1.

These have now been added and work fine. Here is a frivolous example:
(define VILLAGE_STORAGE_MULT (+ (- 5)))         ; evaluates to 5
   ; because 5 - 1 = 4, and then 4 + 1 = 5

> (13) Lists and individual numbers can be mixed freely. Again, the only
> constraint is that the lengths of all the lists must match.

For example:
(village (food orc-food) (/ (1000 500) 5))	; evaluates to (200 100)
(village (food orc-food) (/ (1000 1000) (5 0.10)))
   ; evaluates to (200 100)

Note that 0.10 is treated as 10 by Xconq internally. 10 = 0.10 = 10% in
the world of Xconq. Similarly, 400 = 4.00 = 400%. My point is that the
GDL math expressions can contain these kinds of numbers (decimals and
percents); just be aware of what internal values they really represent.

> (14) Doing math on dice specs is not recommended with this set of
> operators. They treat dice specs like normal integers (> 16384), and
> will likely screw with your dice specs in ways that you might not
> imagine.

Documentation is forthcoming. I will start with extremely simple
examples and progress to advanced ones. In the advanced examples, I will
mention how to safely manipulate dice specs using arithmetic expressions
(involving multiples of certain powers of 2).

  Enjoy,
    Eric