[Haskell-cafe] Sample rate inference

[Glynn Clements]

Henning Thielemann wrote:

> > >  The computation sample rate should be propagated through the network as
> > > follows:
> > >   If in a component of equal sample rate some processors have the same
> > > fixed sample rate, all uncertain processors must adapt that. 
> > >   If some processors have different fixed sample rates this is an error. 
> > >   If no processor has a fixed sample rate, the user must provide one
> > > manually.
> > >  To me this looks very similar to type inference. Is there some mechanism
> > > in Haskell which supports this programming structure? 
> > 
> > If you define a class for sample rates, and an instance for each
> > possible sample rate, then you could use type inference,
> 
> Interesting approach, though it's not good idea to restrict to some sample
> rates. It's also not necessary to do the inference at compile time. 

Ah. I think that I took your comparision to type inference too
literally.

> > I doubt that this specific example wouldn't work in practice (the type
> > inference would probably give the compiler a heart attack), but you
> > could presumably construct an equivalent mechanism using base-N
> > numerals.
> 
> :-)
> 
> How can one implement a sample rate inference that work at run-time for
> arbitrary rates? This will be the only way if one works with sampled
> sounds read from a file. 

This is essentially "unification".

Haskell and ML use it for type inference and for pattern matching,
(although pattern matching is always unidirectional, i.e unifying a
pattern comprised of both variables and constants with a value
comprised solely of constants). Prolog uses it more extensively
(variables can occur on either side).

Essentially, unification involves matching structures comprised of
constants, variables, and other structures. An unbound variable
matches anything, resulting in the variable becoming bound; a bound
variable matches whatever its value matches; a constant matches
itself; and a structure matches another structure if they have the
same number of components and all of their components match.

You could probably use GHC's type inference code, although converting
it for your purposes may be more work than starting from scratch. The
Hugs98 code contains a miniature prolog implementation, so you could
take the unification algorithm from that.

-- 
Glynn Clements <glynn at gclements.plus.com>