### Author Topic: Well tested common functions library - should we have it?  (Read 16201 times)

0 Members and 1 Guest are viewing this topic.

#### divtiply

• Guest
##### Well tested common functions library - should we have it?
« on: December 06, 2013, 08:53:31 AM »
Whe are reinventing the wheel, again and again. It's not bad - we are learning.
The bad is that some of common functions are implemented wrongly or not time effective.
For example, ymg's ceil/floor functions [http://www.theswamp.org/index.php?topic=45379.msg505421#msg505421]:

Code - Auto/Visual Lisp: [Select]
1. ;; Ceiling function, Returns the smallest integer not less than x.            ;
2. (defun ceil (x) (if (minusp x)(fix x)(1+ (fix x))))
3. ;; Floor function, Returns the largest integer not greater than x.            ;
4. (defun floor (x) (if (minusp x)(1- (fix x))(fix x)))

are little bit wrong, because:
Code - Auto/Visual Lisp: [Select]
1. (ceil 1) => 2
2. (floor -1) => -2

Correct implementation is:

Code - Auto/Visual Lisp: [Select]
1. (defun floor (num)
2.   (if (zerop (- num (setq num (fix num))))
3.     num
4.     (if (minusp num) (1- num) num)))
5.
6. (defun ceiling (num)
7.   (if (zerop (- num (setq num (fix num))))
8.     num
9.     (if (minusp num) num (1+ num))))

So, should we make a library with a well tested, speed effective functions?

#### Lee Mac

• Seagull
• Posts: 12892
• London, England
##### Re: Well tested common functions library - should we have it?
« Reply #1 on: December 06, 2013, 09:06:04 AM »
So, should we make a library with a well tested, speed effective functions?

#### divtiply

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #2 on: December 06, 2013, 09:09:56 AM »

Same as ymg's implementation error in std-floor/std-ceiling.
So it is not well tested ))

#### LE3

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #3 on: December 06, 2013, 09:21:21 AM »
An ex-lisper comment:

In all my past years spent (20+-) in the autolisp/vlisp world --- the only way or form I have seen to adopt a function as standard it is when these are added into the autolisp core. Anything out it will be way too difficult - will only be part of anyone's personal functions arsenal. Have seen so many try-outs -- ALL have failed.

Let see if this time not.

LE!

#### divtiply

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #4 on: December 06, 2013, 09:25:22 AM »
I'll give you a bit, tell me should I continue?

