[The following message bounced because ptolemy-hackers only posts
submission from members. I took the liberty of changing your
subscription from [EMAIL PROTECTED] to [EMAIL PROTECTED]]
If you could take a look at the Ptolemy II fix point facilities and
contribute solutions, then that would be really helpful.
The original author of the FixPoint class is no longer at the UC
Berkeley. When the FixPoint class was written in 6/99, we needed some
fixed point functionality, and someone stepped up to the plate and
wrote some code, which was really appreciated at the time. Now would
be a good time to polish that code.
Code maintenance is an issue in both industry and academia.
Unfortunately, in an academic research environment, code gets written
and then the primary author moves on and the code remains in limbo
until someone else decides become the champion of that code and tune
it up. It is critical that the fundamental building blocks work
correctly, but it is difficult to convince a grad student who is
supposed to be doing original research that it is really important
that they spend long hours hacking on basic building blocks that are
not seen as original research by some people.
-Christopher
"Ed.Willink" <[EMAIL PROTECTED]> writes:
--------
> jpat <[EMAIL PROTECTED]> writes:
> > Yes, I must say I was quite surprised to find an error of this
> > obviousness in a package as mature as Ptolemy. Given the
> > catestrophic effects on the operation of any
> fixed-point simulation,
> > it is also surprising that that no one had complained
> up until now.
While it's open season for the Ptolemy II FixPoint package, allow me
to re-post a correspondence concerning surprising overflow functionality.
(The original correspondence was on ptresearch).
The correspondence also covers a number of other areas that would benefit
from attention. Resolving these issues now falls within my work remit again
,
so I may be able to contribute to some solutions.
Regards
Ed Willink
> -----Original Message-----
> From: Ed.Willink
> Sent: Wednesday, May 09, 2001 3:39 PM
> To: [EMAIL PROTECTED]
> Subject: Type specification and bit true simulation
>
>
> Hi
>
> I needed to do some bit-true simulation, so I thought of
> using Ptolemy II in earnest. The FixToken appears to work,
> and types can be defined by inference from values such as
> fix(0,8,6), but:
>
> Consider a trivial SDF design in which a Const is Add'ed to
> the SampleDelay'ed sum.
>
> The Const is configured to the value fix(0.333,8,6) i.e
> binary 000000.01
> The SampleDelay is configured with the inital value
> {fix(0.126,8,2)} i.e. binary 00.001000
>
> This compiles without error.
> It runs without error.
> (on the approx April 25 2001 state of the pt II 1.1 dev tree)
>
> Connecting a FixToDouble and a SequencePlotter shows that the
> adder has at least three fractional bits of precision, a
> plausible but perhaps too helpful interpretation for a bit
> true simulation, since there is no specification on how
> precision extension should be done. I should get a type error
> if I'm using more bits without specifying round/truncate.
>
> Running for a long time shows that there are more than 6
> integer bits, more than either input. The system has
> therefore silently created extra precision for me. Not at all
> appropriate for a bit true simulation.
>
> If I had included some FixToFix actors, I would have an
> opportunity to control precision misalignments. However I
> didn't so the design should fail.
>
> I consider overflow and rounding to be attributes of a type.
> Therefore when a fix(0.333,8,6,saturate,round) collides with
> a (fix(0.126,8,2,saturate,round)) I have a type error through
> saturation at different integer precisions.
>
> In principle any actor has input precisions, internal
> precisions and output precisions. The internal is deduced to
> satisfactorily represent operations on the inputs, which may
> then require input conditioning, that must not violate input
> saturation characteristics. Output conditioning must trim the
> internal precision to the output precision without violating
> saturation or rounding constraints.
>
> Every link has a type, usually inferred. Bit true simulation
> requires more precise user control. Firstly to be able to at
> least see what the simulated type of each link is, and
> secondly to be able to provide explicit type specifications
> wherever required. The safest approach requires all
> conditioning to be performed externally by manually placed
> FixToFix; this is tedious in the extreme. Automatic synthesis
> of the safe FixToFix at each input and output should be
> relatively easy given Ptolemy's polymorphisms.
>
> In the example design, the natural place to define the loop
> precision is at the adder output, since this obviously
> ripples through the sample delay. Having the behaviour
> defined as a side-effect of an initializer is weird.
>
> If I am experimenting with a design, I want to make
> precisions parametric, so that I may use SinglePrecisionType,
> DoublePrecisionType etc. I want my initialisers to be
> independent of their type, so having to use value exemplars
> as types doesn't work, unless I change my parameterisation to
> SinglePrecisionType_0 for a 0 init, SinglePrecisionType_1 for
> a unity init etc.
>
> Ptolemy/Vergil must support named types.
> Vergil must make inferred types visible.
> Vergil must support explicit specification of types at
> arbitrary links and ports.
> Type checking for FixToken should be pedantic and safe
> - perhaps there should be an overall safe/helpful type
> inference option
> Overflow and rounding should be properties of the user
> configuration of a FixToken not of a FixToFix.
>
> Regards
>
> Ed Willink
>
> -----Original Message-----
> From: Edward A. Lee [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 10, 2001 3:59 PM
> To: Ed.Willink
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Ptolemy] Type specification and bit true simulation
>
>
>
> The type system deals only coarsely with fixed point, since it would
> require using dependent types otherwise, which would open up a host
> of other problems.
>
> I agree that there is a problem here, but it is in the FixToken code
> that does polymorphic add.
>
> On these:
>
> >Ptolemy/Vergil must support named types.
>
> We have a design for this, but I guess it hasn't gotten implemented
> yet...
>
> >Vergil must make inferred types visible.
>
> It does. Just linger on the ports.
>
> >Vergil must support explicit specification of types at
> arbitrary links and
> >ports.
>
> We have a design for ports, but I guess it hasn't gotten implemented
> yet... It doesn't make sense in Ptolemy to put types on links.
>
> >Type checking for FixToken should be pedantic and safe
> > - perhaps there should be an overall safe/helpful
> type inference
> >option
>
> Agreed. This means changing FixToken, which should be fairly
> easy. Do you want to do it?
>
> >Overflow and rounding should be properties of the user
> configuration of a
> >FixToken not of a FixToFix.
>
> Tokens are immutable, so I doubt this would work.
> There is no point in specifying an overflow strategy for an object
> that can never overflow.
>
> Edward
>
> -----Original Message-----
> From: Ed.Willink
> Sent: Friday, May 18, 2001 4:31 PM
> To: 'Edward A. Lee'
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Ptolemy] Type specification and bit true simulation
>
>
> Hi Edward
>
> > The type system deals only coarsely with fixed point, since it would
> > require using dependent types otherwise, which would open up a host
> > of other problems.
>
> I'm not familiar with dependent types, and a quick Google
> search shows that I'm unlikely to get much wiser very
> quickly. So in principle I agree that such complexities want
> to be avoided.
>
> > I agree that there is a problem here, but it is in the FixToken code
> > that does polymorphic add.
>
> Possibly in all methods that perform arithmetic, including assignment.
>
> > >Vergil must support explicit specification of types at
> > arbitrary links and
> > >ports.
> >
> > We have a design for ports, but I guess it hasn't gotten implemented
> > yet... It doesn't make sense in Ptolemy to put types on links.
>
> Surely there is no difference? A connection comprises a
> number of ports and links, some of which may provide input to
> a type inference/checking algorithm. Ergonomically, it is
> much easier to click on links than ports. When I parameterise
> a link, I avoid the potential confusion between
> parameterising a port instance and a port definition that was
> at one point present in Vergil.
>
> > >Type checking for FixToken should be pedantic and safe
> > > - perhaps there should be an overall safe/helpful
> > type inference
> > >option
> >
> > Agreed. This means changing FixToken, which should be fairly
> > easy. Do you want to do it?
>
> I would like to, but with WDL nearly dead, I have no
> work-time available, and non-work-time must go to finishing
> my PhD thesis.
>
> > >Overflow and rounding should be properties of the user
> > configuration of a
> > >FixToken not of a FixToFix.
> >
> > Tokens are immutable, so I doubt this would work.
> > There is no point in specifying an overflow strategy for an object
> > that can never overflow.
>
> No doubt the tokens are immutable (Flyweights ?) but that
> doesn't stop you creating a derivative with mutated value.
> For instance in C++, you may have a shared object denoting
> "int", and another derivative denoting "const int" possibly
> created in response to "int".make_const(). In this case the
> "int" object is responsible for managing its derivatives - no
> garbage collector.
>
> I think the problems will become more serious and the current
> behavioiur less tenable when you introduce wrap-around/modulo
> arithmetic for which all arithmetic tokens should respect the
> type qualification and complain when there is no consistent
> type inference. Clearly a mix of modulo-2pi, modulo-256 and
> unity-saturation cannot go through a multiplier or adder unscathed.
>
> Regards
>
> Ed
>
> >
> >
> > At 03:38 PM 5/9/2001 +0100, Ed.Willink wrote:
> > >Hi
> > >
> > >I needed to do some bit-true simulation, so I thought of
> > using Ptolemy II in
> > >earnest. The FixToken appears to work, and types can be
> > defined by inference
> > >from values such as fix(0,8,6), but:
> > >
> > >Consider a trivial SDF design in which a Const is Add'ed to the
> > >SampleDelay'ed sum.
> > >
> > >The Const is configured to the value fix(0.333,8,6) i.e
> > binary 000000.01
> > >The SampleDelay is configured with the inital value
> > {fix(0.126,8,2)} i.e.
> > >binary 00.001000
> > >
> > >This compiles without error.
> > >It runs without error.
> > >(on the approx April 25 2001 state of the pt II 1.1 dev tree)
> > >
> > >Connecting a FixToDouble and a SequencePlotter shows that
> > the adder has at
> > >least three fractional bits of precision, a plausible but
> perhaps too
> > >helpful interpretation for a bit true simulation, since there is no
> > >specification on how precision extension should be done. I
> > should get a type
> > >error if I'm using more bits without specifying round/truncate.
> > >
> > >Running for a long time shows that there are more than 6
> > integer bits, more
> > >than either input. The system has therefore silently created
> > extra precision
> > >for me. Not at all appropriate for a bit true simulation.
> > >
> > >If I had included some FixToFix actors, I would have an
> > opportunity to
> > >control precision misalignments. However I didn't so the
> > design should fail.
> > >
> > >I consider overflow and rounding to be attributes of a type.
> > Therefore when
> > >a fix(0.333,8,6,saturate,round) collides with a
> > >(fix(0.126,8,2,saturate,round)) I have a type error through
> > saturation at
> > >different integer precisions.
> > >
> > >In principle any actor has input precisions, internal
> > precisions and output
> > >precisions. The internal is deduced to satisfactorily
> > represent operations
> > >on the inputs, which may then require input conditioning,
> > that must not
> > >violate input saturation characteristics. Output
> > conditioning must trim the
> > >internal precision to the output precision without violating
> > saturation or
> > >rounding constraints.
> > >
> > >Every link has a type, usually inferred. Bit true simulation
> > requires more
> > >precise user control. Firstly to be able to at least see
> > what the simulated
> > >type of each link is, and secondly to be able to provide
> > explicit type
> > >specifications wherever required. The safest approach requires all
> > >conditioning to be performed externally by manually placed
> > FixToFix; this is
> > >tedious in the extreme. Automatic synthesis of the safe
> > FixToFix at each
> > >input and output should be relatively easy given Ptolemy's
> > polymorphisms.
> > >
> > >In the example design, the natural place to define the loop
> > precision is at
> > >the adder output, since this obviously ripples through the
> > sample delay.
> > >Having the behaviour defined as a side-effect of an
> > initializer is weird.
> > >
> > >If I am experimenting with a design, I want to make
> > precisions parametric,
> > >so that I may use SinglePrecisionType, DoublePrecisionType
> > etc. I want my
> > >initialisers to be independent of their type, so having to
> use value
> > >exemplars as types doesn't work, unless I change my
> > parameterisation to
> > >SinglePrecisionType_0 for a 0 init, SinglePrecisionType_1
> > for a unity init
> > >etc.
> > >
> > >Ptolemy/Vergil must support named types.
> > >Vergil must make inferred types visible.
> > >Vergil must support explicit specification of types at
> > arbitrary links and
> > >ports.
> > >Type checking for FixToken should be pedantic and safe
> > > - perhaps there should be an overall safe/helpful
> > type inference
> > >option
> > >Overflow and rounding should be properties of the user
> > configuration of a
> > >FixToken not of a FixToFix.
> > >
> > > Regards
> > >
> > > Ed Willink
>
------------------------------------------------------------------------
E.D.Willink, Email: mailto:[EMAIL PROTECTED]
Thales Research Ltd, Tel: +44 118 923 8278 (direct)
Worton Drive, or +44 118 986 8601 (ext 8278)
Worton Grange Industrial Estate, Fax: +44 118 923 8399
Reading, RG2 0SB
ENGLAND http://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------
(formerly Racal Research and Thomson-CSF)
As the originator, I grant the addressee permission to divulge
this email and any files transmitted with it to relevant third parties.
***************************************************************************
****
This email and any files transmitted with it are intended solely for the us
e of
the individual or entity to whom they are addressed and may not be divulged
to
any third party without the express permission of the originator. Any view
s
expressed in this message are those of the individual sender, except where
the
sender specifically states them to be the views of Thales Research Ltd.
Following the acquisition of Racal Electronics plc by Thomson-CSF, please n
ote
that our new name is Thales Research Ltd. For more information regarding t
he
Thales Group (formerly Thomson-CSF) please see our website www.Thalesgroup.
com
***************************************************************************
****
--------
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
