Topic: mapcar apply lambda

[mailmaverick]

Dear All

I have been using LISP for the past few months and have made some LISP programs successfully.

I have never understood the concept of mapcar, lambda and apply clearly. However, still I have been able to make programs using foreach, repeat, while etc.

My questions are :

(i) Is there any benefit of using mapcar, apply when we can use foreach, repeat, while etc ?

(ii) Instead of lambda we can define a function with name and use it wherever required.  So what is the benefit of lambda ? I have read that it saves memory. But question is how much memory does our LISP programs consume and what we will get by saving it and that too only during running of routine.

[Peter2]

...I have never understood the concept of mapcar, lambda and apply clearly. ...

Me too, but don't say it to others ...

Have you read the tutorials like
http://www.lee-mac.com/mapcarlambda.html
http://www.afralisp.net/autolisp/tutorials/mapcar-and-lambda.php
http://www.advanced.autolisp.info/lambda.html (German)
http://forums.autodesk.com/autodesk/attachments/autodesk/130/294770/1/CP401-1-Lisp-Advance-Yourself%20_2-DOC.pdf

I think it can answer your questions.

[mailmaverick]

I have read the tutorials but my query is still unresolved.

Is there any situation where the logic cannot be achieved by foreach, repeat. while etc but can be achieved by mapcar, apply etc ?

If yes, then I would like to know such a case.

[Lee Mac]

Is there any situation where the logic cannot be achieved by foreach, repeat. while etc but can be achieved by mapcar, apply etc.

There is usually more than one way to tackle a problem in AutoLISP, and indeed, every conceivable loop could probably be constructed using only foreach, repeat or while. However, although possible, for some situations this will be far more inefficient and obfuscated than writing an equivalent statement using mapcar (apply is not comparable as this function does not iterate over a list).

The first example that springs to mind:

"Write a function that sums the items in two lists and outputs a list of the results."

For example, given two lists: (1 2 4 6 3 8 7) & (5 4 7 2 3 1 9), the result should be (6 6 11 8 6 9 16).

Using foreach, this might be written as:

Code - Auto/Visual Lisp: [Select]

1. (defun sum-foreach ( a b / r y )
2.     (foreach x a
3.         (if (setq y (car b))
4.             (setq r (cons (+ x y) r)
5.                   b (cdr b)
6.             )
7.         )
8.     )
9.     (reverse r)
10. )

Code - Auto/Visual Lisp: [Select]

1. _$ (sum-foreach '(1 2 4 6 3 8 7) '(5 4 7 2 3 1 9))
2. (6 6 11 8 6 9 16)

Using repeat, it might be:

Code - Auto/Visual Lisp: [Select]

1. (defun sum-repeat ( a b / x y r )
2.     (repeat (min (length a) (length b))
3.         (if
4.             (and
5.                 (setq x (car a))
6.                 (setq y (car b))
7.             )
8.             (setq r (cons (+ x y) r)
9.                   a (cdr a)
10.                   b (cdr b)
11.             )
12.         )
13.     )
14.     (reverse r)
15. )

Code - Auto/Visual Lisp: [Select]

1. _$ (sum-repeat '(1 2 4 6 3 8 7) '(5 4 7 2 3 1 9))
2. (6 6 11 8 6 9 16)

Using while, it could be written as:

Code - Auto/Visual Lisp: [Select]

1. (defun sum-while ( a b / x y r )
2.     (while
3.         (and
4.             (setq x (car a))
5.             (setq y (car b))
6.         )
7.         (setq r (cons (+ x y) r)
8.               a (cdr a)
9.               b (cdr b)
10.         )
11.     )
12.     (reverse r)
13. )

Code - Auto/Visual Lisp: [Select]

1. _$ (sum-while '(1 2 4 6 3 8 7) '(5 4 7 2 3 1 9))
2. (6 6 11 8 6 9 16)

However using mapcar, this task is a simple one-liner:

Code - Auto/Visual Lisp: [Select]

