The perfect recursive function

[SOliver]

Below are the results of the time comparison of passing symbol~unevaluated-symbol. Code below was used to generate the results

;Test constant
(setq LIMIT 10000000)
;Test method
(defun c:test( / )
(setq i 0)
(princ "\nTEST 1----------")    
(princ "\nStart:")(princ (time))
(while (< (setq i(1+ i)) LIMIT)
  (test1 1+ ) 
)
(princ "\nEnd:")(princ (time))
(princ "\n-------")
(setq    i 0)
(princ "\nTEST 2----------")    
(princ "\nStart:")(princ (time))
(while (< (setq i(1+ i)) LIMIT)
  (test2 '1+ ) 
)
(princ "\nEnd:")(princ (time))
(princ "\n-------")
   (princ)
)
;Pass symbol
(defun test1 (x )
(x 1)
)
;Pass unevaluated symbol
(defun test2(x )
   ((eval x) 1)
)

;Written by
;    Kenny Ramage @ www.Afralisp.com
(defun TIME ( / d hr m s)
;define the function and declare all variables as local

    (setq d (rtos (getvar "CDATE") 2 6)
    ;get the date and time and convert to text

         hr (substr d 10 2)
     ;extract the hour

         m (substr d 12 2)
     ;extract the minute

         s (substr d 14 2)
     ;extract the second

    );setq

    (strcat hr ":" m ":" s)
    ;string 'em together

);defun

The results

                 Start             End                Difference                        
     TEST 1       17:43:39       17:43:50       00:00:11       
     TEST 2       17:43:50       17:45:03       00:01:13   

It appears that passing the symbol is a considerably more timely method than it's unevaluated counterpart.

 

As a previous comment states: The memory usage doesn't really deviate other than where it is stored.

 

I think the above more or less confirms that with native methods the pass needs to be unevaluated solely because it is parsed to another language.

Edited June 19, 2011 by SOliver
Formatting

[Lee Mac]

lmao you needed all that code to see that (x 1) was quicker than ((eval x) 1)?

[SOliver]

lmao you needed all that code to see that (x 1) was quicker than ((eval x) 1)?

 

Not so much needed more ironically given I was denouncing a proclaimation from an exulted forum member I figure I'd better writing in terms any lisp user could understand. Like psuedo code but it acutally works

 

Besides whilst I inherently proved what is noted in your comment'; I primarily proved that passing symbols is far more efficient than passing unevaluated symbols - and of course since there is no eval statement it is intrinsically safer.

Edited June 19, 2011 by SOliver
Bit of banter

[Lee Mac]

given I was denouncing the code of an exulted forum member

 

Huh? Seriously, what is this, a one-upping contest? If so - you win.

 

Do you not think I wrote my code to intentionally include the eval function...

[SOliver]

Huh? Seriously, what is this, a one-upping contest? If so - you win.

 

Do you not think I wrote my code to intentionally include the eval function...

 

On the contrary, forum members have a lot of respect for your coding and rightly so; were I to just post results or something that didn't clearly show what I had done to achieve the results the comment wouldn't get a second look I concerned myself with determining which was the more efficient method (symbol or unevaluated symbol) and found no reasons supporting unevaluated symbols , for my benefit as much as anyone else's. That said, having put the time into it and to receive

lmao you needed all that code to see that (x 1) was quicker than ((eval x) 1)?

as a response follows the disheartening theme that appears on the first page. I strive to continually improve my knowledge base and this surely is an important discussion and set of subsequent results for any lisp programmer?

 

In short: Assume makes an ass of you and me (doesn't work well written). There were a set of assumptions that left untested would lead others to the same assumptions.

[Lee Mac]

I don't know, maybe I'm reading too much into it - it just seems like you are going out of your way to pick apart minor points in my code purely because my post count on this forum is higher.

[SOliver]

I don't know, maybe I'm reading too much into it - it just seems like you are going out of your way to pick apart minor points in my code purely because my post count on this forum is higher.

 

I can only assure you that post count on any forum is not something I hold in high regard in most cases (you produce the goods to support the counter based status); I'd go as far as to say that I'm a proponent of counter removal - I've certainly written about before. The fact of the matter is, and I know this because I'm guilty of it as well - your reputation precedes your code. If a topic had results for several other members and one from yourself when asked whose the author of the code any user that implemented they used, results are going to be almost exclusively yours -without second thought for other author's code. Which is why I felt ****-retentive testing and definition was paramount to the visiblity of the findings.

 

Hehe I refer you to the opening post that this is my, and hopefully the forums, quest for the "perfect" method. Not my final boss of the forum battle lol.

Edited June 19, 2011 by SOliver

[Lee Mac]

Ok, I've probably read too much into your posts and apologise for jumping the gun with many of my comments. I'm flattered that you feel I have some kind of reputation, but I assure you that I'm still learning and would very much consider myself a 'small fish' in a big pond in regards to programming - I've barely touched the surface.

 

Anyway, back on topic.

[SOliver]

Ok, I've probably read too much into your posts and apologise for jumping the gun with many of my comments. I'm flattered that you feel I have some kind of reputation, but I assure you that I'm still learning and would very much consider myself a 'small fish' in a big pond in regards to programming - I've barely touched the surface.

 

Anyway, back on topic.

It's all good; it never hurts to have a bit of heated arguementation lol. As for the pond: it's all relative, much like the universe it's ever expanding. no amount of weightgain 5000 will change a programming fish's relative size - a fish making such a bold proclaimation is a fool or [sic] attmpting to impress the ladies.

 

Lovely stuff; we appear to have both elegancy and efficiency down to fine art over the last couple of pages. I pose the notion that we expand into a suitable method of implementing the derivative (stateles) equivalent method in such a manner as to prevent stack overflow.

 

 

I'll be the first to spit the dummy out and say that I loathe global variables but I believe that at least one is goin' to be necessary - sort of like a hash table.

 

(removed due to rushed nature, will be rewritten tomorrow)

Edited June 20, 2011 by SOliver