TheSwamp

Code Red => AutoLISP (Vanilla / Visual) => Topic started by: ribarm on March 08, 2019, 05:00:39 AM

Title: logic doubt
Post by: ribarm on March 08, 2019, 05:00:39 AM
Hi...

I have those 2 expressions which are working correctly, but I am in doubt which one should I actually use in routine :

Code: [Select]
(if (not (and x y))
  ...
)

Code: [Select]
(if (or (not x) (not y))
  ...
)

It is difficult to determine which is faster, so I am in doubt. Like I said they both are logically fine and work as desired...
Title: Re: logic doubt
Post by: roy_043 on March 08, 2019, 05:55:04 AM
Assuming that x and y have already been determined there should not be a great difference in speed.
Title: Re: logic doubt
Post by: Marc'Antonio Alessi on March 08, 2019, 06:23:15 AM
More simple?
(or (and x y) (progn ...))
Title: Re: logic doubt
Post by: kdub on March 08, 2019, 06:25:19 AM
Marginal Difference

DoIt: BENCHMARK2
DoIt: Benchmarking-V2 :B=500 [M.P.2005 <revised kdub 2005,2014>] ...........................
Elapsed milliseconds for 16777216 iteration(s)/ relative Timing :

    (OR (NOT X) (NOT Y)).....1016 / 1.0325 <slowest>: 0.00006056ms Per iteration
    (NOT (AND X Y))...........984 / 1 <fastest>: 0.00005865ms Per iteration


I'd still use the (OR (NOT X) (NOT Y))
The meaning and permutations should be grasped a lot easier by most readers
Title: Re: logic doubt
Post by: kdub on March 08, 2019, 06:26:26 AM
More simple?
(or (and x y) (progn ...))

I think you meant to post something else.
Title: Re: logic doubt
Post by: ribarm on March 08, 2019, 07:20:03 AM
Somehow, when I think in terms of reading the code, to me they both look with equal complexity... Maybe first is faster because little less operations (2 whereas second have 1 and 2 negations)... Surprisingly I coded 2nd example, but I am thinking to revise routine and put first one... If it's faster then I would ask myself, is it matter reader understand it or not? - important is that it works, isn't it?...

Maybe if someone more has some argument more in favor of second example, I'll consider it and revise revision, but for now I somehow trust benchmark and my feeling that first one is better...
Title: Re: logic doubt
Post by: kdub on March 08, 2019, 07:38:04 AM
>>  but for now I somehow trust benchmark and my feeling that first one is better...

Marco, Did you have a good look at the results ?
16 million iterations with minimal difference.
... even Marco got the logic wrong at first reading. Clarity of code IS important.
Title: Re: logic doubt
Post by: ribarm on March 08, 2019, 08:11:28 AM
>>  but for now I somehow trust benchmark and my feeling that first one is better...

Marco, Did you have a good look at the results ?
16 million iterations with minimal difference.
... even Marco got the logic wrong at first reading. Clarity of code IS important.

Does someone else think that first example is not clear as second one?
Please reply if you think so...
Title: Re: logic doubt
Post by: Marc'Antonio Alessi on March 08, 2019, 08:24:12 AM
>>  but for now I somehow trust benchmark and my feeling that first one is better...

Marco, Did you have a good look at the results ?
16 million iterations with minimal difference.
... even Marco got the logic wrong at first reading. Clarity of code IS important.
If we do not need a output value from the if:
Code: [Select]
(defun TestA () (if (not (and x y))      (print "yes"))  (princ))
(defun TestB () (if (or (not x) (not y)) (print "yes"))  (princ))
(defun TestC () (or (and x y)    (print "yes")) (princ));[color=red] progn do not needed
[/color]
Comando: (setq x T y T) T
Comando: (TestA)
Comando: (TestB)
Comando: (TestC)

Comando: (setq x T y nil) nil
Comando: (TestA) "yes"
Comando: (TestB) "yes"
Comando: (TestC) "yes"

Comando: (setq x nil y T) T
Comando: (TestA) "yes"
Comando: (TestB) "yes"
Comando: (TestC) "yes"

Comando: (setq x nil y nil) nil
Comando: (TestA) "yes"
Comando: (TestB) "yes"
Comando: (TestC) "yes"

Edit: progn
Title: Re: logic doubt
Post by: ribarm on March 08, 2019, 08:39:46 AM
>>  but for now I somehow trust benchmark and my feeling that first one is better...

