[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
n-ary nand & nor; trivial ops; replace-bit-field
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)
(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
> 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.