Topic: Determining Even or Odd

[CAB]

One question: Why have a test for both odd and even? ``If its not one...''

Readability.

Code: [Select]

(If (even? num)

Code: [Select]

(If (not (odd? num))
I don't see it as costing you anything, especially if it pleases you when you read it.

[MP]

Readability ... I don't see it as costing you anything, especially if it pleases you when you read it.

True, but ... in the bigger sense it just makes a library bigger than it need be, and while the code in this example is trivial it does mean there is more code to maintain. I would surmise that's why you don't see the compliment to predicate functions in most languages (e.g. exception: vbnet's is/isnot operators), for example in lisp there are no NotBoundP, NotNumberP, NotZeroP ... functions.

If we pin my one Boole up against your math&Boole i bet i could do better then that.

Go for it but be aware any performance gains are not realized because of the additional comparison testing one has to do in-situ, so then it comes down to practicality; ease of use.

/imo

[MP]

Another thing to consider --

Code: [Select]

(   (lambda ( / IsEvenRem IsEvenLogand TestFoo )

        (defun IsEvenRem (x) (zerop (rem x 2)))

        (defun IsEvenLogand (x) (zerop (logand 1 x)))
       
        (defun TestFoo ( foo x )       
            (princ
                (strcat
                    "Testing:" (vl-prin1-to-string foo) "\n\n"
                )   
            )
            (repeat 10
                (princ
                    (strcat     
                        (rtos (setq x (+ x 0.5)) 2 1)
                        " is "
                        (if (foo x) "even\n" "not even\n")
                    )
                )
            )
            (princ "\n")
            (princ)
        )
       
        (TestFoo IsEvenRem 0)
       
        (TestFoo IsEvenLogand 0)
       
    )
)   

Testing:#<SUBR @10327c94 ISEVENREM>

0.5 is not even
1.0 is not even
1.5 is not even
2.0 is even
2.5 is not even
3.0 is not even
3.5 is not even
4.0 is even
4.5 is not even
5.0 is not even

Testing:#<SUBR @10327ca8 ISEVENLOGAND>

Backtrace:
[0.64] (VL-BT)
[1.60] (*ERROR* "bad argument type: fixnump: 0.5")
[2.55] (_call-err-hook #<SUBR ... *ERROR*> "bad argument type: fixnump: 0.5")
[3.49] (sys-error "bad argument type: fixnump: 0.5")
:ERROR-BREAK.44 nil
[4.41] (logand 1 0.5)
[5.35] (LOGAND 1 0.5)
[6.29] (FOO 0.5)
[7.24] (TESTFOO #<SUBR @103a4f8c ISEVENLOGAND> 0)
[8.18] (#<SUBR @103f91e0 -lambda->)
[9.15] (#<SUBR @103f9258 -rts_top->)
[10.12] (#<SUBR @0de62334 veval-str-body> "((lambda ..." T #<FILE internal>)
:CALLBACK-ENTRY.6 (:CALLBACK-ENTRY)
:ARQ-SUBR-CALLBACK.3 (nil 0)

Should reals (or integers larger than 2147483647, less than -2147483647) be excluded from an even test? I don't know, what's your call?

[CAB]

Readability ... I don't see it as costing you anything, especially if it pleases you when you read it.

True, but ... in the bigger sense it just makes a library bigger than it need be, and while the code in this example is trivial it does mean there is more code to maintain. I would surmise that's why you don't see the compliment to predicate functions in most languages (e.g. exception: vbnet's is/isnot operators), for example in lisp there are no NotBoundP, NotNumberP, NotZeroP ... functions.

I don't practice that but for the sake of discussion, you could implement it this way & not worry about the maintenance issue.

Code: [Select]

(defun NotBoundP (arg)
  (not (BoundP arg))
)

(defun NotNumberP (arg)
  (not (NumberP arg))
)

(defun NotZeroP (arg)
  (not (ZeroP arg))
)

[JohnK]

*zing* ... *lmao* (I didn't see that coming)

My call: no. Not in this case. I say that because of the orig. scope of the request. The author is asking for a test to test numbers from 1-50. HOWEVER! i know that's the ``easy'' route here. -i.e. i know most people are most likely not going to ensure only int's get tested if they just toss this into their library and use it later but he does use the `fix' procedure in this case so...but, again that's kind of a cop out. Maybe i should just note that in my header that if you plan to use this or if there is a chance that there will be other types of numbers besides int's tested please seek other methods.

It all comes down to personal preference. When creating applications i prefer the proced's to be as ``little'' as they can (And by that i mean to not add too much more as far as scope goes) to save on readability and time. Its not that I would much rather come back with a diff revision later, but i like to keep my code as lean as possible.

I guess what it comes down to is: `Fun' is fun, but `production' is diff. ...I love creating procedures that take into account alot of diff situations for fun, but in production I create what needes to be created.

That's why I love using block structure in my code; I can come back and totaly change the application by adding a few lines here and a few there.

For example.

Orig: (defun odd? (i) (logand i 1) )
New:

Code: [Select]

(defun odd? ( i )
  ;; determine if a number is odd?
  ;; scope: numbers 1 -- 50 only
  (if (and (>= i 0) (<= i 50))
     (logand i 1)
     '*Error* ) )
I dont know, its a wash I suppose.

CAB, It creates maintence issues with the code. Its a bit redundant. HOWEVER! if  you are in need of a way to ``test for evens'' in a diff proced, then i can see using it. (Im saying try to name your procedures in the spirit of your application. -e.g. if you spend 100 lines `talking about evens' and then all of a sudden you `test for odd' becuse you were to lazy to alter a library function then...)