Author Topic: logic doubt  (Read 10212 times)

0 Members and 1 Guest are viewing this topic.

ribarm

  • Gator
  • Posts: 3225
  • 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: 2121
  • 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: 2121
  • 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: 3225
  • 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: 2121
  • 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: 3225
  • 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: 3225
  • 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.comhttp://cadanalyst.slack.comhttp://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: 3225
  • 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.comhttp://cadanalyst.slack.comhttp://linkedin.com/in/cadanalyst

kdub_nz

  • Mesozoic keyThumper
  • SuperMod
  • Water Moccasin
  • Posts: 2121
  • 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.