[kepler-dev] question on typing processes and higher-order fu nctions a la map

Willink, Ed Ed.Willink at thalesgroup.com
Wed Jun 2 01:47:06 PDT 2004


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:EdWillink at iee.org
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
------------------------------------------------------------------------



More information about the Kepler-dev mailing list