
6.5.6 Conclusions As I mention in the Preface, in my opinion Mathematica programming is divided in 3 layers in terms of efficiency: scripting, intermediate and system layers. This section is a good illustration of this statement: solutions in the first part (procedural) are "scripting" in the sense that they are completely straightforward. Also, they are slow, and can practically be used only on very small lists.The unfortunate thing is that they are also the ones which are most likely to first come to mind for people coming from the procedural background. Solutions in the second part (functional, using Intersection, MemberQ or Alternatives) represent an "intermediate" level and are generally not bad, and also easy to write for anybody with some Mathematica programming experience. For many purposes they can be good enough. The final solution which is based on boosted MapAt and memberPositions functions, represents a "system" level (if there are further ways to speed up this code within Mathematica, I am not aware of them), and can perhaps be packaged to make an extension of Mathematica language. While not as fast as the analogous builtin probably would be, it should be fast enough for most purposes for which Mathematica is generally acceptable in terms of performance. In terms of development speed, it takes somewhat longer to get the "system level" function done, mainly to figure out the idea of the implementation. Perhaps, with experience it takes about couple of minutes to make any of the functional versions work (in fact, faster than the procedural ones since the code is shorter) and about half an hour to get the structural version done (well, at least in my experience. Perhaps it can be done much faster still). But given the level of generality of the problem in question, I think this is acceptable. Returning to the problem in question, the final comment is that in cases when the mapped function is very computationally intensive (so that the computation of this function becomes the most expensive operation), the difference in efficiency between the various solutions we have discussed will matter less or much less. So, it makes sense to perform this kind of analysis before going say from the "intermediate" to "system" levels in one's implementations, because it may be just not worth it for a given problem.

