3 ms·

MACLISP also had a BOOLE function, which had an extra argument with 16 possible values., e.g. (BOOLE 1 x y) was equivalent to x & y (1 = 0001 => AND) (

MACLISP also had a BOOLE function, which had an extra argument with 16 possible values., e.g. (BOOLE 1 x y) was equivalent to x & y (1 = 0001 => AND) (BOOLE 6 x y) was equivalent to x ^ y (6 = 0110 => XOR) (BOOLE 7 x y) was equivalent to x | y (7 = 0111 => OR) (BOOLE 14 x y) was equivalent to ~(x & y) (14 = 1110 => NAND) i.e. the first argument always corresponds to the values in the binary operation table (as shown in your table). But in Common Lisp, the values are in an arbitrary order with, e.g. boole-and = 6 instead of 1 (0001), boole-xor = 8 instead of 6 (0110), and boole-nand = 10 instead of 14 (1110). As well as being arbitrary, this unnecessarily breaks backward compatibility with MACLISP.

Jtsummers 4y ago
boole-and 0 0 0 1 and boole-nand 1 1 1 0 not-and While boole-and appears in the 6th (counting from 0) position, it still has a binary representation here of 1, and boole-nand is (reasonably) its complement with 14. It seems the table has been reordered for some reason for this presentation. It seems to present 0-ary, 1-ary, 2-ary operations in that order, which doesn't correspond to the order of the binary representation.
- gumby 4y ago
  If I remember correctly these are the PDP-10 Boolean operator codes.
  - Jtsummers 4y ago
    Yep, zachbeane's near-simultaneous comment to mine has a link with details on that.
kazinator 4y ago
The order is implementation-specific. For the values I cared to sample below, CLISP seems to have sane values that reflect the truth tables: [1]> boole-clr 0 [2]> boole-set 15 [3]> boole-and 8 [4]> boole-ior 14 [5]> boole-nand 7 Obviously, values with this property are not unique; they depend on the bit combination order. boole-and and boole-ior could plausibly be 1 and 7. IMHO, the latitude in the spec should be interpreted as accommodating this truth table ordering variation, and not as an invitation for arbitrarily enumerating the functions so that the values don't make sense as truth tables. That is to say, it should be possible to perform logical operations on the values whose interpretation is that the truth tables are combined accordingly, such that these two are equivalent: (boole (logior boole-xxx boole-yyy) a b) <--> (logior (boole boole-xxx a b) (boole boole-yyy a b)) No matter how boole-and is defined, (logior boole-and boole-nand) should produce 15, which should be the value of boole-set. The vector indexing trick recommended in the boole function's example should only be necessary for a program which needs the operators to have concrete values corresponding to a particular choice of truth table bit order. It should not be necessary for obtaining indexing which has the above good behavior with respect to being able to use logical operators on the truth tables in order to combine them. Indeed, the implementation from which you are reporting seems to have a broken numbering. For the boole-xor function, we need to see a value that has two zeros and two ones. If it's not one of the values 2, 5, 9, 6, 10, 12, then the numbering is broken. It is inescapable that boole-clr and boole-set must be 0 and 15.

Jtsummers 4y ago

boole-and 0 0 0 1 and boole-nand 1 1 1 0 not-and While boole-and appears in the 6th (counting from 0) position, it still has a binary representation here of 1, and boole-nand is (reasonably) its complement with 14. It seems the table has been reordered for some reason for this presentation. It seems to present 0-ary, 1-ary, 2-ary operations in that order, which doesn't correspond to the order of the binary representation.

gumby 4y ago
If I remember correctly these are the PDP-10 Boolean operator codes.
- Jtsummers 4y ago
  Yep, zachbeane's near-simultaneous comment to mine has a link with details on that.

kazinator 4y ago

The order is implementation-specific. For the values I cared to sample below, CLISP seems to have sane values that reflect the truth tables: [1]> boole-clr 0 [2]> boole-set 15 [3]> boole-and 8 [4]> boole-ior 14 [5]> boole-nand 7 Obviously, values with this property are not unique; they depend on the bit combination order. boole-and and boole-ior could plausibly be 1 and 7. IMHO, the latitude in the spec should be interpreted as accommodating this truth table ordering variation, and not as an invitation for arbitrarily enumerating the functions so that the values don't make sense as truth tables. That is to say, it should be possible to perform logical operations on the values whose interpretation is that the truth tables are combined accordingly, such that these two are equivalent: (boole (logior boole-xxx boole-yyy) a b) <--> (logior (boole boole-xxx a b) (boole boole-yyy a b)) No matter how boole-and is defined, (logior boole-and boole-nand) should produce 15, which should be the value of boole-set. The vector indexing trick recommended in the boole function's example should only be necessary for a program which needs the operators to have concrete values corresponding to a particular choice of truth table bit order. It should not be necessary for obtaining indexing which has the above good behavior with respect to being able to use logical operators on the truth tables in order to combine them. Indeed, the implementation from which you are reporting seems to have a broken numbering. For the boole-xor function, we need to see a value that has two zeros and two ones. If it's not one of the values 2, 5, 9, 6, 10, 12, then the numbering is broken. It is inescapable that boole-clr and boole-set must be 0 and 15.