Code - Auto/Visual Lisp: [Select]
1.   (setq consp vl-consp)
2.   (defun consp (obj)
3.     (not (atom obj))))
4.
5. (defun dotted-pair-p (obj)
6.   (and (consp obj) (not (listp (cdr obj)))))
7.
8. (if vl-list-length
9.   (defun dotted-list-p (obj)
10.     (and (consp obj)
11.          (not (vl-list-length obj))))
12.   (defun dotted-list-p (obj)
13.     (and (consp obj)
14.          (dotted-pair-p (last-pair obj)))))
15.
16. (defun association-list-p (obj)
17.   (and (consp obj)
18.        (every 'consp obj)))
19.
20. (setq first   (cond (vle-nth0)(car))
24.       fifth   (cond (vle-nth4)((lambda (list) (car (cddddr list)))))
25.       sixth   (cond (vle-nth5)((lambda (list) (cadr (cddddr list)))))
26.       seventh (cond (vle-nth6)((lambda (list) (caddr (cddddr list)))))
27.       eighth  (cond (vle-nth7)((lambda (list) (cadddr (cddddr list)))))
28.       ninth   (cond (vle-nth8)((lambda (list) (car (cddddr (cddddr list))))))
29.       tenth   (cond (vle-nth9)((lambda (list) (cadr (cddddr (cddddr list))))))
30.       rest    cdr)
31.
32. (if vle-sublist
33.   (defun nthcdr (n lst)
34.     (vle-sublist lst n 0))
35.   (defun nthcdr (n lst)
36.     (nth n (list nil)) ; parameter validation
37.     (while (and lst (not (zerop n)))
38.       (setq n (1- n)
39.             lst (cdr lst)))
40.     lst))
41.
42. (if vle-sublist
43.   (defun firstn (n lst)
44.     (vle-sublist lst 0 n))
45.   (defun firstn (n lst / out)
46.     (nth n (list nil)) ; parameter validation
47.     (while (and lst (not (zerop n)))
48.       (setq n (1- n)
49.             out (cons (car lst) out)
50.             lst (cdr lst)))
51.     (reverse out)))
52.
53. (if vle-sublist
54.   (defun lastn (n lst)
55.     (vle-sublist lst (- (length lst) n) 0))
56.   (defun lastn (n lst / out)
57.     (nth n (list nil)) ; parameter validation
58.     (setq lst (reverse lst))
59.     (while (and lst (not (zerop n)))
60.       (setq n (1- n)
61.             out (cons (car lst) out)
62.             lst (cdr lst)))
63.     out))
64.
65. (defun last-pair (lst)
66.   (while (consp (cdr lst))
67.     (setq lst (cdr lst)))
68.   lst)
69.
70. (if vle-remove-last
71.   (setq butlast vle-remove-last)
72.   (defun butlast (lst)
73.     (reverse (cdr (reverse lst)))))
74.
75. (if vle-sublist
76.   (defun butlastn (n lst)
77.     (vle-sublist lst 0 (- (length lst) n)))
78.   (defun butlastn (n lst)
79.     (reverse (nthcdr n (reverse lst)))))
80.
81. (defun ldiff (lst sublst / out)
82.   (while (and lst (not (eq lst sublst)))
83.     (setq out (cons (car lst) out)
84.           lst (cdr lst)))
85.   (reverse out))
86.
87. (if vle-sublist
88.   (setq sublist vle-sublist)
89.   (defun sublist (lst start len)
90.     (firstn len (nthcdr start lst))))
91.
92. (if vle-sublist
93.   (defun split-at (n lst)
94.     (cons (vle-sublist lst 0 n) (vle-sublist lst n 0)))
95.   (defun split-at (n lst / out)
96.     (nth n (list nil)) ; parameter validation
97.     (while (and lst (not (zerop n)))
98.       (setq n (1- n)
99.             out (cons (car lst) out)
100.             lst (cdr lst)))
101.     (cons (reverse out) lst)))
102.
103. (defun split-at-first (item lst / out)
104.   (while (and lst (not (equal item (car lst))))
105.     (setq out (cons (car lst) out)
106.           lst (cdr lst)))
107.   (cons (reverse out) lst))
108.
109. (defun split-at-last (item lst / out1 out2)
110.   (setq out1 (reverse lst))
111.   (while (and out1 (not (equal item (car out1))))
112.     (setq out2 (cons (car out1) out2)
113.           out1 (cdr out1)))
114.   (if out1
115.     (cons (reverse (cdr out1)) (cons (car out1) out2))
116.     (list lst)))
117.
118. (defun split-if (pred lst / out)
119.   (while (and lst (not (apply pred (list (car lst)))))
120.     (setq out (cons (car lst) out)
121.           lst (cdr lst)))
122.   (cons (reverse out) lst))
123.
124. (defun split-if-not (pred lst / out)
125.   (while (and lst (apply pred (list (car lst))))
126.     (setq out (cons (car lst) out)
127.           lst (cdr lst)))
128.   (cons (reverse out) lst))
129.
130. (defun partition (pred lst / out1 out2)
131.   (foreach x lst
132.     (if (apply pred (list x))
133.       (setq out1 (cons x out1))
134.       (setq out2 (cons x out2))))
135.   (cons (reverse out1) (reverse out2)))
136.
137. (if vl-list-length
138.   (setq list-length vl-list-length)
139.   (defun list-length (lst / len)
140.     (setq len 0)
141.     (while (and lst (listp (setq lst (cdr lst))))
142.       (setq len (1+ len)))
143.     (if (null lst) len)))
144.
145. (defun revappend (lst obj)
146.   (while lst
147.     (setq obj (cons (car lst) obj)
148.           lst (cdr lst)))
149.   obj)
150.
151. (defun unfold (p f g seed / lst)
152.   (while (not (apply p (list seed)))
153.     (setq lst (cons (apply f (list seed)) lst)
154.           seed (apply g (list seed))))
155.   (reverse lst))
156.
157. (defun fold (fn init lst)
158.   (foreach x lst
159.     (setq init (apply fn (list x init))))
160.   init)
161.
162. (defun reduce (func lst)
163.   (fold func (car lst) (cdr lst)))
164.
165.   (setq every vl-every)
166.   (defun every (pred lst / res)
167.     (while (and (setq res (apply pred (list (car lst))))
168.                 (setq lst (cdr lst))))
169.     res))
170.
171.   (setq some vl-some)
172.   (defun some (pred lst / res)
173.     (while (and (setq res (not (apply pred (list (car lst)))))
174.                 (setq lst (cdr lst))))
175.     (not res)))
176.
177. (if vl-member-if
178.   (setq member-if vl-member-if)
179.   (defun member-if (pred lst)
180.     (while (and lst (not (apply pred (list (car lst)))))
181.       (setq lst (cdr lst)))))
182.
183. (if vl-member-if-not
184.   (setq member-if-not vl-member-if-not)
185.   (defun member-if-not (pred lst) ; aka drop-while
186.     (while (and lst (apply pred (list (car lst))))
187.       (setq lst (cdr lst)))))
188.
189.   (setq position vl-position)
190.   (defun position (item lst / n)
191.     (setq n 0)
192.     (while (and lst (not (equal item (car lst))))
193.       (setq n (1+ n)
194.             lst (cdr lst)))
195.     (if lst n)))
196.
197. (defun position-if (pred lst / n)
198.   (setq n 0)
199.   (while (and lst (not (apply pred (list (car lst)))))
200.     (setq n (1+ n)
201.           lst (cdr lst)))
202.   (if lst n))
203.
204. (defun position-if-not (pred lst / n)
205.   (setq n 0)
206.   (while (and lst (apply pred (list (car lst))))
207.     (setq n (1+ n)
208.           lst (cdr lst)))
209.   (if lst n))
210.
211. (defun count (item lst / cnt)
212.   (setq cnt 0)
213.   (foreach x lst
214.     (if (equal item x)
215.       (setq cnt (1+ cnt))))
216.   cnt)
217.
218. (defun count-if (pred lst / cnt)
219.   (setq cnt 0)
220.   (foreach x lst
221.     (if (apply pred (list x))
222.       (setq cnt (1+ cnt))))
223.   cnt)
224.
225. (defun count-if-not (pred lst / cnt)
226.   (setq cnt 0)
227.   (foreach x lst
228.     (or (apply pred (list x))
229.         (setq cnt (1+ cnt))))
230.   cnt)
231.
232. (defun subst-if (new pred lst)
233.   (mapcar (function (lambda (x) (if (apply pred (list x)) new x)))
234.           lst))
235.
236. (defun subst-if-not (new pred lst)
237.   (mapcar (function (lambda (x) (if (apply pred (list x)) x new)))
238.           lst))
239.
240. (if vle-subst-nth
241.   (defun subst-nth (new n lst)
242.     (vle-subst-nth lst n new))
243.   (defun subst-nth (new n lst)
244.     (setq lst (split-at n lst))
245.     (if (cdr lst)
246.       (append (car lst) (cons new (cddr lst)))
247.       (car lst))))
248.
249. (if vle-subst-nth
250.   (defun subst-first (new old lst)
251.     (setq n (position old lst))
252.     (if n
253.       (vle-subst-nth lst n new)
254.       lst))
255.   (defun subst-first (new old lst)
256.     (setq lst (split-at-first old lst))
257.     (if (cdr lst)
258.       (append (car lst) (cons new (cddr lst)))
259.       (car lst))))
260.
261. (defun subst-last (new old lst)
262.   (setq lst (split-at-last old lst))
263.       (if (cdr lst)
264.         (append (car lst) (cons new (cddr lst)))
265.         (car lst)))
266.
267.   (setq remove vl-remove)
268.   (defun remove (item lst)
269.     (apply 'append (subst nil (list item) (mapcar 'list lst)))))
270.
271. (if vl-remove-if
272.   (setq remove-if vl-remove-if)
273.   (defun remove-if (pred lst)
274.            (mapcar (function (lambda (x) (or (apply pred (list x)) (list x))))
275.                    lst))))
276.
277. (if vl-remove-if-not
278.   (setq remove-if-not vl-remove-if-not)
279.   (defun remove-if-not (pred lst)
280.            (mapcar (function (lambda (x) (if (apply pred (list x)) (list x))))
281.                    lst))))
282.
283. (if vle-remove-nth
284.   (setq remove-nth vle-remove-nth)
285.   (defun remove-nth (n lst)
286.     (setq lst (split-at n lst))
287.     (append (car lst) (cddr lst))))
288.
289. (if vle-remove-first
290.   (setq remove-first vle-remove-first)
291.   (defun remove-first (item lst)
292.     (setq lst (split-at-first item lst))
293.     (append (car lst) (cddr lst))))
294.
295. (if vle-remove-last
296.   (setq remove-last vle-remove-last)
297.   (defun remove-last (item lst)
298.     (setq lst (split-at-last item lst))
299.     (append (car lst) (cddr lst))))
300.
301. (defun insert (new n lst)
302.   (setq lst (split-at n lst))
303.   (append (car lst) (cons new (cdr lst))))

