David Kastrup <[email protected]> writes: > Mario Lang <[email protected]> writes: > >> David Kastrup <[email protected]> writes:
[...] >>> Computers are fast enough nowadays that the choice of implementation >>> language is almost irrelevant compared to the choice of algorithm and >>> consequently the algorithmic complexity. >> >> Having experienced the difference between compiled and interpreted >> languages first hand, I tend to disagree. > > Of course there is a difference, but it is a constant factor, and the > "gets unusable for large-scale applications" threshold is much more > determined by algorithmic complexity. > >> Guess I am a bit biased since I spent a few weeks recently finding >> optimisations for my current algorithm. > > I remember working in the area of digitized map processing and trying to > find my way through a large-scale, heavily optimized algorithm (partly > written by someone with a PhD in computer science) which it was my task > to improve, as it took days to process large amounts of data and was > increasingly getting unstable under the partaken optimizations. I tried > for a week finding my way around it, but it was beyond me and I proposed > letting me rewrite it from scratch. The purpose of the algorithm was to > determine for a sort-of rectangular grid to look for the closest contour > line in eight directions and do a weighted average. Contour lines were > digitized with a humongous amount of line pieces. I basically inverted > the logic of the algorithm: instead of searching from each raster point > to the next contour line, I used line drawing algorithms on each contour > line to figure out where it crossed raster lines and diagonals, and > afterwards used just the intersection data from the raster lines > corresponding to each data point. > > After shaking out the compilation errors and initial segfaults and > stuff, I got stuck without getting anywhere since the program showed no > immediately obvious problem but just terminated after running for about > two minutes. Hahaha, while reading this, it already dawned on me what would be next :-). > After two days of trying to figure out the root cause of the premature > termination by debugging in various manners, I finally tried to see > whether the problem could be guessed from visualizing the output. > > It turned out that the output was fine. > > Taught me a lesson about "optimization" and "computer scientists". Yes, I know about the pitfalls that premature optimisation can open. In the case I was talking about, I actually went from roughly 70 seconds runtime of my first naive implementation, to about 5 seconds now. On the way, I discovered things like std::shared_ptr (basically reinventing GC for C++ :-) ). Most of the remaining optimisations came from observing further improvements of the actual algorithm, and integrating it more closely with the language it is implemented in. So I guess both stories can happen: optimisation can be evil, but it can also lead to quite nice results. >> So I take it you suggest it would be best to start with a Scheme-based >> implementation, basically similar to what articulate.ly does? > > I don't really like the coding of articulate.ly. If you take a look at > scm/display-lily.scm, you'll find a macro with-music-match which is used > a lot in define-music-display-methods.scm. Scheme is suited rather well > for this kind of pattern-based coding, and it would likely be feasible > to create a suitable framework where one can specify conversion patterns > in a reasonably straightforward way. Thanks for that hint, I just had a look at with-music-match and I totally agree, it looks like a much better way then hand-coding conditionals. I happen to have a few years of Lisp-experience (mostly elisp and a bit of CL) and am one of those guys that absolutely loved SICP :) So with that background, maybe I can even get something done. We will see :-) Again, thanks for that pointer, it looks very useful. -- CYa, ⡍⠁⠗⠊⠕ _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
