[Haskell-cafe] When the unknown is unknown

[Martin Drautzburg]

On Thursday, 24. June 2010 00:04:18 Alexander Solla wrote:
> On Jun 23, 2010, at 1:50 PM, Martin Drautzburg wrote:
> > I said that a rhythm is a series of Moments (or Beats), each
> > expressed as
> > fractions of a bar. But each Moment also has volume. So I could
> > model rhythm
> > as Pairs of (Moment, Volume). However I certanly do not want to
> > specify both
> > the Moments and the Volume, but rather compute one from the other.
>
> How about something like:
>
> type RhythmScheme = [(Maybe Moment, Maybe Volume)]
> type Rhythm       = [(Moment, Volume)]
>
> -- The resolution function will then be a function with type:
>
> rhythm_from_scheme :: RhythmScheme -> Rhythm
>
> -- Though you might want something like
> -- rhythm_from_scheme :: RhythmScheme -> IO Rhythm
> -- or
> -- rhythm_from_scheme :: Seed -> RhythmScheme -> Rhythm
> -- so that you can get and use random numbers, for example.
>
>
> I guess the point of my suggestion is to let pattern matching in
> function definitions deal with unification of constraints.  Beta
> reduction and unification are two sides of a coin.

Nice. 

But what if I have three or more values (and not just two). Then inside the 
rhythm_from_scheme function I will probably have functions like
a->b->c, i.e. if two values are known I can compute the third. If only one 
value is known the result would be a partially applied function and I would 
need additional information to compute the result. So I will need more than 
just a Mabye, because I can either have Nothing, a value or a function. 

However I will need one such function for each permutation. The function 
a->b->c will not help me much if either b or c is known. This means I cannot 
stuff too many unknowns together, but I will have to layer the problem 
somehow, such that a 9tuple of unknowns is unified as three triples. I am 
still uncertain how to do this, but I believe it basically matches musical 
thinking. A composer cannot juggle 9 unknowns either without grouping them 
somehow.

Another question is: how much past and future knowledge do I need. (I believe 
the fundamental property of music is that things are ordered).  In order to 
compute Volumes from Moments I can get pretty much away without the past, but 
computing Moments from Volumes definitely requires knowing "where I am", 
because each new Moment has to be placed after a preceding Moment.

Any ideas?










-- 
Martin