> Date: Sun, 08 Dec 2002 19:10:30 +1100 > From: Damian Conway <[EMAIL PROTECTED]> > > There are actually four types of junction: > > conjunction: all(@elements) > disjunction: any(@elements) > abjunction: one(@elements) > injunction: none(@elements)
Oh yeah... > > represent the set: > > > > { 1, 2, 3 } > > > > Which we will call N. Performing some > > ....unary... Sure. Any n-ary operation can be turned to unary with currying anyway, right? > > If that was a comparison operation, say C<{ $^x > 2 }>, the resultant > > set would be: > > > > { undef, undef, 1 } > > Err, no. The result is: > > { 1 } > > Comparison of a junction returns those states for which the comparison is true. > Furthermore, the resulting junction has a truth property assigned, according to > the truth of the comparison. Furtherurthermore, the type of the rsulting junction > is the same as the type of the junctive operand. Yes, but I was trying to unify all kinds of operations. +'s junctive semantics would be no different from >'s, except for the actual function they performed. And that would work with the "truth of the comparison" thing you just said, except that 0 is false, so -2 + 2 would not be included in the junction. I guess a small distinction between comparison (or boolean, I suppose) and non-comparison is okay. > I'm not sure that any of the above semantic changes are required. All that is > needed is the define that logical operations on junctions return a junction of > the states of the leftmost junctive operand for which the operation was true. > And that the resultant junction be ascribed a C<true> or C<false> property > according to the overall truth/falsehood of the comparison. Again, under the condition that operations can be classified logical and non-logical. Ok. > No. At present, the proposal is that n arithmetic operation between > junctions produces a junction whose states are the distinct results > of the operation applied pairwise to all possible combinations of > states from each operand, and whose junctive type is the same as > the left-most operand. I can make a strong case against this behavior, at least: (2 | 3) + (5 & 6) > 8 In English: Does either 2 or 3 (or both) have the property that when you add it to _both_ 5 and 6 you achieve a result greater than 8. The answer, of course is no. However, (2 | 3) + (5 & 6) > 8 7 | 8 | 9 > 8 # True!!! Counterintuitive. Another: Same example, with operands swapped: (5 & 6) + (2 | 3) > 8 7 & 8 & 9 > 8 # False!!! Ok, not only can it provide counterintuitive results, but it makes communitive operators not commute. That's Just Not Right. And Another: one(1, 40) + any(3, 4) > 42 In English: Does either 1 or 40 (but not both) have the property that with you add it to either 3 or 4 (or both) you achieve a result greater than the answer to life, the universe, and everything :) This time, it's true. 40 has this property, but not 1. But, one(1, 40) + any(3, 4) > 42 one(4, 5, 43, 44) > 42 # False!! Again, counterintuitive > Presumably, under Luke's model: > > $C = foo($A, $B); > > would be the same as: > > $C = foo(1,4)&foo(1,5)&foo(1,6) | > foo(2,4)&foo(2,5)&foo(2,6) | > foo(3,4)&foo(3,5)&foo(3,6); Right. Since junctions distribute (they'd better, lest I go absolutely mad), that's equivalent to: $C = (foo(1,4)|foo(2,4)|foo(3,4)) & (foo(1,5)|foo(2,5)|foo(3,5)) & (foo(1,6)|foo(2,6)|foo(3,6)); And whether you come up with this or the other depends on whether you evaluate $A or $B first. Semantically, it doesn't matter either way. > The semantics Luke suggests seem to be richer, but rely on the fixed > precedence relationships between the various junctive types. I'd really > like to (see someone else) explore how that expands to include abjunctions > and injunctions, before I contemplated so fundamental a change in the > semantics. Um, what? The semantics I suggested have nothing to do with the lexical representation of junctions at all. It's a purely logical semantic. Unless I'm misunderstanding you... I'll show you an example of abjunctions. Take my example from earlier: one(1, 40) + any(3, 4) > 42 This expands to: one(any(1+3, 1+4), any(40+3, 40+4)) > 42 Which is true. If you happened to evaluate the any() first: any(one(3+1, 3+40), one(4+1, 4+40)) > 42 Again, true. For the same reason too. One thing I'd like to know is what none() means. Does it mean "anything but" or "when tested against each argument, is false". I assume the latter, for computational reasons. In which case I have Yet Another example: any(2, 3) + none(7) > 8 English: When seven is added to either 2 or 3 (or both), is the result not greater than 8? The answer: no. Under Quantum::Superpositions semantics: any(2, 3) + none(7) > 8 any(9, 10) > 8 # True! Wrong again. Under logic/nested semantics: any(2, 3) + none(7) > 8 any(none(9), none(10)) > 8 # False Explored (partially). My overall argument for the semantics I proposed would be that: when things get complex, it's better to have logically correct semantics than locally DWIMmy ones. For instance, in those nice recursive functions that were shown here (by Brent? Dan? I don't remember). The only problem that I see with them is that their structure could get very big, very fast. For junctions $a, $b, and $c with sufficiently many states: $d = $a + $b + $c; # ... and later if $d < 10 {...} Who would think that the comparison would take Θ(abc) time. The Quantum::Superpositions's time would be only O(abc). > And which null set you use will depend on what you intend to do with it. > For example, if you're accumulating "seen" values, the empty set you need > to start with depends on whether they're conjunctively or disjunctively > being "seen". That is: > > my $seen = any(); > for <> { > next when $seen; > do_something_with($_); > $seen |= $_; > } But it doesn't really matter, does it? As you have shown, nested junctions are useful. Nesting the empty set in any form with a junction of another type would be the same as just using that other type in the first place. > One might also contemplate C<none()> as the universal set. ;-) On second thought, the different empty sets might not actually be equivalent: any() < 10 # False (∃x: x ∈ ∅ ∧ ?x) all() < 10 # True (∀x: x ∈ ∅ ⇒ ?x) Oh, dear. Luke