Marco, Did you have a good look at the results ?
16 million iterations with minimal difference.
... even Marco got the logic wrong at first reading. Clarity of code IS important.
I we do not need a output value from the if:
Code: [Select]
(defun TestA () (if (not (and x y))      (print "yes"))  (princ))
(defun TestB () (if (or (not x) (not y)) (print "yes"))  (princ))
(defun TestC () (or (and x y)     (progn (print "yes"))) (princ))

Comando: (setq x T y T) T
Comando: (TestA)
Comando: (TestB)
Comando: (TestC)

Comando: (setq x T y nil) nil
Comando: (TestA) "yes"
Comando: (TestB) "yes"
Comando: (TestC) "yes"

Comando: (setq x nil y T) T
Comando: (TestA) "yes"
Comando: (TestB) "yes"
Comando: (TestC) "yes"

Comando: (setq x nil y nil) nil
Comando: (TestA) "yes"
Comando: (TestB) "yes"
Comando: (TestC) "yes"

Man, you are making it even more complex IMHO with (or)... Actually to be even more precise : in my routine I have this construction :

Code: [Select]
(cond
  ( (and ppp1 (null ppp2))
    (setq tst t)
  )
  ( (and ppp2 (null ppp1))
    (setq tst t)
  )
  ( (and ppp1 ppp2 (not (and (cadr ppp1) (cadr ppp2))))  ;;; here I used first example x=(cadr ppp1); y=(cadr ppp2)
    ... bla bla bla ...
  )
)
Title: Re: logic doubt
Post by: MP on March 08, 2019, 10:35:20 AM
Unless there is appreciable gains to be realized by contorting code constructs clarity should be one's primary intention. I believe this thread falls heavily on the latter, and subjective as it may be, (if (not (and x y)) ... ) is an easy, no brainer choice.
Title: Re: logic doubt
Post by: Marc'Antonio Alessi on March 08, 2019, 11:07:15 AM
Maybe this:
Code: [Select]
(cond
  ( (and (null ppp1) (null ppp2)) nil ); error
  ( (and ppp1 ppp2)
    (if (and (cadr ppp1) (cadr ppp2))
      nil ;  error
      ... bla bla bla ...
    )
  )
  ( (setq tst T) )
)
Title: Re: logic doubt
Post by: ribarm on March 08, 2019, 11:59:41 AM
(if (not (and x y)) ... ) is an easy, no brainer choice.

Can you explain little better why it is easy, no brainer choice... I constructed functions and elements with logic as much as I did with second example... So its 2:1 in favor of second... Still that don't convince me that I should revise revision...
Title: Re: logic doubt
Post by: MP on March 08, 2019, 12:33:44 PM
Can you explain little better why it is easy, no brainer choice...

Given the context the two variants were anted up in the original post the first is "a no brainer" because I can discern the logic easier than the second. To explain why would require me to reveal how my brain works, and given the empirical data I've amassed from 2 decades++ with my wife -- that's impossible. Knowing that I prefixed my statement with as subjective as it may be ....

Cheers.
Title: Re: logic doubt
Post by: kdub on March 08, 2019, 04:58:50 PM
ribarm,
As Michael indicated, after correctness it's all a matter of personal style.
My preference for the OR conctruct would depend on which day it was. Unfortunately my use of C# ( and some other languages) colors my thinking, sometines incorrectly. OR in C# returns as soon as it finds a true condition ... so for multiple choice situations sometimes it is faster. Lisp checks ALL conditionals.

Both constructs are pretty easy to understand
one says 'test are both these true, then negate the condition'
the other 'test if either of these are false'

I agree with MP regarding explaining how the artistic and analytic brain works ... the gray stuff is difficult to understand , particularly on Saturdays and Wednesdays.
Title: Re: logic doubt
Post by: VovKa on March 08, 2019, 05:04:53 PM
Lisp checks ALL conditionals.
Code: [Select]
(or (setq a 1) (setq a 2))
Title: Re: logic doubt
Post by: kdub on March 08, 2019, 05:21:21 PM
Lisp checks ALL conditionals.
Code: [Select]
(or (setq a 1) (setq a 2))

My bad ... you are correct.
Title: Re: logic doubt
Post by: Grrr1337 on March 08, 2019, 07:10:31 PM
... because I can discern the logic easier than the second. To explain why would require me to reveal how my brain works...

Cheers.

I'm on the same boat as MP - hence I'd use the most readable evaluation for me.



Coding Conventions == null

Time ago somewhere here I was discussing about how the perception about the syntax of the code changes for one
which is based on the time he spent writing in a certain language, by constantly changing or modifying his style of writing.

