[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

This page is part of the web mail archives of SRFI 33 from before July 7th, 2015. The new archives for SRFI 33 contain all messages, not just those from before July 7th, 2015.

*To*: srfi-33@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*Subject*: n-ary nand & nor; trivial ops; replace-bit-field*From*: shivers@xxxxxxxxxxxxx*Date*: Sat, 20 Jul 2002 19:19:57 -0400*Delivered-to*: srfi-33@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx*Reply-to*: shivers@xxxxxxxxxxxxx

From: Marc Feeley <feeley@xxxxxxxxxxxxxxxx> Date: Thu, 18 Jul 2002 09:52:40 -0400 I don't understand why bitwise-nand and bitwise-nor are not n-ary. My heuristic is: "associative ops are n-ary." So if you see (f x y z) you don't have to wonder if it is (f (f x y) z) or (f x (f y z)) because it's the same. Plus and times fall under this rule, for example. However, nand and nor are not associative. OK, that's a good reason to leave them dyadic instead of variadic. On the other hand... you are right. There is a *perfectly reasonable* definition of n-ary nand: (nand x1 ... xn) = (not (and x1 ... xn)) and likewise for nor. Hardware guys, for example, have no issue drawing n-ary nand and nor gates in logic diagrams. On the other hand, the associative rule makes a nice split between the dyadics and variadics. If we make nand and nor variadic, we still have to leave andc1, andc2, orc1 and orc2 dyadic. I see the advantages of deciding both ways. It won't mess up this library if we go either way. I think I would resolve this in favor of n-ary nand & nor, but I would like to hear more opinions before I make a decision. > bitwise-eqv i ... (not (i xor j)) This would be clearer: bitwise-eqv i ... (lambda args (bitwise-not (apply bitwise-xor args))) Too much text goin' on there. I like the short & simple description. (I did try it both ways when I wrote the original draft.) > Trivial, hence not provided > bitwise-const0 i j (lambda (i j) 0) > bitwise-const1 i j (lambda (i j) -1) > bitwise-arg1 i j (lambda (i j) i) > bitwise-arg2 i j (lambda (i j) j) > bitwise-not1 i j (lambda (i j) (bitwise-not i)) > bitwise-not2 i j (lambda (i j) (bitwise-not j)) Given that these are so trivial, I would suggest that they be included in the SRFI. Dude, (lambda (i j) 0) is the clearest way to write that function down that I know. BITWISE-CONST0 is not an improvement. I know I have a rep for including the kitchen sink in my libraries, but this is beyond the pale. The power/weight ratio just doesn't justify adding six more bindings to the library. > arithmetic-shift i count -> exact-integer > Arithmetic left shift when COUNT>0; right shift when COUNT<0. Given that there is no logical shift, wouldn't it be better to call this simply "shift" or "integer-shift". I think the "arithmetic" prefix is confusing. It's the generally accepted term. And logical shift *does* make sense, if you are willing to fix (or parameterise) a word-size. > insert-bit-field size position new-field i -> exact-integer How about "replace-bit-field"? This strikes me as a much better name. I'm going ahead and making the change. Anyone who thinks it's a mistake flame away. Or confirm the decision, if you like it as Marc and I do. -Olin

- Prev by Date:
**bitop APIs in Gambit & Kawa** - Next by Date:
**NAND & NOR now n-ary; Bug in BITWISE-EQV? implementation** - Previous by thread:
**bitop APIs in Gambit & Kawa** - Next by thread:
**NAND & NOR now n-ary; Bug in BITWISE-EQV? implementation** - Index(es):