#### dgorsman

• Water Moccasin
• Posts: 2437
##### Re: Well tested common functions library - should we have it?
« Reply #5 on: December 06, 2013, 10:19:00 AM »
The only way that is "wrong" is one that doesn't work.  The shortest path is not the only way forward.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
catch (notResponsible)
finally
{MasterBasics;}

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #6 on: December 06, 2013, 03:19:02 PM »
I'll give you a bit, tell me should I continue?
The fact that Reini Urban's project was abandoned more than 10 years ago (and not picked up by 'the community') should make you think, but is in itself no reason to stop working on your project.

Some random questions and remarks:
1.
Why look at CL? And if you are going to do that, why not make the (some) function really compatible.
2.
Consistent naming scheme? You now have predicate functions with names that do not end in '-p'.
3.
You are using vle-* functions. You should be aware that a non BricsCAD user may have loaded the complete vle-extension.lsp file. Which would result in a strange situation I think.
4.
Have you ever used the (tenth) function? Would some sort of (SafeNth) function not be more useful?
5.
You should be aware that writing code is but one part of the project. Testing, documentation, examples and maintenance are also required.
6.
Is the speed of the functions important? Or are you striving for 'elegant' code? See example below.

Code: [Select]
`;;; (setq partLst '("a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m" "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z"));;; (setq testLst (append partLst partLst '(0) partLst partLst));;; (KGX_BenchMark '((vl-some 'numberp testLst) (divtiply_some 'numberp testLst) (roy_some_1 'numberp testLst) (roy_some_2 'numberp testLst)) 5000)    ; Benchmarking .......... elapsed milliseconds / relative timing <5000 iterations>      ; (VL-SOME 'NUMBERP TESTLST) ............ 16 / 8.81 <fastest>      ; (ROY_SOME_2 'NUMBERP TESTLST) ......... 63 / 2.24      ; (ROY_SOME_1 'NUMBERP TESTLST) ......... 93 / 1.52      ; (DIVTIPLY_SOME 'NUMBERP TESTLST) ..... 141 / 1.00 <slowest>`
Code - Auto/Visual Lisp: [Select]
1. ; Code taken from the (some) function in divtiply's code)
2. (defun divtiply_some (pred lst / res)
3.     (and
4.       (setq res (not (apply pred (list (car lst)))))
5.       (setq lst (cdr lst))
6.     )
7.   )
8.   (not res)
9. )
10.
11. ; Some improvements:
12. (defun roy_some_1 (pred lst / res)
13.   (setq pred (eval pred))
14.     (and
15.       (not (setq res (pred (car lst))))
16.       (setq lst (cdr lst))
17.     )
18.   )
19.   res
20. )
21.
22. ; With additional speed improvement based on Reini Urban's (std-%setnth):
23. (defun roy_some_2 (pred lst / res)
24.   (setq pred (eval pred))
25.     (and
27.       (not
28.         (setq res
29.           (or
30.             (pred (car lst))
34.           )
35.         )
36.       )
37.     )
38.     (setq lst (cddddr lst))
39.   )
40.   (if (not res)
41.       (and
42.         (car lst)
43.         (not (setq res (pred (car lst))))
44.       )
45.       (setq lst (cdr lst))
46.     )
47.   )
48.   res
49. )

