I found it very difficult to develop a coherent way of representing
numeric property values when I was looking at the property values
expression evaluator. My initial approach had a structure that looked
something like:
PropertyValue
|
v
Numeric
/ | \
/ v \
Number Length Percentage
with inheritance flowing down. The problem was that Numeric types are
changeable. Any numeric with a unit power of zero is a number; any
numeric with a unit power of one is a measure of some kind, and other
unit powers represent intermediate calulation results in the expression
evaluator.
A PropertyValue can start life as a Length, become a number (unit power
0) through a multop, and then theoretically mutate into a completely
different form of measurement, e.g. an Angle. The table I used for this is:
* Operations defined on combinations of the types (where a percentage
* is treated in the same manner as a number) are:
* number anyop number = number
* baseunit anyop baseunit2 = Illegal
* number multop baseunit = baseunit
* number addop baseunit = Illegal
* baseunit multop baseunit = baseunit (with changed power)
* baseunit^n addop baseunit^n = baseunit^n
* baseunit^n addop baseunit^m = Illegal
*
I don't know how kosher this is, and would appreciate any comments. I
am also puzzled by the constraint in the spec (5.9.6 Absolute Numerics)
that:
In addition, only the mod, addition, and subtraction operators require
that the numerics on either side of the operation be absolute numerics
of the same unit power. For other operations, the unit powers may be
different and the result should be mathematically consistent as with the
handling of powers in algebra.
As I read this, it means that, while I can divide a <length> by a
number, resulting in a <length> of the same unit power, I cannot take
the mod of a <length> using a number. Can anyone explaing the reasons
for this restriction?
The approach taken in the current expression evaluator is that all
arithmetic operations involving property values require that the operand
be another property value, and the operation generates a new property
value object. This may well be the cleanest way, but I am experimenting
with expressing the result of the operation directly in the
PropertyValue object on which the arithmetic operation is invoked.
In order for this to work, I had to eliminate the subclasses of Numeric.
These (Length, Percentage, IntegerType, Angle, Time, Frequency and
possibly Number) remain as "static" classes which provide the class
methods makeLength, makePercentage, etc, all of which return Numerics.
The type of a Numeric is distinguished by the baseunit, which may
change as a result of arithmetic operations.
I am currently working my way through the Numeric and other subclasses
of PropertyValue, and setting up any necessary PropertyValue objects to
express the initial values of the properties in Properties.java, the
monster properties file.
The propertyStacks in PropertyConsts.java will contain PropertyTriplet
objects, which potentially contain specified, computed and actual
property values. Specified is a String; the othes are PropertyValue
objects. I will upload the latest versions to my web page later
tonight, for anyone who is interested.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