For example I'd dare to assume that MP's lisp coding syntax wasn't figured out in a single night by him, but rather constantly re-styled through the years.
One could trace Lee's syntax style from 2008 and how it changed till now..
I've also changed my style of writing many times, so I couldn't figure out what I was writing like 2 months ago (but in the end I ended-up with one that works for me).


BTW would be more easier to point out the different evaluations if we wrap them in a defuns, just like Marc'Antonio Alessi suggested -

Code: [Select]
(defun f1 (x y)
  (not (and x y))
)

(defun f2 (x y)
  (or (not x) (not y))
)

(defun f3 ( x y )
  (vl-some 'not (list x y))
)

(defun f4 ( x y )
  (not (vl-every 'eval (list x y)))
)

(defun f5 ( x y )
  (not (if x y))
)

(defun f6 ( x y )
  (cond
    ( (not x) )
    ( (not y) )
  )
)

Sample test to check if our evaluations work as expected -

Code: [Select]
(mapcar
  '(lambda (x)
    (list
      (apply 'f1 x)
      (apply 'f2 x)
      (apply 'f3 x)
      (apply 'f4 x)
      (apply 'f5 x)
      (apply 'f6 x)
    )
  )
  '((t nil)(nil t)(t t)(nil nil))
)
>> ((T T T T T T) (T T T T T T) (nil nil nil nil nil nil) (T T T T T T))

If the speed doesn't matter then my reading preferences would be on the evaluations within the functions f3 and f6.

f6 brings me memories about a fragment of John's post (http://www.theswamp.org/index.php?topic=53278.msg580296#msg580296) which stated this:
Quote
Ultimatly all that was required was a simple COND statement to implement the concept

:)

Cheers!
Title: Re: logic doubt
Post by: Marc'Antonio Alessi on March 09, 2019, 04:22:57 AM
More simple?
(or (and x y) (progn ...))

I think you meant to post something else.
Excuse my ignorance and incompetence, would you please be so kind to explain to me why what I wrote is completely wrong?
Thank you for your time.  :-)

Code: [Select]
OP:
(if (not (and x y))       ...)
(if (or (not x) (not y))  ...)

My Post:
(or (and x y)     (progn ...))

-----------------------------------

(defun TestA () (if (not (and x y))      (print "yes")) (princ))
(defun TestB () (if (or (not x) (not y)) (print "yes")) (princ))
(defun TestC () (or (and x y)            (print "yes")) (princ))

Code: [Select]
-----------------------------------
Comando: (setq x T y T) T

Comando: (TestA) =>
Comando: (TestB) =>
Comando: (TestC) =>

------------------------------------
Comando: (setq x T y nil) nil

Comando: (TestA) => "yes"
Comando: (TestB) => "yes"
Comando: (TestC) => "yes"

------------------------------------
Comando: (setq x nil y T) T

Comando: (TestA) => "yes"
Comando: (TestB) => "yes"
Comando: (TestC) => "yes"

------------------------------------
Comando: (setq x nil y nil) nil

Comando: (TestA) => "yes"
Comando: (TestB) => "yes"
Comando: (TestC) => "yes"

------------------------------------
Title: Re: logic doubt
Post by: kdub on March 09, 2019, 05:03:27 AM
Settle down Marc' .. I didn't say or intimate you were ignorant and incompetent ... I just thought you posted something other than intended.

This is how I read the code you posted.
Code - Auto/Visual Lisp: [Select]
  1.  
  2. (or
  3.      (and x y)      ; first conditional test
  4.      (progn ...)    ; second conditional test  
  5. )
  6.  
  7.  

Regards,
Title: Re: logic doubt
Post by: MP on March 09, 2019, 12:38:03 PM
For example I'd dare to assume that MP's lisp coding syntax wasn't figured out in a single night by him, but rather constantly re-styled through the years.

Pretty much 2 phases primary phases. When I first learned LISP I used an indent of 2 spaces. As work demanded the employ of additional languages I opted to use an indent of 4 spaces universally. The effect on my LISP coding was that it required a more vertical orientation if I wanted to honour a margin of 80 chars. Other changes if present are more subtle, reflecting continued knowledge and growth in my programming quest. Or the quantity of coffee on a given day.

BTW would be more easier to point out the different evaluations if we wrap them in a defuns ...

Code: [Select]
(defun f1 (x y)
  (not (and x y))
)

...

While I appreciate the simplification you aim to achieve for me this erodes the signal to noise ratio.

I can discern (if (not (and x y)) ...) far faster -- and in-situ -- than (if (f1 x y) ...) as f1 is meaningless until I search thru source code for the def. While a construct like (mapcar '(lambda (x) (list (apply 'f1 x) ...) may occupy less real estate in a working program for demonstration purposes I find it difficult to see benefit as reading clarity was fundamental to the original inquiry.

Beer.
Title: Re: logic doubt
Post by: MP on March 09, 2019, 12:40:23 PM
Lisp checks ALL conditionals.
Code: [Select]
(or (setq a 1) (setq a 2))

My bad ... you are correct.

You had the malady correct (lack of short-circuit evaluation), wrong patient: VBA.
Title: Re: logic doubt
Post by: MP on March 09, 2019, 12:41:15 PM
the gray stuff is difficult to understand , particularly on Saturdays and Wednesdays.

TRUTH
Title: Re: logic doubt
Post by: MP on March 09, 2019, 01:10:23 PM
More simple?
(or (and x y) (progn ...))

I see your intent Marco but for me it requires pause, whereas the easy digestion of (if (not (and x y)) ...) makes the latter preferable.

Cheers.
Title: Re: logic doubt
Post by: Stefan on March 09, 2019, 02:36:39 PM
Hi...

I have those 2 expressions which are working correctly, but I am in doubt which one should I actually use in routine :

Code: [Select]
(if (not (and x y))
  ...
)

Code: [Select]
(if (or (not x) (not y))
  ...
)

It is difficult to determine which is faster, so I am in doubt. Like I said they both are logically fine and work as desired...

Marco, both are ugly... Without seeing the big picture, I can only suggest what it seems to me more elegant:
Instead of:
Code: [Select]
(if
  (not (and x y))
  (do_the_stuff)
  (do_the_other_stuff)
)
use
Code: [Select]
(if
  (and x y)
  (do_the_other_stuff)
  (do_the_stuff)
)
I know, I know... you didn't mention anything about any ELSE statement, but then it looks even more... oh, well,  you know what I mean...
Title: Re: logic doubt
Post by: MP on March 09, 2019, 03:21:10 PM
Marco, both are ugly...

Disagree, logic is relatively concise, and the intention clear: do something if either x and y are nil.

<snip> ... seems to me more elegant: <snip>

use:

(if (and x y)
  (do_the_other_stuff)
  (do_the_stuff)
)

What if there is no need to perform something when x and y are non nil?
Title: Re: logic doubt
Post by: Stefan on March 09, 2019, 03:45:51 PM
Marco, both are ugly...

Disagree, logic is relatively concise, and the intention clear: do something if either x and y are nil.

<snip> ... seems to me more elegant: <snip>

use:

(if (and x y)
  (do_the_other_stuff)
  (do_the_stuff)
)

What if there is no need to perform something when x and y are non nil?

Yeah, I know, I already mentioned that possibility.
Still ugly to me
Title: Re: logic doubt
Post by: MP on March 09, 2019, 03:51:46 PM
Yeah, I know, I already mentioned that possibility.

Far more than a possibility given the original post so were back to "the ugly code".
Title: Re: logic doubt
Post by: Stefan on March 09, 2019, 04:12:14 PM
Yeah, I know, I already mentioned that possibility.

Far more than a possibility given the original post so were back to "the ugly code".

OK, no more"ugly code". Let me reformulate.
Marko, in case of an "else" statement, you can use
Code: [Select]
(if
  (and x y)
  (do_the_oter_stuff)
  (do_the_stuff)
)
Title: Re: logic doubt
Post by: MP on March 09, 2019, 04:36:36 PM
OK, no more"ugly code". Let me reformulate.
Marko, in case of an "else" statement, you can use
Code: [Select]
(if
  (and x y)
  (do_the_oter_stuff)
  (do_the_stuff)
)

(http://i.imgflip.com/2vn3la.jpg)

Some day Ill grow up, but not today lol.
Title: Re: logic doubt
Post by: Stefan on March 09, 2019, 04:44:53 PM
OK, no more"ugly code". Let me reformulate.
Marko, in case of an "else" statement, you can use
Code: [Select]
(if
  (and x y)
  (do_the_oter_stuff)
  (do_the_stuff)
)

(http://i.imgflip.com/2vn3la.jpg)

Some day Ill grow up, but not today lol.

Even the otter is prettier
Title: Re: logic doubt
Post by: Lee Mac on March 09, 2019, 06:36:40 PM
For example I'd dare to assume that MP's lisp coding syntax wasn't figured out in a single night by him, but rather constantly re-styled through the years.

When I first learned LISP I used an indent of 2 spaces. As work demanded the employ of additional languages I opted to use an indent of 4 spaces universally.

Ditto - Python converted me to 4 spaces and I haven't looked back since. :-)