#### divtiply

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #7 on: December 06, 2013, 04:03:19 PM »
Code: [Select]
`; Some improvements:`
Thanks Roy!
That's why I've started this topic. Together it's easy to improve common code.
2. Consistent naming scheme? You now have predicate functions with names that do not end in '-p'.
Which?
« Last Edit: December 06, 2013, 04:20:57 PM by divtiply »

#### Jeff H

• Needs a day job
• Posts: 6142
##### Re: Well tested common functions library - should we have it?
« Reply #8 on: December 06, 2013, 04:41:53 PM »
I have only played with AutoLisp here and there, but I will write the section on variable naming standards.

1. Do NOT be descriptive.
2. Try to keep variable names 3 letters or less.
3. Try to use a lower case 'l' as frequently as possible('l' is not the number one it is lowercase 'L').

Done.

#### divtiply

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #9 on: December 06, 2013, 04:48:29 PM »
1. Do NOT be descriptive.
2. Try to keep variable names 3 letters or less.
3. Try to use a lower case 'l' as frequently as possible('l' is not the number one it is lowercase 'L').

You prefer names like list-to-search-within instead of lst?

#### Jeff H

• Needs a day job
• Posts: 6142
##### Re: Well tested common functions library - should we have it?
« Reply #10 on: December 06, 2013, 04:56:24 PM »
Hi divtiply,

That was not directed toward you or any code you posted. It was a joke from a non-lisper who is not familiar with the language or the conventions and seeing snippets of code with 'a', 'l', etc... as variables.

#### dgorsman

• Water Moccasin
• Posts: 2437
##### Re: Well tested common functions library - should we have it?
« Reply #11 on: December 06, 2013, 06:18:53 PM »
Hi divtiply,

That was not directed toward you or any code you posted. It was a joke from a non-lisper who is not familiar with the language or the conventions and seeing snippets of code with 'a', 'l', etc... as variables.

Brought a smile to my face, at least.
If you are going to fly by the seat of your pants, expect friction burns.

try {GreatPower;}
catch (notResponsible)
finally
{MasterBasics;}

#### danallen

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #12 on: December 06, 2013, 07:05:16 PM »
does anyone have routines from Looking Glass Microproducts? I had collected some from the very old cad shack website and it was very useful for learning and putting together my own routines. (also probably was not legitimately shared though...

An ex-lisper comment:

In all my past years spent (20+-) in the autolisp/vlisp world --- the only way or form I have seen to adopt a function as standard it is when these are added into the autolisp core. Anything out it will be way too difficult - will only be part of anyone's personal functions arsenal. Have seen so many try-outs -- ALL have failed.

Let see if this time not.

LE!

#### LE3

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #13 on: December 06, 2013, 08:22:59 PM »
does anyone have routines from Looking Glass Microproducts? I had collected some from the very old cad shack website and it was very useful for learning and putting together my own routines. (also probably was not legitimately shared though...

Oh!
The old master Phil Kreiker --- I remember those on cadence magazine? if my 1/4 brain cell left still is working.... I am sure he wrote the 'painter' or match properties --- too btw.

did a quick search and yes he had a section on cadalyst magazine named THE CAD COOKBOOK  - so maybe if they are still available do a search on the cadalyst site.
« Last Edit: December 06, 2013, 08:39:15 PM by LE »

#### ymg

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #14 on: December 07, 2013, 02:50:55 AM »
Quote
For example, ymg's ceil/floor functions [http://www.theswamp.org/index.php?topic=45379.msg505421#msg505421]:

divtiply,

Thanks for the attribution, but these function were actually taken from std-math. http://autocad.xarch.at/stdlib/STDMATH.LSP

However I should have tested.  (Post has been updated)

And by the way Floor and Ceiling are applicable to real numbers not to integers as shown in your example.

ymg
« Last Edit: December 07, 2013, 05:24:54 AM by ymg »

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #15 on: December 07, 2013, 05:28:15 AM »
2. Consistent naming scheme? You now have predicate functions with names that do not end in '-p'.
Which?
consp
some
every

#### divtiply

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #16 on: December 07, 2013, 06:53:30 AM »
They are standard CL names. As null, for example.

#### MP

• Seagull
• Posts: 17750
• Have thousands of dwgs to process? Contact me.
##### Re: Well tested common functions library - should we have it?
« Reply #17 on: December 07, 2013, 07:41:11 AM »
Have seen so many try-outs -- ALL have failed.

Pretty much this -- a six member committee with 12 legs -- will try to walk in as many directions -- good luck.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #18 on: December 07, 2013, 08:04:17 AM »

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #19 on: December 07, 2013, 08:09:27 AM »
BTW: My (roy_some_2) has a problem:
Code: [Select]
`(defun MyFunc (a) (if (numberp a) (1+ a)))(roy_some_2 'MyFunc '("a" "b" "c" "d" 0)) => 1(roy_some_2 'MyFunc '("a" "b" "c" 0)) => T`
New version:
Code - Auto/Visual Lisp: [Select]
1. (defun roy_some_2_Revised (pred lst / res)
2.   (setq pred (eval pred))
3.     (and
5.       (not
6.         (setq res
7.           (cond
8.             ((pred (car lst)))
12.           )
13.         )
14.       )
15.     )
16.     (setq lst (cddddr lst))
17.   )
18.   (if (not res)
19.       (and
20.         (car lst)
21.         (not (setq res (pred (car lst))))
22.       )
23.       (setq lst (cdr lst))
24.     )
25.   )
26.   res
27. )