1. (defun sum-mapcar ( a b ) (mapcar '+ a b))

Code - Auto/Visual Lisp: [Select]

1. _$ (sum-mapcar '(1 2 4 6 3 8 7) '(5 4 7 2 3 1 9))
2. (6 6 11 8 6 9 16)

And the use of the right tool for the job is reflected in the performance:

Code - Auto/Visual Lisp: [Select]

1. _$ (setq a '(1 2 4 6 3 8 7) b '(5 4 7 2 3 1 9))
2. (5 4 7 2 3 1 9)
3. _$ (repeat 5 (setq a (append a a) b (append b b)))
4. _$ (length a)
5. 224
6. _$ (benchmark '((sum-foreach a b)(sum-repeat a b)(sum-while a b)(sum-mapcar a b)))
7. Benchmarking .................Elapsed milliseconds / relative speed for 16384 iteration(s):
8.  
9.     (SUM-MAPCAR A B)......1451 / 6.56 <fastest>
10.     (SUM-WHILE A B).......7363 / 1.29
11.     (SUM-FOREACH A B).....7551 / 1.26
12.     (SUM-REPEAT A B)......9516 / 1.00 <slowest>

And now consider if we want to sum the items in not just two lists, but n lists...

Using mapcar, this is again a simple one-liner:

Code - Auto/Visual Lisp: [Select]

1. (defun sum-mapcar ( l ) (apply 'mapcar (cons '+ l)))

Code - Auto/Visual Lisp: [Select]

1. _$ (sum-mapcar '((1 3 4 2) (5 6 2 1) (8 5 1 5) (1 4 5 5)))
2. (15 18 12 13)

But it certainly wouldn't be anywhere near as concise (or efficient) using only foreach, while or repeat.

Restricting yourself to using only foreach, while or repeat for every situation is like trying to build a house with only a hammer - you are depriving yourself of some powerful tools in your AutoLISP toolbox.

[ymg]

mailmaverick,

So what is the benefit of lambda ?

Say that the function is only used by that mapcar, there is no point
to clutter your program with a separate funtion call.

On top of that, the function is right there, where it is used, which is
very logical. No need to go anywhere else to assert  what the
function is doing.

ymg

[gile]

Hi,

Higher order functions (which, with AutoLISP, means functions which takes another function as arguments), and lambda functions  are basic concepts of functional programming (LISP is the oldest functional programming language).

In my opinion, the understanding of these concepts (as the understanding of recursion) is a major step in the AutoLISP (or any other language) learning curve.

The functional paradigm allows a more declarative way of coding: you directly write what you want instead of describing the way to get what you want.
A simple example to get the even integers from an integers list

Code - Auto/Visual Lisp: [Select]

1. (setq lst '(0 1 2 3 4 5 6 7 8 9))
2.  
3. (defun isEven (x) (zerop (rem x 2)))

Functional/declarative way using vl-remove-if-not (which is a higher order function):
get the list without the odd integers.

Code - Auto/Visual Lisp: [Select]

1. (setq evens (vl-remove-if-not 'isEven lst))

Imperative way using foreach:
for each item in the list, if the item is even, add it to the new list. Reverse the new list.

Code - Auto/Visual Lisp: [Select]

1. (foreach x lst (if (isEven x) (setq evens (cons x evens))))
2. (reverse evens)

Both would have been written without using the external isEven function

Code - Auto/Visual Lisp: [Select]

1. (setq evens (vl-remove-if-not '(lambda (x) (zerop (rem x 2))) lst))

Code - Auto/Visual Lisp: [Select]

1. (foreach x lst (if (zerop (rem x 2)) (setq evens (cons x evens))))
2. (reverse evens)

[Bhull1985]

Thanks Gile, this is a good description of how and when to use a lambda function!
I believe the hardest thing to grasp for novices such as myself in regards to lambda and mapcar is intuitively knowing when one is correct method of obtaining a result.
I'm starting to feel like I could use these functions though, and off-the-top of my head I would phrase it as such.

When a separate defun would be required, could be used, to process a LIST of items.
      - A LIST of items because mapcar applies a function to each item within a list, so say we're dealing with a point or two , complete with x y and z coordinates.

Code: [Select]

(setq pt1 '(1.0 1.0 0.0))
(setq pt2 '(2.0 2.0 0.0))

And we want to for whatever reason, add some elevation to these points in order to add a third dimension, or make the points 3-dimensional. We will arbitrarily add an elevation of 1 foot to each of these points.

One method would be to write a defun accepting as arguments the point variable and to which the 1 foot would be added to the z-coordinate.

Code: [Select]

(defun addelev ( pt / x y z newz newpt)
(setq x (car pt))
(setq y (cadr pt))
(setq z (caddr pt))
(if pt
(setq newz (+ 12.0 z))
(princ "\nNot a point coordinate")
);if
(setq newpt (list x y newz))
(princ newpt)
)

well, client work calls. I feel like I'm getting close. My function there prints to the screen (X Y NEWPT) instead of the values themselves and I was going to anonymize that function with a lambda but alas, gotta busy myself elsewhere.
Am I doing something wrong in that function or heading down the right path? Gile, Lee, Others?

[gile]

Hi,

You can simply write your function:

Code - Auto/Visual Lisp: [Select]

1. (defun addelev (pt)
2.   (list (car pt) (cadr pt) (+ (caddr pt) 12.))
3. )

Or as a lambda function:

Code - Auto/Visual Lisp: [Select]

1. (lambda (pt) (list (car pt) (cadr pt) (+ (caddr pt) 12.)))

[Bhull1985]

Thank you!
So

Code: [Select]

(setq pt1 '(1.0 2.0 0.0))
(setq pt2 '(2.0 3.5 0.0))
(setq pt3 '(5.0 10.0 0.0))
(setq pt4 '(6.0 7.5 0.0))
(setq lst (list pt1 pt2 pt3 pt4))
(mapcar
   '(lambda ( pt )
     (list (car pt) (cadr pt) (+ (caddr pt) 12.))
   )
 lst
)

This , if *crosses fingers* would apply the "addelev" to each point in the list , giving each a z coordinate of 12.0, keeping the x and y coordinates the same.
This would be a baby example and I'm not too quick to say it's correct but if I'm taking the right steps here hopefully someone in addition to myself gains from it


edit: cad says it works, hooray.

[fixo]

Maybe i'm missing something,
but I would be use instead:

Code: [Select]

(mapcar '(lambda (pt)(mapcar '+ pt (list 0 0 12))) lst)

[Bhull1985]

Not sure I understand the difference.
I can't follow the logic in yours..nevertheless; it appears to work as well.
I believe it to be adding the z coordinate in a different fashion than the previous example, but you've got an additional argument and an additional mapcar statement.
Twice the complexity, IMO, but perhaps there's a good reason for it.......

Code: [Select]

(setq pt1 '(1.0 2.0 0.0))
(1.0 2.0 0.0)

Command: (setq pt2 '(2.0 3.5 0.0))
(2.0 3.5 0.0)

Command: (setq pt3 '(5.0 10.0 0.0))
(5.0 10.0 0.0)

Command: (setq pt4 '(6.0 7.5 0.0))
(6.0 7.5 0.0)

Command: (setq lst (list pt1 pt2 pt3 pt4))
((1.0 2.0 0.0) (2.0 3.5 0.0) (5.0 10.0 0.0) (6.0 7.5 0.0))

Command: (mapcar '(lambda (pt)(mapcar '+ pt (list 0 0 12))) lst)
((1.0 2.0 12.0) (2.0 3.5 12.0) (5.0 10.0 12.0) (6.0 7.5 12.0))

Command: (setq pt1 '(1.0 2.0 0.0))
(1.0 2.0 0.0)

Command: (setq pt2 '(2.0 3.5 0.0))
(2.0 3.5 0.0)

Command: (setq pt3 '(5.0 10.0 0.0))
(5.0 10.0 0.0)

Command: (setq pt4 '(6.0 7.5 0.0))
(6.0 7.5 0.0)

Command: (setq lst (list pt1 pt2 pt3 pt4))
((1.0 2.0 0.0) (2.0 3.5 0.0) (5.0 10.0 0.0) (6.0 7.5 0.0))

Command: (mapcar
(_>    '(lambda ( pt )
('(_>      (list (car pt) (cadr pt) (+ (caddr pt) 12.))
('(_>    )
(_>  lst
(_> )
((1.0 2.0 12.0) (2.0 3.5 12.0) (5.0 10.0 12.0) (6.0 7.5 12.0))


[Lee Mac]

Not sure I understand the difference.
I can't follow the logic in yours..nevertheless; it appears to work as well.

See this thread to understand fixo's example

[Bhull1985]

Excuse me if I'm wrong- just trying to gain understanding here...
and I'm not, definitely not, thinking my methodology is the best here but at the moment the second example, "fixos example" seems a bit redundant with the multiple calls to mapcar and the single list. I suppose with the points being a list themselves, is this what's causing the second mapcar?


This is how I read the two functions occurring;

Fixos adds (0 0 12) to each point, mapping the addition
The previous routine adds 12 to the z coordinate only.

And the code again, side by side for each

Code: [Select]

(mapcar '(lambda (pt)(mapcar '+ pt (list 0 0 12))) lst)

and

(mapcar
   '(lambda ( pt )
     (list (car pt) (cadr pt) (+ (caddr pt) 12.))
   )
 lst
)


Tomato, tomatoe? Or is there a functional difference that i'm unawares of?
According to the linked thread it may be to have all values returned , however..

Code: [Select]

(mapcar
(_>    '(lambda ( pt )
('(_>      (list (car pt) (cadr pt) (+ (caddr pt) 12.))
('(_>    )
(_>  lst
(_> )
((1.0 2.0 12.0) (2.0 3.5 12.0) (5.0 10.0 12.0) (6.0 7.5 12.0))
I'll be looking into this more, surely there's a reason for knowing this other way

[mailmaverick]

Dear Bhull,

I have run both of your functions on a list of 10,000 points.
Your first function with two mapcar takes more time than second function with one mapcar.
The veterans can explain why it is so.

Code: [Select]

(defun c:dff ()
  (setq lst nil)
  (setq a (list 100.4 340.24 452.24))
  (repeat 10000 (setq lst (append lst (list a))))
  (setq Start (getvar "Millisecs"))
  (setq b (mapcar '(lambda (pt) (mapcar '+ pt (list 0.0 0.0 12.0))) lst))
  (setq End (getvar "Millisecs"))
  (setq yu (- End Start))
  (princ "\nTime Taken to Run Method 1 (two mapcar) : ")
  (princ yu)
  (princ " milliseconds \n")
  (setq Start (getvar "Millisecs"))
  (setq c
(mapcar '(lambda (pt) (list (car pt) (cadr pt) (+ (caddr pt) 12.0)))
lst
)
  )
  (setq End (getvar "Millisecs"))
  (setq yu (- End Start))
  (princ "\nTime Taken to Run Method 2 (single mapcar) : ")
  (princ yu)
  (princ " milliseconds \n")
  (princ)
)


Output :-
Time Taken to Run Method 1 (two mapcar) : 140 milliseconds

Time Taken to Run Method 2 (single mapcar) : 47 milliseconds

[jvillarreal]

Hi mailmaverick / Bhull1985,

As you know, there are many ways to accomplish the same task.
The example provided to you by Fixo is one of brevity, also providing you with a method to quickly add to each item of your list.

Here's another for shtzngigglez:

Code: [Select]

(setq a (list 100.4 340.24 452.24))
  (repeat 20000 (setq lst (append lst (list a))))

(defun test1 ()
(mapcar'(lambda (pt)(reverse (cons (+ (last pt) 12)(cdr (reverse pt)))))lst)
)

(defun test2 ()
(mapcar '(lambda (pt)(mapcar '+ pt (list 0 0 12))) lst)
)

(defun MavBull ()
(mapcar '(lambda (pt) (list (car pt) (cadr pt) (+ (caddr pt) 12.0)))lst)
)

I found the difference in time to be negligible and inconsistent (on my machine at least):

$ (benchmark '(mavbull test1 test2))
Benchmarking .......................Elapsed milliseconds / relative speed for 1048576 iteration(s):

    TEST2.......1108 / 1.03 <fastest>
    TEST1.......1123 / 1.01
    MAVBULL.....1139 / 1.00 <slowest>
_$ (benchmark '(mavbull test1 test2))
Benchmarking .......................Elapsed milliseconds / relative speed for 1048576 iteration(s):

    TEST2.......1139 / 1.01 <fastest>
    MAVBULL.....1154 / 1.00
    TEST1.......1154 / 1.00 <slowest>
_$ (benchmark '(mavbull test1 test2))
Benchmarking .......................Elapsed milliseconds / relative speed for 1048576 iteration(s):

    TEST1.......1139 / 1.01 <fastest>
    MAVBULL.....1154 / 1.00
    TEST2.......1154 / 1.00 <slowest>

[Bhull1985]

The two most recent posts in this thread contradict eachother, and my day is filled with client work again but i'm still reading best I can. Perhaps by the end of the day I can have more time to devote as the benchmarking has always interested me....nobody likes a routine that takes longer to run than someone doing the process manually

[Lee Mac]

Excuse me if I'm wrong- just trying to gain understanding here... and I'm not, definitely not, thinking my methodology is the best here but at the moment the second example, "fixos example" seems a bit redundant with the multiple calls to mapcar and the single list. I suppose with the points being a list themselves, is this what's causing the second mapcar?

As jvillareal correctly points out, there are usually several ways to tackle a problem in AutoLISP (this is further demonstrated by the number of equivalent solutions offered in the many 'challenge' threads here at the Swamp).

As for the performance: it is true that the solution using mapcar is performing two redundant addition operations since the following mapcar expression:

Code - Auto/Visual Lisp: [Select]

1. (mapcar '(lambda ( x ) (mapcar '+ x '(0 0 12))) '((1 2 3) (4 5 6) (7 8 9)))

Is performing the following operations on each item 'x' of the list:

Code - Auto/Visual Lisp: [Select]

1. (
2.     ((+ 1 0) (+ 2 0) (+ 3 12))
3.     ((+ 4 0) (+ 5 0) (+ 6 12))
4.     ((+ 7 0) (+ 8 0) (+ 9 12))
5. )

Also, memory must be allocated for the second list argument supplied to mapcar for each iteration - therefore, although this solution is perhaps more concise and maybe more readable, the above reasons could make this inefficient.

However, consider that in the alternative solution:

Code - Auto/Visual Lisp: [Select]

1. (mapcar '(lambda ( x ) (list (car x) (cadr x) (+ (caddr x) 12))) '((1 2 3) (4 5 6) (7 8 9)))

We have the overhead of evaluating the list function to construct a new list, followed by evaluation of the car, cadr & caddr functions independently of each other to access the first three items of the list, before the addition is performed and the new list returned.

Here is a quick benchmark:

Code - Auto/Visual Lisp: [Select]

1. _$ (setq l '((0 1 2) (3 4 5)))
2. ((0 1 2) (3 4 5))
3. _$ (repeat 8 (setq l (append l l)))
4. ((0 1 2) (3 4 5) ...  (3 4 5))
5. _$ (length l)
6. 512
7. _$ (defun f1 ( l ) (mapcar '(lambda ( x ) (mapcar '+ x '(0 0 12))) l))
8. F1
9. _$ (defun f2 ( l ) (mapcar '(lambda ( x ) (list (car x) (cadr x) (+ (caddr x) 12))) l))
10. F2
11. _$ (defun f3 ( l ) (mapcar '(lambda ( x ) (reverse (cons (+ (caddr x) 12) (cdr (reverse x))))) l))
12. F3
13. _$ (equal (f1 l) (f2 l))
14. T
15. _$ (equal (f1 l) (f3 l))
16. T
17. _$ (benchmark '((f1 l) (f2 l) (f3 l)))
18. Benchmarking .............Elapsed milliseconds / relative speed for 1024 iteration(s):
19.  
20.     (F2 L).....1108 / 2.84 <fastest>
21.     (F3 L).....1326 / 2.38
22.     (F1 L).....3151 / 1.00 <slowest>

[adalea03]

Fixo
Your first post was an inspiration.

[Bhull1985]

Very interesting.
So, taking away from this....
construct a mapcar statement logically based on which functions needed to operate on which list, but all elements of that list.
Function can be a primitive such as '+ '- '* '/ a subfunction defined elsewhere or an anonymous function calling lambda (typically when the only call to that function is within the mapcar statement itself).
Lambda accomplishes any task in a very similar manner as (defun) except it's usually a helper function, being as such it does not have it's own command to call nor does it require any additional memory usage once the task has been completed.
Lambda will be used typically when a list or an item must be processed in an unstandard manner, when there is no autolisp function or call that would in one step accomplish the same task.
Examples are given above, well, one in specific but it bears repeating just for clarity's sake....
For instance, adding 12 inches elevation to a set of points. There's no autocad function or command that operates on the z coordinates only of points, unless we're in the properties window. Well, that's why a lambda was used.



So both of these functions are used in necessity, typically only when the conditions for firing them off aren't met elsewhere. Mapcar expects a function and a list every time, and as such hopefully some others without a full understanding are starting to gain one- powerful stuff , here. Lists are one of the most extensively used data types that I see from day to day and it's no surprise that a programmer would want to construct a list and then perform operations on it. Something as simple as

Code: [Select]


(setq nameslist (list "Brandon" "carrie" "john" "frank" "tod" "bill"
"Shannon"))
("Brandon" "carrie" "john" "frank" "tod" "bill" "Shannon")

Command: (mapcar
(_> 'strcase
(_> nameslist
(_> )
("BRANDON" "CARRIE" "JOHN" "FRANK" "TOD" "BILL" "SHANNON")

Is an effective way to showcase the more basic capabilities of mapcar, although indeed on a very rudimentary level.
This function, along with all of your posts and assistance (and fixos curveball, totally worth the discussion) have really made mapcar appear as a tame animal, not so difficult once your head is wrapped around the basics...... the real wild thing is lambda, and i'm fine with that. Constructing on-the-fly functions that have no real use outside of the defun itself are pretty advanced programming, imo, and I look forward to a day where I can use them as fluently as pbejse and/or leemac. No offense others but I frequently see these two using and abusing lambda to spread joy to nerds in need everywhere. 
I won't press too hard right now to fully understand the most apt uses of lambda but even a few easier functions that at least allow some comprehension and when/where a lambda might be useful seem the most correct steps to take at the moment, much in the same way that mapcar was approached in this thread.
Another time, as client work beckons

Fixo, Lee, Rhino, mailmaverick, Gile, jvillareal---much obliged. This was a big step.

[Bhull1985]

Two more quick things:

Fixo
Your first post was an inspiration.

Thanks for joining the discussion....


And as far as the benchmarking results, if I'm reading those correctly then the most direct method is the quickest. I say most direct because I don't believe it's mere chance that has me understanding car, caddr, list, and the primitives in order to construct this statement. Much more experience must be known in order to approach such a task, and have the foresight to realize that there are multiple ways to accomplish the task.....no, see, me as a fledgling, there was just one way, and I was directly going about it. It's just interesting that it would be the most direct in relation to speed (efficiency) as well. On that note, whenever I see (reverse) and (cons) in the same statement, my eyes glaze over. Although, even that i'm beginning to get a feel for. If an item is appended to a list or if two items are made into a list typically the most recent item added would be placed at the bottom of the list, a call to (reverse) gives this the order of newest-to-oldest. Simple enough, maybe i'll need to spend some time with those too.

Ah the neverending world of lisp, limitless and useful knowledge with a company of designers and drafters to be my guinea pigs, but oh did I mention the joy that a steady stream of learning can give to someone who seeks to challenge themselves, typically bored crazy with what others would find "challenging". It's nice to be able to speak with like minded individuals, with no pretenses other than the code itself that we all wrap around us, making ourselves important, lining our bank accounts (hopefully!)
I appreciate each and every post and discussion I can read or take a part of, just saying....it all culminates into something quite nice, and i'm finding these skills are highly desirable and incredibly rare! And I thank you for allowing me to spread my wings and learn more, each and every day.

[Lee Mac]

It's nice to be able to speak with like minded individuals, with no pretenses other than the code itself that we all wrap around us

It's what the Swamp is all about and what makes this such a great place to visit