Hi Mike,
Your proposal looks good to me, though I'm no fixed point guru.
Perhaps Ed Willink or others would have comments?
I'd like to see your changes include tests in the test suite
so that we can be sure we have good coverage.
_Christopher
--------
I want to follow-up on my previous discussion on the fixed point with
a few observations and more suggestions. Initially, I had
misunderstood the meaning of the [x,y] precision format used by the
Ptolemy fixed-point infrastructure by assuming that this format did
not include a bit for the sign (I would have saved a lot of time had I
read the Precision class file documentation more carefully). The
bit-width specification in Precision assumes that a bit dedicated for
the sign and the arithmetic operations perform "signed" arithmetic
correctly with this definition.
While this appears to be working well, I am running into troubles when
I try to model unsigned arithmetic operations. Much of what I do
involves digital hardware circuits where unsigned arithmetic is very
common. I have been able to model much of the unsigned arithmetic
using the existing twos complement signed format supported by the
current code. However, I am having a number of problems when
rounding/truncating unsigned numbers using the existing code and
keeping track of the "extra" bit associated with the sign.
I would like to suggest modifying fixed point infrastructure to
support both signed and unsigned number formats naturally. While more
code would be required, I believe supporting both signed and unsigned
within the existing classes would be natural and relatively
straightforward. Details of my proposal are listed below.
Any suggestions on my proposal?
---------------------------------------------------------------
The current Precision class defines the fixed point precision using
two arguments, [x/y] where x specifies the total number of bits and y
specifies the number of integer valued bits. In this format, one of
the bits is assumed to be the sign bit.
[8/7]
Max value = 127 (01111111)
Min value = -128 (10000000)
I propose that we add another field in the precision specification
that allows for unsigned values. For example, such a specificatoin
could be [x/y/z] where x is used for the total number of bits, y is
used to specify the number of integer bits, and z is used to specify
the sign bit (z=0 indicates unsigned number and x=1 indicates a signed
number). Here are some examples of numbers in this new format:
[8/7/1]
Max value = 127 (01111111)
Min value = -128 (10000000)
Epsilon = 1
[8/7/0]
Max value = 63.5 (11111111)
Min value = 0 (000000000)
Epsilon = 0.5
[8/8/0]
Max value = 255 (11111111)
Min value = 0 (00000000)
Epsilon = 1
[8/8/1]
Max value = 254 (01111111 x 2 = 011111110)
Min value = -256 (10000000 x 2 = 100000000)
Epsilon = 2
Necessary Changes:
Precision.java
- support added representation for unsigned numbers
- Text format for specifying signed/unsigned behavior
- Field to represent signed/unsigned behavior
- Accessor method to determine signed/unsigned behavior
- Modification of all methods to correctly represent both unsigned
and signed numbers.
- backwards compatibility for signed only formats
(specification in old format creates a "signed" number)
Quantization.java
- This class assumes a sign bit. Modify the class to
query the unsigned/signed behavior to respond correctly
FixPoint.java (* this would involve the most work)
- Modification of all arithmetic functions to handle unsigned
arithmetic
- Produce a fixed value with the correct signed/signed
Operand A Operand B Result
unsigned unsigned unsigned
unsigned signed signed
signed unsigned signed
signed signed signed
- Modification of quantize method
Overflow.java
- Handle unsigned overflow
Rounding.java
- Handle unsigned rounding
No changes to:
FixType, FixToken, FixPointQuantization
--
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]