#### snownut2

• Swamp Rat
• Posts: 971
##### Re: Well tested common functions library - should we have it?
« Reply #20 on: December 07, 2013, 09:16:09 AM »
Roy,

Why "cad....r" and not "nth #"  much easier to read a number then how many "d's" to use.

Bruce

#### divtiply

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #21 on: December 07, 2013, 11:34:18 AM »
Why "cad....r" and not "nth #"

"cad...r" functions are faster than "nth n" equivalents.

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #22 on: December 07, 2013, 11:42:10 AM »
Roy,

Why "cad....r" and not "nth #"  much easier to read a number then how many "d's" to use.

Bruce

Apart from the issue of speed there also this:
On line 5 of (roy_some_2_revised) I have:
Code: [Select]
`(cadddr lst)`Because lst can be or become nil (nth) cannot be used here:
Code: [Select]
`(nth 3 nil) => Error(cadddr nil) => nil`

#### snownut2

• Swamp Rat
• Posts: 971
##### Re: Well tested common functions library - should we have it?
« Reply #23 on: December 07, 2013, 02:13:09 PM »
Roy,

Thanks for the explanation, I did not know about the nil/error difference.

Bruce

#### Jeremy

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #24 on: December 07, 2013, 07:06:24 PM »
I share some of DIVTIPLY's concerns. There are a great many functions on this board that have been optimized and benchmarked but can be impossible to find unless you know they exist. It would be nice if there could be a place to drop the most optimized version of various functions in one spot where you can see them all categorized. This would of course need updating as new people submit better algorithms. We could suggest that people use these functions in submitted code so that one is not constantly bothered with making sure every subfunction to a given function is included. A lot of repetitious space is being used over and over again.

Setting some rules for function naming is important because Autolisp is kind of a mess in that regard. Predicate functions are indeed not consistent and I have ended all of mine with a question mark rather than -p. I think "number?" is more quickly recognized as an inquiry than "numberp" is. Perhaps I am excessive but I also wrote replacements for the operators and booleans that have no "p" at all. So I have "less?" as well as "<" and "wcmatch?" instead of "wcmatch". Rather than "First","Second","Third" I would gravitate towards "1st","2nd" and "3rd" as they are shorter and I believe the digits are more rapidly comprehended than the words.

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #25 on: December 09, 2013, 03:56:22 AM »
FWIW: Another look at the (some) function.

Code: [Select]
`(vl-some 'atom nil)              => nil(divtiply_some 'atom nil)        => T(roy_some_1 'atom nil)           => T(roy_some_2_Revised 'atom nil)   => nil(roy_some_1_Revised_2 'atom nil) => nil(roy_some_2_Revised_2 'atom nil) => nil(vl-some 'atom '(nil))              => T(divtiply_some 'atom '(nil))        => T(roy_some_1 'atom '(nil))           => T(roy_some_2_Revised 'atom '(nil))   => nil(roy_some_1_Revised_2 'atom '(nil)) => T(roy_some_2_Revised_2 'atom '(nil)) => T(vl-some 'numberp '(nil nil 0 . 0))              => T(divtiply_some 'numberp '(nil nil 0 . 0))        => T(roy_some_1 'numberp '(nil nil 0 . 0))           => T(roy_some_2_Revised 'numberp '(nil nil 0 . 0))   => Error(roy_some_1_Revised_2 'numberp '(nil nil 0 . 0)) => T(roy_some_2_Revised_2 'numberp '(nil nil 0 . 0)) => T(vl-some 'numberp '(nil nil . 0))              => nil(divtiply_some 'numberp '(nil nil . 0))        => Error(roy_some_1 'numberp '(nil nil . 0))           => Error(roy_some_2_Revised 'numberp '(nil nil . 0))   => Error(roy_some_1_Revised_2 'numberp '(nil nil . 0)) => nil(roy_some_2_Revised_2 'numberp '(nil nil . 0)) => nil`
Code - Auto/Visual Lisp: [Select]
1. (defun roy_some_1_Revised_2 (pred lst / res)
2.   (setq pred (eval pred))
3.     (and
4.       (vl-consp lst)
5.       (not (setq res (pred (car lst))))
6.     )
7.     (setq lst (cdr lst))
8.   )
9.   res
10. )
11.
12. (defun roy_some_2_Revised_2 (pred lst / res)
13.   (setq pred (eval pred))
14.     (and
15.       (vl-consp lst)
16.       (vl-consp (cdr lst))
17.       (vl-consp (cddr lst))
18.       (vl-consp (cdddr lst))
19.       (not
20.         (setq res
21.           (cond
22.             ((pred (car lst)))
26.           )
27.         )
28.       )
29.     )
30.     (setq lst (cddddr lst))
31.   )
32.   (if (not res)
33.       (and
34.         (vl-consp lst)
35.         (not (setq res (pred (car lst))))
36.       )
37.       (setq lst (cdr lst))
38.     )
39.   )
40.   res
41. )

