Re: Braille export

[Mario Lang]

David Kastrup <address@hidden> writes:

> Mario Lang <address@hidden> writes:
>
>> David Kastrup <address@hidden> 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,
  ⡍⠁⠗⠊⠕