> > I don't understand how this turned into an argument about simplicity. I > never said it was complex.
i wasn't arguing, just confused about what you were asking cuz i didn't see what wasn't straightforward. so i addressed the straightforward interpretation in order to ask what that was missing. :) looks like polyphony is the issue, so i think you need a directed acyclic graph (DAG). http://hackage.haskell.org/packages/archive/containers/0.3.0.0/doc/html/Data-Graph.html since every note has at most one pre-Tie and one post-Tie, i guess you don't need a general DAG -- but a graph library would have the algorithms for walking the Ties (ie, dfs, components, reachable, etc. in the mentioned library). I conceive of this problem as multiple passes. On the first pass, I > translate XML notes into a convenient internal representation, on the second > pass sort them, then make a pass to figure out ties. Whether this is the > best approach, I do not know. > sure that makes sense, i was just addressing the last pass, the matter of wiring up the tie references. > Regarding my use of Rational, it's because I'm representing *notated* > durations or positions in time, which are always fractions of integers. > Suppose I give the command to my program to play via midi everything from > bar 1 beat 1 to bar 2 beat 2 1/2. I want to use Rational so I know 2 1/2 > means 2 1/2 and not 2.49999999999. i wasn't suggesting anything Numeric for durations -- those are NoteDurs like (Dotted $ Triplet Half). you don't need numerics until resolving temporal locations, like milliseconds or subdivisions of a beat. those may be irrational numbers (consider if the tempo is irrational, or tiny random jitter in timing) -- though it's a totally pedantic point on my part and realistically won't matter. ;) > I don't quite get this: > > > forall x. (Real x, Fractional x) => x if you're picky. > just being agnostic about the true representation as long as you have (/), compare, realToFrac, toRational. the client can choose some concrete representation like Rationals, Floats, Doubles, some Fixed resolution, some C type, something they make up, etc. space or speed or compatibility may trump precision for some applications. (*) I may want to use the location of a note (bar and beat) as the key in a > Map, which I believe should be done with Rational and not Float. location needs subdiv, which is (very pedantically) not Rational. :) -e
_______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