#### ymg

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #26 on: December 09, 2013, 05:20:31 AM »
Here some revised ceil and floor function.

These you may attribute to me although probably was done before.

Code - Auto/Visual Lisp: [Select]
1. (defun floor (x) (if (minusp (rem x 1)) (- (fix x) 1) (fix x)))
2. (defun ceil  (x) (if (> (rem x 1) 0) (+ (fix x) 1) (fix x)))
3.

@divtiply
As an aside, it would certainly have been appreciated if you had let me know

ymg
« Last Edit: December 09, 2013, 05:28:51 AM by ymg »

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #27 on: December 09, 2013, 06:34:58 AM »
Since the OP is a BricsCAD user this may be of interest:

BricsCAD uses OpenLisp as the basis for its Lisp-engine:
http://www.eligis.com/
OpenLisp is an ISLISP implementation:
http://islisp.info/

To be compatible with AutoLisp some functionality from the underlying Lisp-engine is blocked in BricsCAD. Which can be a frustrating idea if you goal is to extend the Lisp-library.

Note: there is also a different OpenLISP:
http://www.openlisp.org/

Edit: Typo.
« Last Edit: December 09, 2013, 10:09:33 AM by roy_043 »

#### snownut2

• Swamp Rat
• Posts: 971
##### Re: Well tested common functions library - should we have it?
« Reply #28 on: December 09, 2013, 07:39:32 AM »
Roy,

A little off subject, but do you know if OpenLisp from your last post supports DCL use.

Bruce

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #29 on: December 09, 2013, 10:29:28 AM »
do you know if OpenLisp from your last post supports DCL use.
DCL is unique to AutoCAD and some other .dwg software. So the answer is: No.

#### ymg

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #30 on: December 09, 2013, 02:51:37 PM »
divtiply,

I suggest you test your so called "correct implementation" of ceil and floor function.

Graph provided by omegatron at http://commons.wikimedia.org/wiki/File:Floor_function.svg
Ceiling Function:

Floor Function:
« Last Edit: December 09, 2013, 02:56:58 PM by ymg »

#### irneb

• Water Moccasin
• Posts: 1794
• ACad R9-2016, Revit Arch 6-2016
##### Re: Well tested common functions library - should we have it?
« Reply #31 on: December 10, 2013, 02:26:43 AM »
Had a similar idea a while back: http://www.theswamp.org/index.php?topic=39158.5

And yes CL, because it's the only one where the namings of functions (and their argument orders and expected results) is already well established in the hyperspec. If you go with something like Scheme, then you have an extremely small subset which is a prerequisite of functions R6RS - all the rest is up for grabs by the user (never mind the implementer). That means if you choose Scheme as a base (or some of the others like NewLisp) then you'd have to go through the entire process of choosing names, arguments, expected results, etc .... could be a very lengthy process especially as it would need consensus. Why not take one which has already gone through such process for several decades (i.e. Common Lisp)?

If you choose something like CL, then at least that portion is already sorted out. You can then focus on the actual implementations instead of arguing about the naming. Just my opinion

Edit: As per this discussion about floor/ceiling - http://www.lispworks.com/documentation/HyperSpec/Body/f_floorc.htm#floor
« Last Edit: December 10, 2013, 02:30:01 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

#### divtiply

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #32 on: December 10, 2013, 10:23:40 AM »
divtiply,
I suggest you test your so called "correct implementation" of ceil and floor function.

Oops. My optimizing went too far. Initial (and correct) versions was:
Code: [Select]
`(defun floor (num / n)  (if (zerop (- num (setq n (fix num))))    n    (if (minusp num) (1- n) n)))(defun ceiling (num / n)  (if (zerop (- num (setq n (fix num))))    num    (if (minusp num) n (1+ n))))`But your new code is faster.
« Last Edit: December 17, 2016, 10:15:34 AM by divtiply »

#### LE3

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #33 on: December 10, 2013, 10:57:16 AM »
For what I see so far, it will take you guys a lot of time just to agree in these two common functions... I know it is not my business to make you change (and not my intention et-al).... But see how easy can be to use the Math function for example in lisp - No rocket science:

