Author Topic: logic doubt  (Read 10376 times)

0 Members and 1 Guest are viewing this topic.

ribarm

  • Gator
  • Posts: 3270
  • Marko Ribar, architect
logic doubt
« 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...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

roy_043

  • Water Moccasin
  • Posts: 1895
  • BricsCAD 18
Re: logic doubt
« Reply #1 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.

Marc'Antonio Alessi

  • Swamp Rat
  • Posts: 1451
  • Marco
Re: logic doubt
« Reply #2 on: March 08, 2019, 06:23:15 AM »
More simple?
(or (and x y) (progn ...))

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2135
  • class keyThumper<T>:ILazy<T>
Re: logic doubt
« Reply #3 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
Called Kerry in my other life
Retired; but they dragged me back in !

I live at UTC + 13.00

---
some people complain about loading the dishwasher.
Sometimes the question is more important than the answer.

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2135
  • class keyThumper<T>:ILazy<T>
Re: logic doubt
« Reply #4 on: March 08, 2019, 06:26:26 AM »
More simple?
(or (and x y) (progn ...))

I think you meant to post something else.
Called Kerry in my other life
Retired; but they dragged me back in !

I live at UTC + 13.00

---
some people complain about loading the dishwasher.
Sometimes the question is more important than the answer.

ribarm

  • Gator
  • Posts: 3270
  • Marko Ribar, architect
Re: logic doubt
« Reply #5 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...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2135
  • class keyThumper<T>:ILazy<T>
Re: logic doubt
« Reply #6 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.
Called Kerry in my other life
Retired; but they dragged me back in !

I live at UTC + 13.00

---
some people complain about loading the dishwasher.
Sometimes the question is more important than the answer.

ribarm

  • Gator
  • Posts: 3270
  • Marko Ribar, architect
Re: logic doubt
« Reply #7 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...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

Marc'Antonio Alessi

  • Swamp Rat
  • Posts: 1451
  • Marco
Re: logic doubt
« Reply #8 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

ribarm

  • Gator
  • Posts: 3270
  • Marko Ribar, architect
Re: logic doubt
« Reply #9 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 ...
  )
)
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #10 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.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Marc'Antonio Alessi

  • Swamp Rat
  • Posts: 1451
  • Marco
Re: logic doubt
« Reply #11 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) )
)

ribarm

  • Gator
  • Posts: 3270
  • Marko Ribar, architect
Re: logic doubt
« Reply #12 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...
Marko Ribar, d.i.a. (graduated engineer of architecture)

:)

M.R. on Youtube

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #13 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.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2135
  • class keyThumper<T>:ILazy<T>
Re: logic doubt
« Reply #14 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.
« Last Edit: March 08, 2019, 05:22:03 PM by kdub »
Called Kerry in my other life
Retired; but they dragged me back in !

I live at UTC + 13.00

---
some people complain about loading the dishwasher.
Sometimes the question is more important than the answer.

VovKa

  • Water Moccasin
  • Posts: 1631
  • Ukraine
Re: logic doubt
« Reply #15 on: March 08, 2019, 05:04:53 PM »
Lisp checks ALL conditionals.
Code: [Select]
(or (setq a 1) (setq a 2))

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2135
  • class keyThumper<T>:ILazy<T>
Re: logic doubt
« Reply #16 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.
Called Kerry in my other life
Retired; but they dragged me back in !

I live at UTC + 13.00

---
some people complain about loading the dishwasher.
Sometimes the question is more important than the answer.

Grrr1337

  • Swamp Rat
  • Posts: 812
Re: logic doubt
« Reply #17 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 which stated this:
Quote
Ultimatly all that was required was a simple COND statement to implement the concept

:)

Cheers!
(apply ''((a b c)(a b c))
  '(
    (( f L ) (apply 'strcat (f L)))
    (( L ) (if L (cons (chr (car L)) (f (cdr L)))))
    (72 101 108 108 111 32 87 111 114 108 100)
  )
)
vevo.bg

Marc'Antonio Alessi

  • Swamp Rat
  • Posts: 1451
  • Marco
Re: logic doubt
« Reply #18 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"

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

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2135
  • class keyThumper<T>:ILazy<T>
Re: logic doubt
« Reply #19 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,
Called Kerry in my other life
Retired; but they dragged me back in !

I live at UTC + 13.00

---
some people complain about loading the dishwasher.
Sometimes the question is more important than the answer.

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #20 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.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #21 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.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #22 on: March 09, 2019, 12:41:15 PM »
the gray stuff is difficult to understand , particularly on Saturdays and Wednesdays.

TRUTH
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #23 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.
« Last Edit: March 09, 2019, 03:18:19 PM by MP »
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Stefan

  • Bull Frog
  • Posts: 319
  • The most I miss IRL is the Undo button
Re: logic doubt
« Reply #24 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...

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #25 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?
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Stefan

  • Bull Frog
  • Posts: 319
  • The most I miss IRL is the Undo button
Re: logic doubt
« Reply #26 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

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #27 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 we’re back to "the ugly code".
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Stefan

  • Bull Frog
  • Posts: 319
  • The most I miss IRL is the Undo button
Re: logic doubt
« Reply #28 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 we’re 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)
)

MP

  • Seagull
  • Posts: 17750
  • Have thousands of dwgs to process? Contact me.
Re: logic doubt
« Reply #29 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)
)



Some day I’ll grow up, but not today lol.
Engineering Technologist • CAD Automation Practitioner
Automation ▸ Design ▸ Drafting ▸ Document Control ▸ Client
cadanalyst@gmail.com • http://cadanalyst.slack.com • http://linkedin.com/in/cadanalyst

Stefan

  • Bull Frog
  • Posts: 319
  • The most I miss IRL is the Undo button
Re: logic doubt
« Reply #30 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)
)



Some day I’ll grow up, but not today lol.

Even the otter is prettier

Lee Mac

  • Seagull
  • Posts: 12913
  • London, England
Re: logic doubt
« Reply #31 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. :-)