Re: Performance comparison Q

Hi Gary,

(CC'd to list with permission)

> In general, for functional languages (LISP, Python [to some  
> degree], etc.) there should be some kind of "map" function that  
> takes one function and applies it to the members of a list.  In  
> general, coding in terms of such map functions yields enhanced  
> performance over a normally coded loop and is the preferred way of  
> coding such things in languages of that sort.  Infelicities can  
> arise (as in Python) if the language does not support map() in a  
> fully general form or does not support lambda-abstraction in fully  
> general form.  Nonetheless, for many fairly straightforward  
> operations on a list (or set) of objects, use of map() is the way  
> to go since it throws execution of the loop into lower level and  
> more efficient code.
>
> This is a long-winded way of saying that the question about  
> "arbitrary operators" depends on how arbitrary they are.  In  
> Python, lambda-abstraction is supported in only a restricted way  
> and the constraint on map() is that the functional parameter must  
> resolve to a function of exactly one parameter.  This is unfortunate.

These are precisely the sort of issues I'm facing right now in the  
stuff I'm coding up myself.  Generality vs. special-casing.  I've got  
examples where the difference is three orders of magnitude, so what  
this is really all about is to what extent I can just code up a  
general case and defer all special-casing to much later on.

Just discovered the "operator" module a minute ago, from Brian  
Kelley's Python example.  Yes, there is only so much you can pre-code  
in C (although covering 95% of the cases surely is a very good  
strategy).

What if the loop wants to calculate a condition such as "item % 7 > 3"?

-jcw

_____________________________________________
Metakit mailing list  -  [email protected]
http://www.equi4.com/mailman/listinfo/metakit