Code - C#: [Select]
1.         [LispFunction("Ceiling")]
2.         public object Swamp_Ceiling(ResultBuffer resultBuffer)
3.         {
4.             if (resultBuffer == null || resultBuffer.AsArray().Any(tv => tv.TypeCode != RTREAL)) return null;
5.             var number = (double)resultBuffer.AsArray().FirstOrDefault(tv => tv.TypeCode == RTREAL).Value;
6.             return Math.Ceiling(number);
7.         }
8.
9.         [LispFunction("Floor")]
10.         public object Swamp_Floor(ResultBuffer resultBuffer)
11.         {
12.             if (resultBuffer == null || resultBuffer.AsArray().Any(tv => tv.TypeCode != RTREAL)) return null;
13.             var number = (double)resultBuffer.AsArray().FirstOrDefault(tv => tv.TypeCode == RTREAL).Value;
14.             return Math.Floor(number);
15.         }
16.

Even if those are done in C++/ARX:
Code - C++: [Select]
2.         {
3.                 struct resbuf *rb = acedGetArgs();
4.                 if (!rb) return RSERR;
5.                 if (rb && rb->restype != RTREAL) { acutPrintf(_T("\nError: function requires a RTREAL as argument. \n")); return RSERR; }
6.                 acedRetReal(ceil(rb->resval.rreal));
7.                 return (RSRSLT);
8.         }
9.
11.         {
12.                 struct resbuf *rb = acedGetArgs();
13.                 if (!rb) return RSERR;
14.                 if (rb && rb->restype != RTREAL) { acutPrintf(_T("\nError: function requires a RTREAL as argument. \n")); return RSERR; }
15.                 acedRetReal(floor(rb->resval.rreal));
16.                 return (RSRSLT);
17.         }
18.

Well I leave you guys here..... want to stay in the lisp world - good --- and yes autolisp it is GREAT --- but have his limitations.

See ya! and have fun.

#### ymg

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #34 on: December 10, 2013, 12:47:55 PM »
Quote
Well I leave you guys here..... want to stay in the lisp world - good --- and yes autolisp it is GREAT --- but have his limitations.

Luis,

I agree that Autolisp has his limitations. (Just like me  )

As far as moving to the .net world, probably getting too old for that.

ARX and all these carry a lot of overhead for the kind of programming we do.
I won't even compile to a VLX.

Sorry if the thread has taken this tone, but Yes! I was peeved.

ymg

#### irneb

• Water Moccasin
• Posts: 1794
• ACad R9-2016, Revit Arch 6-2016
##### Re: Well tested common functions library - should we have it?
« Reply #35 on: December 10, 2013, 11:47:31 PM »
Well I leave you guys here..... want to stay in the lisp world - good --- and yes autolisp it is GREAT --- but have his limitations.
I'm not sure how you want us to take this. But your samples aren't showing how C#/C++ is "better" than AutoLisp. It's just showing that there are already libraries you can use built into it. It wasn't always the case, the Math lib was an addon to C++, prior to that C/C++ programmers had to roll their own Ceil/floor functions too (it was actually one of the exercises I had to do in my programming degree - implement some standard math functions as a library in C++).

This entire thread is actually about implementing those libs so us AutoLispers have the use of them as well (instead of needing to design our own).
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

#### roy_043

• Water Moccasin
• Posts: 1895
##### Re: Well tested common functions library - should we have it?
« Reply #36 on: December 11, 2013, 05:04:26 AM »
To quote from a different topic:

I look forward to seeing the implementation and documentation.
Yes, me too  ... that is the main thing isn't it?

@ irneb and divtiply:
What would it take to get this off the ground?

#### LE3

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #37 on: December 11, 2013, 01:20:24 PM »
This entire thread is actually about implementing those libs so us AutoLispers have the use of them as well (instead of needing to design our own).

My point is to take advantage of what it is available - I come from a background in lisp too.

I just did an startup visual studio solution on my lunch break to export some of the Math library methods as autolisp functions, will open a new topic on the show your stuff and post the link later today here...

Have fun.

Edit: Here it is the link for my test project:
http://www.theswamp.org/index.php?topic=45841.msg509847#msg509847
« Last Edit: December 11, 2013, 02:14:58 PM by LE »

#### irneb

• Water Moccasin
• Posts: 1794
• ACad R9-2016, Revit Arch 6-2016
##### Re: Well tested common functions library - should we have it?
« Reply #38 on: December 12, 2013, 12:14:44 AM »
@ irneb and divtiply:
What would it take to get this off the ground?
Many things  most notably:
• Someone (or rather more than one, or preferably some form of "organization") to take ownership of this.
• A forum to propose new functions / items for inclusion to this library. Also to discuss & vote on these functions. Note if CL is used as a benchmark, much of this is already done for us - it's been tweaked since the '80s, so chances are that quite a lot of thought has already been incorporated
• Some method of listing the accepted functions for inclusion, perhaps just a wiki page which could be the start of documentation
• Another forum where implementations are proposed, discussed, "better" alternatives suggested and voted on.
• A site where the latest version can easily be downloaded. This should also include a wiki-like documentation which can be downloaded to a local off-line file. Another reason CL is a good choice: much of the documentation is already in the hyperspec
• A "would be nice to have" is also some buy-in from the manufacturers of the programs where AutoLisp features as an extension language. i.e. AutoCAD, BricsCAD and other similar clones. But, this is not a necessity, as most of the lib can be implemented as normal Lisp defuns instead of needing built-in additions. Further, most of these also provide other ways to add Lisp functions, like ARX/BRX, or even just through DotNet.

