Junctions & Set Theory
Derek Ross
Do junctions have a direct representation as predicate logic statements?
In particular, do the following logic statements correspond directly
to the following perl6 junctions:
LOGIC PERL6 JUNCTION (DESCRIP)
===== ========================
(forall x)(x is true) all (conjunction)
(exists x)(x is true) any (disjunction)
(forall x)(x is false) none (injunction)
(exists x)(x is false) one (abjunction)
I don't have a really clear understanding of junctions (which is why I'm
posting this message, to try to clarify junctions in relation to a topic
I'm more familiar with), but it seems that the fourth type of junction,
"one" is inconsistent with the logic definition.
Maybe "one" should be named "one_isnt", or the logic statement should
become (exists a single x)(x is true). Either way, maybe another
junction is needed!
Derek Ross.
Abhijit A. Mahabal
> Do junctions have a direct representation as predicate logic statements?
> In particular, do the following logic statements correspond directly
> to the following perl6 junctions:
>
> LOGIC PERL6 JUNCTION (DESCRIP)
> ===== ========================
> (exists x)(x is false) one (abjunction)
>
> I'm more familiar with), but it seems that the fourth type of junction,
> "one" is inconsistent with the logic definition.
>
> Maybe "one" should be named "one_isnt", or the logic statement should
> become (exists a single x)(x is true). Either way, maybe another
> junction is needed!
The logic statement should become (exists a unique x) (x is true). This is
typically written (exists!)(x is true).
No other junction should be necessary:
If you want to say that something is *false* for at least one of the
values, you can just rephrase that as not (true for all values).
On the other hand, if you wanted to say "true for all except exactly one
value, I can't think of a way. (but then, nor of a reason for wanting to).
> Derek Ross.
Abhi.
Luke Palmer
>
> Do junctions have a direct representation as predicate logic statements?
Yes. Damian and I have already worked them out in a link I have
already posted today:
> In particular, do the following logic statements correspond directly
> to the following perl6 junctions:
>
> LOGIC PERL6 JUNCTION (DESCRIP)
> ===== ========================
> (forall x)(x is true) all (conjunction)
> (exists x)(x is true) any (disjunction)
> (forall x)(x is false) none (injunction)
> (exists x)(x is false) one (abjunction)
>
> I don't have a really clear understanding of junctions (which is why I'm
> posting this message, to try to clarify junctions in relation to a topic
> I'm more familiar with), but it seems that the fourth type of junction,
> "one" is inconsistent with the logic definition.
>
> Maybe "one" should be named "one_isnt", or the logic statement should
> become (exists a single x)(x is true).
Yeah, the latter. The thing about one_isnt is that it is exactly the
same as all() except for its behavior when given no arguments. I
don't see that as particularly useful...
> Either way, maybe another junction is needed!
Don't think so.
I think it's important to make it easy to add new junctive types,
however. So perhaps Junction is an abstract class which requires the
definition of the two methods prefix:? () and states(). Then, to make
one_isnt:
class Indisjunction is Junction {
method prefix:? () {
? grep { !$_ } self.args
}
method states () {
die "Not smart enough to write this one"
}
}
sub one_isnt(*@args) {
new Nondisjunction: @args
}
Luke
>
> Derek Ross.
Jonadab The Unsightly One
> On the other hand, if you wanted to say "true for all except exactly
> one value, I can't think of a way.
Easy. The following two statements are equivalent:
F(x) is true for all but exactly one x
(not F(x)) is true for exactly one x
The only additional possibility that can't be phrased in terms of the
four given is the complex generalised case:
F(x) is true for at least n but not more than m values of x
So for example you could have a list of fifty values for x and test
whether the condition is true for at least ten but not more than
fourty of them. (Or, x could be the condition; you could have a list
of fifty conditions and test whether between twenty and thirty of them
were true.) My guess is, however, that the frequency with which
anyone would use such a capability would not be overwhelming.
It would be great for obfuscation, though, particularly if some of the
conditions had side effects with an impact on the value of the other
conditions to be tested... That would be sufficiently interesting
that it's almost a shame I can't think of a real reason to request
such a feature, since I rather doubt anyone's going to much fancy
implementing it just for obfuscatory value ;-)
--
$;=sub{$/};@;=map{my($a,$b)=($_,$;);$;=sub{$a.$b->()}}
split//,"ten.thgirb\@badanoj$/ --";$\=$ ;-> ();print$/
Luke Palmer
Jonadab the Unsightly One writes:
> "Abhijit A. Mahabal" <amah...@cs.indiana.edu> writes:
>
> > On the other hand, if you wanted to say "true for all except exactly
> > one value, I can't think of a way.
>
> Easy. The following two statements are equivalent:
>
> F(x) is true for all but exactly one x
> (not F(x)) is true for exactly one x
>
> The only additional possibility that can't be phrased in terms of the
> four given is the complex generalised case:
>
> F(x) is true for at least n but not more than m values of x
Oh, I wouldn't say that....
use HypotheticalModules::List::Combinations 束combinations損;
sub between($low, $high, *@values) {
any(
$low..$high ==> map -> $num {
any( map { all(@$_) } combinations($num, @values) )
}
)
}
Efficient? No. Blows out memory for (20, 30, 1..50)? Yes.
Works? Yes.
We also have:
class Betwunction is Junction {
submethod BUILD($.low, $.high, @.values) { }
method evaluate() {
my Int $n = grep { ? $_ } @.values;
$.low <= $n <= $.high;
}
}
sub between($low, $high, @values) {
new Betwunction: $low, $high, @values;
}
Or something. But I guess this one breaks the constraint of "in terms
of the four given".
> So for example you could have a list of fifty values for x and test
> whether the condition is true for at least ten but not more than
> fourty of them. (Or, x could be the condition; you could have a list
> of fifty conditions and test whether between twenty and thirty of them
> were true.) My guess is, however, that the frequency with which
> anyone would use such a capability would not be overwhelming.
>
> It would be great for obfuscation, though, particularly if some of the
> conditions had side effects with an impact on the value of the other
> conditions to be tested... That would be sufficiently interesting
> that it's almost a shame I can't think of a real reason to request
> such a feature, since I rather doubt anyone's going to much fancy
> implementing it just for obfuscatory value ;-)
Who needs reasons?
Luke
Benjamin Goldberg
>
> Wow, what an old thread...
>
> Jonadab the Unsightly One writes:
> > "Abhijit A. Mahabal" <amah...@cs.indiana.edu> writes:
> >
> > > On the other hand, if you wanted to say "true for all except exactly
> > > one value, I can't think of a way.
> >
> > Easy. The following two statements are equivalent:
> >
> > F(x) is true for all but exactly one x
> > (not F(x)) is true for exactly one x
> >
> > The only additional possibility that can't be phrased in terms of the
> > four given is the complex generalised case:
> >
> > F(x) is true for at least n but not more than m values of x
>
> Oh, I wouldn't say that....
>
>
> sub between($low, $high, *@values) {
> any(
> $low..$high ==> map -> $num {
> any( map { all(@$_) } combinations($num, @values) )
> }
> )
> }
>
> Efficient? No. Blows out memory for (20, 30, 1..50)? Yes.
> Works? Yes.
>
> We also have:
>
> class Betwunction is Junction {
> submethod BUILD($.low, $.high, @.values) { }
>
> method evaluate() {
> my Int $n = grep { ? $_ } @.values;
> $.low <= $n <= $.high;
> }
> }
> sub between($low, $high, @values) {
> new Betwunction: $low, $high, @values;
> }
>
> Or something. But I guess this one breaks the constraint of "in terms
> of the four given".
Also, it tests more values for truth than it has to.
If there are fewer elements in the array than $.low, then obviously, we
should fail immediately. Actually I should say, "elements remaining",
instead of just "elements", and should say "$.low - the number of true
elements so far" instead of "$.low". In otherwords, this bit of short-
circuiting could be done on every iteration, so as to test fewer
elements of the array for truth, if we can.
If there are fewer elements in the array than $.high, then (assuming we
already know that there are at least $.low elements) we can succeed
immediately. Likewise, this short-circuiting can be done on every
iteration.
method evaluate() {
my Iterator $i = Iterator.new($.values);
my Int $need = $.low;
while( $need > 0 ) {
return false if $i < $need;
--$need if ? $i.shift;
}
my Int $limit = $.high - $.low;
while( $limit >= 0 ) {
return true if $i < $limit;
--$limit if ? $i.shift;
}
return false;
}
This *should* do no more boolean tests on the elements of $.values than
absolutely necessary.
> > So for example you could have a list of fifty values for x and test
> > whether the condition is true for at least ten but not more than
> > fourty of them. (Or, x could be the condition; you could have a list
> > of fifty conditions and test whether between twenty and thirty of them
> > were true.) My guess is, however, that the frequency with which
> > anyone would use such a capability would not be overwhelming.
> >
> > It would be great for obfuscation, though, particularly if some of the
> > conditions had side effects with an impact on the value of the other
> > conditions to be tested... That would be sufficiently interesting
> > that it's almost a shame I can't think of a real reason to request
> > such a feature, since I rather doubt anyone's going to much fancy
> > implementing it just for obfuscatory value ;-)
>
> Who needs reasons?
It's at least as useful as the proposed "fortytwo" op for parrot. :)
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}