Hi Edward Edwasrd Willink wrote >Surely <double> --> <double> is just wrong. It uses the COSSAP >fudge to support Arrays in a non-Array tool via accidental sequences. >Any type system that requires exaplanatory text, (use N successive >samples) is not a type system.
Edward Lee wrote > The only difference between: > > <double> --> <double> > > and > > A sequential array (distributed in time over sequential samples) > with type T1[N] --> T2[N] > > is the "N", which is what makes it a dependent type system... I don't think we got to the bottom of this, getting side tracked into axes of type lattices. If <double> --> <double> is the signature of an FFT, what is the output? Does the FFT fire after the first token to do an FFT1, then second to do FFT2, then 4 to do FFT4 etc, or after every 64 to do FFT64? Whichever; the output can only really be a stream of double (complex surely) for FFT1. I think there is a confusion between the computation firing signature double[64] -> double[64] and the communication context which might indeed be <double> --> <double> The two are only compatible after a helpful type-inference system has inserted the conversions <double> --> <double[64]> and <double[64]> --> <double> (The implementation option of address/space/time distribution of the 64 elements remains open.) A helpful system may do this automatically, however a type-safe system must require user intervention to avoid accidental and undiagnosed interconnection of skewed frame boundaries. You agreed to my suggestion a couple of yeasrs ago that the Prolemy type system should have two modes: helpful/safe. If Ptolemy is to approach a consistent specification of behaviour rather than yet another set of intuitions, this conversion should not be automatic. When seen as a conversion, it ceases to be part of the FFT, just another part of the type system. It might even be that a smart code generator could exploit a stream optimised FFT implementation to weave the conversions into the computation, but that is a code generation/implementation issue that should only appear on the mapping of a Ptolemy diagram to a target platform. Regards Ed Willink ------------------------------------------------------------------------ E.D.Willink, Email: mailto:[EMAIL PROTECTED] Thales Research and Technology (UK) Ltd, Tel: +44 118 923 8278 (direct) Worton Drive, or +44 118 986 8601 (ext 8278) Worton Grange Business Park, Fax: +44 118 923 8399 Reading, RG2 0SB ENGLAND http://www.computing.surrey.ac.uk/personal/pg/E.Willink ------------------------------------------------------------------------ ---------------------------------------------------------------------------- Posted to the ptolemy-hackers mailing list. Please send administrative mail for this list to: [EMAIL PROTECTED]