The list is probably not complete, but I think it shows the main hurdles to navigate.

If you guys feel creating a new project just for this is over the top, then feel free to join my Caddons project. I've already added some library functions there, together with some tools for use. It's just that I don't have the time to constantly give it the attention needed for such an undertaking on my own. It has a wiki built-in, as well as a forum for proposing "feature requests", bug reports and a general discussion.

Alternative (or in addition to) I've also started a wiki for listing possible extensions to AutoLisp, though its main aim is to revamp the entire Lisp engine to turn it into a much more powerful Lisping environment (perhaps a bit in excess of what this thread is about): http://alisp-ext.wikidot.com/

...I come from a background in lisp too...
Actually I came from the other side: Basic, Pascal, Java & C++ first, AutoLisp became like a drug after that, then I started looking at all the other Lisps and literally (note TRUE use of the word) fell in love with it. Thanks I'll take a look at that thread also.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

#### Jeff H

• Needs a day job
• Posts: 6142
##### Re: Well tested common functions library - should we have it?
« Reply #39 on: December 12, 2013, 01:37:32 AM »
... < >
I wish I knew where to GIT that.

stuffed up by kerry:
I wish I'd said that
Oooops, I really stuffed that up .. sorry Jeff

« Last Edit: December 12, 2013, 02:50:27 AM by Kerry »

#### LE3

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #40 on: December 12, 2013, 09:19:27 AM »
Actually I came from the other side: Basic, Pascal, Java & C++ first, AutoLisp became like a drug after that, then I started looking at all the other Lisps and literally (note TRUE use of the word) fell in love with it. Thanks I'll take a look at that thread also.

Wow --- That's interesting - Hope and guess you still use at least the C++ and have that advantage. I am glad that I am out of lisp as I used to.... still can do some minor stuff when needed.
Have fun!

#### irneb

• Water Moccasin
• Posts: 1794
• ACad R9-2016, Revit Arch 6-2016
##### Re: Well tested common functions library - should we have it?
« Reply #41 on: December 13, 2013, 12:49:35 AM »
Wow --- That's interesting - Hope and guess you still use at least the C++ and have that advantage. I am glad that I am out of lisp as I used to.... still can do some minor stuff when needed.
Have fun!
Actually I despised C++, I try to avoid it as much as possible - did then (mid '90s) and still feel the same. I actually preferred Java and Pascal, so C# came nearly naturally to me (it's so close to Java as to make next to no difference). None of them (however) gives me the same sense of accomplishment through absolute minimum input that Lisp does. But that's just me.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

#### Marc'Antonio Alessi

• Swamp Rat
• Posts: 1447
• Marco
##### Re: Well tested common functions library - should we have it?
« Reply #42 on: December 13, 2013, 03:32:26 AM »
Actually I despised C++, I try to avoid it as much as possible - did then (mid '90s) and still feel the same. I actually preferred Java and Pascal, so C# came nearly naturally to me (it's so close to Java as to make next to no difference). None of them (however) gives me the same sense of accomplishment through absolute minimum input that Lisp does. But that's just me.
I think it is a very widespread opinion, this is also one of the reasons for the success of Bricscad and their effort to make it compatible the maximum possible with VisualLisp. This is also demonstrated by the number of topics:
Code: [Select]
`Posts            TheSwamp-------------------------AutoLISP (Visual)   76919VB(A)                8467.NET                24517ARX Programming      2745General Programming  7244Topics           TheSwamp  Autodesk-----------------------------------AutoLISP (Visual)    6831      1842VB(A)                 910       801.NET                 2774       271ARX Programming       335       304General Programming   783 `It seems that the topics of Autodesk begin by 1999, but many have been lost, especially of AutoLISP.

#### LE3

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #43 on: December 13, 2013, 09:30:35 AM »
OK, the link for some other option to use, it is there now, it have also some more information provided by Gile too. LE!

#### ymg

• Guest
##### Re: Well tested common functions library - should we have it?
« Reply #44 on: December 13, 2013, 12:55:02 PM »
Quote
Actually I despised C++, I try to avoid it as much as possible - did then (mid '90s) and still feel the same.

You can count me in in the group that love to hate C++.

Now, If we could get optional argument to function and array (Not the monster we got now).....!

ymg

#### Jeff H

• Needs a day job
• Posts: 6142
##### Re: Well tested common functions library - should we have it?
« Reply #45 on: December 13, 2013, 02:26:17 PM »
Most people think C++ 11 code is C#.

Why not use well tested and efficient designed algorithms from communities with many more users and money to create them.

When LE exported Math functions to AutoLisp he just gave access to methods that have been used and tested by millions of people, countless hours of math and computer nerds analyzing it.

Nothing anyone said here but seems like people perceptions of other languages are based on AutoCAD's API for that language.

#### hawstom

• Newt
• Posts: 22
• AutoCAD Civil 3D, Mesa, AZ, USA
##### Re: Well tested common functions library - should we have it?
« Reply #46 on: March 13, 2017, 01:39:27 PM »