Hi Mike,
I'm by no means an expert in fix point arithmetic, but it seems
to me like if this change would result in number with extra
"intBits" if we added two numbers with the same number of intBits,
then the results would have an extra intBit?
To illustrate the point (haha), I added a test to
~/ptII/ptolemy/math/test/FixPoint.tcl
that adds two numbers with 20.12 precision and returns
a 20.12 precision number:
test FixPoint-2.6 {add two numbers with the same precision} {
set add_1 [java::new $ctor_double 5.5734 $q_20_12]
set add_2 [java::new $ctor_double 5.5734 $q_20_12]
set add_3 [$add_1 add $add_2]
list [$add_1 toString] [$add_2 toString] [$add_3 toString] \
[[$add_1 getPrecision] toString] \
[[$add_2 getPrecision] toString] \
[[$add_3 getPrecision] toString]
} {5.573486328125 5.573486328125 11.14697265625 (20.12) (20.12) (20.12)}
When I run with your change, I get a 21.12 number:
==== Result was:
5.573486328125 5.573486328125 11.14697265625 (20.12) (20.12) (21.12)
---- Result should have been:
5.573486328125 5.573486328125 11.14697265625 (20.12) (20.12) (20.12)
---- FixPoint-2.6 FAILED
This seems like not what we want? I would think that if I need
an extra bit because of overflow, then either the overflow should
fail or I should explicitly ask for this behaviour
Perhaps FixPoint.add() should be extended to somehow look at the
overflow strategy and if the overflow strategy is "growBits",
then it grows the number?
However, FixPoint.multiply() does change the intBits, so
I'm not sure what is right here.
public FixPoint multiply(FixPoint arg) {
int fracBits = _frac_bits + arg._frac_bits;
int intBits = _int_bits + arg._int_bits;
BigInteger netValue = _value.multiply(arg._value);
return new FixPoint(netValue, intBits, fracBits);
}
Anyway, like I said, I don't have much experience with fix point
numbers.
Anyone else?
_Christopher
--------
The ptolemy.math.FixedPoint class does not seem to handle bit growth
properly for add or subtract operations. For multiplies, the fixed point
format grows automatically as part of the operation. However, no bit
growth is provided for add or subtract. I would suggest that add and
subtract increase the "inBits" of the new FixPoint value when the
intBits field of both operands are the same. This will allow the fixed
point value to grow when an "overflow" occurs during addition and
subtraction.
Original code (for add):
public FixPoint add(FixPoint arg) {
int fracBits = Math.max(_frac_bits, arg._frac_bits);
int intBits = Math.max(_int_bits, arg._int_bits);
BigInteger thisValue = _alignToFraction(fracBits);
BigInteger thatValue = arg._alignToFraction(fracBits);
return new FixPoint(thisValue.add(thatValue), intBits, fracBits);
}
Suggested code:
public FixPoint add(FixPoint arg) {
int fracBits = Math.max(_frac_bits, arg._frac_bits);
int intBits = Math.max(_int_bits, arg._int_bits);
if (_int_bits == arg._int_Bits)
intBits++;
BigInteger thisValue = _alignToFraction(fracBits);
BigInteger thatValue = arg._alignToFraction(fracBits);
return new FixPoint(thisValue.add(thatValue), intBits, fracBits);
}
--
Michael J. Wirthlin
Associate Professor
Electrical and Computer Engineering Voice: (801) 422-7601
Brigham Young University Fax: (801) 422-0201
459 Clyde Building Email: [EMAIL PROTECTED]
Provo, UT 84602 www.ee.byu.edu/faculty/wirthlin
---------------------------------------------------------------------------
-
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
--------
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
