Re: Junctive puzzles.
[EMAIL PROTECTED] wrote:
What if junctions collapsed into junctions of the valid options under
some circumstances, so
my $x = any(1,2,3,4,5,6,7);
if(is_prime($x) # $x = any(2,3,5,7)
and is_even($x) # $x = any(2)
and $x > 2) # $x = any()
This is Just Wrong, IMO. How confusing is it going to be to find that
calling is_prime($x) modifies the value of $x despite it being a very
simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for
is_prime($x), is_even($x) and $x > 2 to all be true, because an any()
junction was used. If an all() junction was used it would be quite a
different matter of course, but I would see is_prime() called on an
any() junction as returning true the moment it finds a value inside
that junction which is prime. It doesn't need to change $x at all.
In a way, you're sort of asking 'has $x got something that has the
characteristics of a prime number?' and of course, $x has - several of
them, in fact (but the count is not important).
Well, yes, unexpected side-effects are not so great, however, in this
case they're sequestered behind junctions. In fact, the other post
suggested using implicit backtracking for this (something that can have
a real problem with *expected* side-effects). If you just think of
junctions as 'Just Works', side effects are implementation detail.
To address your idea, problem is, you generally don't know whether
you've been passed a junction (short of very specific type query), and
writing code without being able to rely on the fact that (is_prime($x)
&& !!is_prime($x)) == false is Just Plain Evil. For example, something
as simple as
if (is_prime($x)) { ... }
else { ... }
may be buggy if $x is a junction. To make it work correctly, you will
want to write
if (is_prime($x)) { ... }
if (!is_prime($x)) { ... }
Evil, no? :)
Miro
Re: [rbw3@cse.nau.edu: Re: Junctive puzzles.]
[EMAIL PROTECTED] wrote: Yes... but perhaps instead of the above transform we should just make sure that < is transitive in the first place... so that no matter what if a Partial ordering relations are also transitive by definition. Of course, you can overload '<' to be something other than ordering relation, but I'd invoke PEBKAC on that. :) Miro
Re: Junctive puzzles.
Matt Fowles wrote:
This is Just Wrong, IMO. How confusing is it going to be to find that
calling is_prime($x) modifies the value of $x despite it being a very
simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for
is_prime($x), is_even($x) and $x > 2 to all be true, because an any()
junction was used. If an all() junction was used it would be quite a
different matter of course, but I would see is_prime() called on an
any() junction as returning true the moment it finds a value inside that
junction which is prime. It doesn't need to change $x at all.
In a way, you're sort of asking 'has $x got something that has the
characteristics of a prime number?' and of course, $x has - several of
them, in fact (but the count is not important).
Soemtimes, although frequently I will check for preconditions at the
begining of a function. After I finished checking for them, I expect
to be able to do stuff assuming them without anyworry of exceptions or
anything else. In these cases I am using conditionals to filter
input, which I imagine is a fairly common case...
Yes, it is fairly common, but I don't think it's common enough to attach
unexpected side-effects to innocent-seeming functions. If I want to
modify a junction to contain only values which satisfy a given
precondition, I'll be wanting to use something which states that explicitly.
Which reminds me that I'm not very aware of anything which can decompose
a junction once it's been created, which would be fairly necessary for
doing that sort of thing. If you can turn junctions into lists then
precondition filtering isn't bad at all. Something like
my $filtered = any($junction.list().grep({ satisfies_precondition }));
Of course, I just invented that out of nothing so I may be way off base.
I haven't found anything in any Apocalypse or Synopsis which says if you
can do things like this, but if Perl itself can pick junctions apart, we
should be able to as well.
My approach to this comes somewhat from my basis in liking Haskell a lot
and thus wanting to keep unusual side-effects to a minimum. However, if
junctions collapse and modify themselves as was in your example, what
happens when you don't want to have them collapse? Do you have to
explicitly make copies?
Re: Junctive puzzles.
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke
Palmer) wrote:
>Well, we see the same kind of thing with standard interval arithmetic:
>[...]
It didn't bother me that junctions weren't ordered transitively.
(Ordering had better work transitively for ordinary numbers, but
junctions aren't numbers.) Yes, the 4<(0|6)<2 thing doesn't quite
DWIM, but maybe I should just mean something else.
Except then I started thinking about why, and I decided that it
*should* DWEveryoneM. Funny things that aren't numbers can still be
ordered intransitively, but the reason that this doesn't work the way
we want is not so much because junctions are something funny, but
because < is something funny.
That is, xhttp://groups-beta.google.com/group/perl.perl6.language/browse_thread/th
read/41b18e5920ab2d78/4b24a002ab4ff9c9>
Quoting from the first message in that thread:
>If a boolean operation is applied in non-boolean context to a
>junction, it will return a junction of only the values for which the
>condition evaluated true. [...]
>
>* Junctions discard Cs on-sight (i.e. C can never be a
> member of a junction).
>* Comparison operators return C if they fail, and their
> left-hand side "C" if they succeed.
>* Comparison operators are right-associative.
Oops, my example above assumed < was left-associative and returned
its right-hand side. But doesn't flipping it around that way solve
this:
>Unfortunately, the last change clobbers the left-short-circuiting
>behavior of comparison operators.
or are there funny edge cases or something that I'm not seeing?
Anyway, the above-cited thread presents two versions of junctions and
comparative operators, and I prefer the Lucian interpretation to the
Damianian. It seems a bit more mathematical and a bit less
specially-cased; both good things in my book.
>But you can force a collapse like this:
>my $x = 4 < $j;
>if $x < 2 { say "never executed" }
Because then we're explicitly taking the result of the first
comparison and applying it to the second. Which is what 4<$j<2 ought
to mean anyway. I think Autrijus's solution for Pugs is to treat <
as list-associative (with a between[-like] function as the list op),
but I'm not sure how that works when you try to mix different
comparative operators.
If every boolean function returns the junctive elements that make it
true, then they can be chained indiscriminately:
is_even(is_prime(1|2|3|4|5))>2
means is_even(2|3|5)>2
means (2)>2
means false.
Incidentally, is there a way to decompose a junction? Something like
a .conjunctions method that returns a list of all the conjunctive
elements (if it isn't a conjunction, then it would return a single
element which is the whole thing).
$petticoat=(1 | 2 | 3 | (4&5));
$petticoat.conjunctions; # list containing (1|2|3|(4&5))
$petticoat.disjunctions; # list containing 1, 2, 3, (4&5)
($petticoat.disjunctions)[-1].conjunctions;# list 4, 5
- David "guilty by list association" Green
Re: Junctive puzzles.
All~
On Wed, 09 Feb 2005 22:48:00 +, Matthew Walton
<[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
> > All~
> >
> > On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]>
> > wrote:
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>
> Well, we see the same kind of thing with standard interval arithmetic:
>
> (-1, 1) * (-1, 1) = (-1, 1)
> (-1, 1) ** 2 = [0, 1)
>
> The reason that junctions behave this way is because they don't
> collapse. You'll note the same semantics don't arise in
> Quantum::Entanglement (when you set the "try to be true" option).
>
> But you can force a collapse like this:
>
> my $x = 4 < $j;
> if $j < 2 { say "never executed" }
>
>
> >>>
> >>>By which I mean:
> >>>
> >>> my $x = 4 < $j;
> >>> if $x < 2 { say "never executed" }
> >>>
> >>>
> >>>
> >>
> >>Uh, I'm not sure this does what I think you wanted to say it does. ;) $x
> >>is a boolean, unless < returns a magical object... in which case, the
> >>magical part of $x ought to be a reference to the original $j, no?
> >>
> >>
> I'm wonding if we should allow a method that returns a junction that is
> allowed to collapse the original:
>
> if 4 < $j.collapse and $j.collapse < 2 {
> say "never executed";
> }
>
> But that's probably not a good idea, just by looking at the
> implementation complexity of Quantum::Entanglement. People will just
> have to learn that junctions don't obey ordering laws.
>
>
> >>
> >>Well, I suspect that junctions will have to be references and just
> >>collapse every time. Observe:
> >>
> >>my $x = any(1, 2, 3, 4, 5);
> >>print "SHOULD NOT RUN" if (is_prime($x) && is_even($x) && $x > 2);
> >>
> >>This only works if $x collapses. Same for matching junctioned strings:
> >>
> >>my $a = any ();
> >>print "Boo!" if $a ~ /a/ and $a ~ /b/ and $a ~ /c/;
> >>
> >>(perhaps I meant to use ~~, I don't quite remember :) )
> >>
> >>Either way, autocollapsing juntions is a Good Thing IMHO, and the only
> >>remaining confusion (to go back to my initial post) is that the only
> >>case that doesn't work is when you instance a junction twice as a pair
> >>of same literals:
> >>
> >>print "SUCCESS, unfortunately" if (is_prime(any(1, 2, 3, 4, 5)) &&
> >>is_even(any(1, 2, 3, 4, 5)) && any(1, 2, 3, 4, 5) > 2);
> >>
> >>Hope I'm making sense. Been a hard day at work. ;)
> >
> >
> > What if junctions collapsed into junctions of the valid options under
> > some circumstances, so
> >
> > my $x = any(1,2,3,4,5,6,7);
> > if(is_prime($x) # $x = any(2,3,5,7)
> > and is_even($x) # $x = any(2)
> > and $x > 2) # $x = any()
>
> This is Just Wrong, IMO. How confusing is it going to be to find that
> calling is_prime($x) modifies the value of $x despite it being a very
> simple test operation which appears to have no side effects?
>
> As far as I can see it, in the example, it's perfectly logical for
> is_prime($x), is_even($x) and $x > 2 to all be true, because an any()
> junction was used. If an all() junction was used it would be quite a
> different matter of course, but I would see is_prime() called on an
> any() junction as returning true the moment it finds a value inside that
> junction which is prime. It doesn't need to change $x at all.
>
> In a way, you're sort of asking 'has $x got something that has the
> characteristics of a prime number?' and of course, $x has - several of
> them, in fact (but the count is not important).
Soemtimes, although frequently I will check for preconditions at the
begining of a function. After I finished checking for them, I expect
to be able to do stuff assuming them without anyworry of exceptions or
anything else. In these cases I am using conditionals to filter
input, which I imagine is a fairly common case...
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Re: Junctive puzzles.
Matt Fowles wrote:
All~
On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
Well, we see the same kind of thing with standard interval arithmetic:
(-1, 1) * (-1, 1) = (-1, 1)
(-1, 1) ** 2 = [0, 1)
The reason that junctions behave this way is because they don't
collapse. You'll note the same semantics don't arise in
Quantum::Entanglement (when you set the "try to be true" option).
But you can force a collapse like this:
my $x = 4 < $j;
if $j < 2 { say "never executed" }
By which I mean:
my $x = 4 < $j;
if $x < 2 { say "never executed" }
Uh, I'm not sure this does what I think you wanted to say it does. ;) $x
is a boolean, unless < returns a magical object... in which case, the
magical part of $x ought to be a reference to the original $j, no?
I'm wonding if we should allow a method that returns a junction that is
allowed to collapse the original:
if 4 < $j.collapse and $j.collapse < 2 {
say "never executed";
}
But that's probably not a good idea, just by looking at the
implementation complexity of Quantum::Entanglement. People will just
have to learn that junctions don't obey ordering laws.
Well, I suspect that junctions will have to be references and just
collapse every time. Observe:
my $x = any(1, 2, 3, 4, 5);
print "SHOULD NOT RUN" if (is_prime($x) && is_even($x) && $x > 2);
This only works if $x collapses. Same for matching junctioned strings:
my $a = any ();
print "Boo!" if $a ~ /a/ and $a ~ /b/ and $a ~ /c/;
(perhaps I meant to use ~~, I don't quite remember :) )
Either way, autocollapsing juntions is a Good Thing IMHO, and the only
remaining confusion (to go back to my initial post) is that the only
case that doesn't work is when you instance a junction twice as a pair
of same literals:
print "SUCCESS, unfortunately" if (is_prime(any(1, 2, 3, 4, 5)) &&
is_even(any(1, 2, 3, 4, 5)) && any(1, 2, 3, 4, 5) > 2);
Hope I'm making sense. Been a hard day at work. ;)
What if junctions collapsed into junctions of the valid options under
some circumstances, so
my $x = any(1,2,3,4,5,6,7);
if(is_prime($x) # $x = any(2,3,5,7)
and is_even($x) # $x = any(2)
and $x > 2) # $x = any()
This is Just Wrong, IMO. How confusing is it going to be to find that
calling is_prime($x) modifies the value of $x despite it being a very
simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for
is_prime($x), is_even($x) and $x > 2 to all be true, because an any()
junction was used. If an all() junction was used it would be quite a
different matter of course, but I would see is_prime() called on an
any() junction as returning true the moment it finds a value inside that
junction which is prime. It doesn't need to change $x at all.
In a way, you're sort of asking 'has $x got something that has the
characteristics of a prime number?' and of course, $x has - several of
them, in fact (but the count is not important).
Re: [rbw3@cse.nau.edu: Re: Junctive puzzles.]
On 2005.02.08.19.07, Matt Fowles wrote: | Brock~ | | | On Tue, 8 Feb 2005 12:08:45 -0700, Brock <[EMAIL PROTECTED]> wrote: | > | > Hm. I take that back... it was a silly comment to make and not very | > mathematically sound. Sorry. | > | > --Brock | > | > - Forwarded message from Brock <[EMAIL PROTECTED]> - | > | > (a < b < c) ==> (a < b) and (b < c) and (a < c) | > | | I disagree, I think that that is both mathematically sounds and | perfectly logical. Yes... but perhaps instead of the above transform we should just make sure that < is transitive in the first place... so that no matter what if a
Re: [rbw3@cse.nau.edu: Re: Junctive puzzles.]
Brock~ On Tue, 8 Feb 2005 12:08:45 -0700, Brock <[EMAIL PROTECTED]> wrote: > > Hm. I take that back... it was a silly comment to make and not very > mathematically sound. Sorry. > > --Brock > > - Forwarded message from Brock <[EMAIL PROTECTED]> - > > (a < b < c) ==> (a < b) and (b < c) and (a < c) > I disagree, I think that that is both mathematically sounds and perfectly logical. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
[rbw3@cse.nau.edu: Re: Junctive puzzles.]
Hm. I take that back... it was a silly comment to make and not very mathematically sound. Sorry. --Brock - Forwarded message from Brock <[EMAIL PROTECTED]> - Date: Tue, 8 Feb 2005 12:06:58 -0700 From: Brock <[EMAIL PROTECTED]> To: Autrijus Tang <[EMAIL PROTECTED]> Cc: perl6-language@perl.org Subject: Re: Junctive puzzles. User-Agent: Mutt/1.5.6+20040907i On 2005.02.05.20.33, Autrijus Tang wrote: | (I've just finished the pretty printing part in Pugs, so I'll use actual | command line transcripts below. The leading "?" does not denote boolean | context -- it's just telling pugs to do a big-step evaluation. Also, | boolean literals are written in their Scheme forms.) | | In S06, the meaning of chaining comparison operators is defined as a | derived form: | | (a < b < c) ==> (a < b) and (b < c) unrelated to the overall topic, shouldn't this be (a < b < c) ==> (a < b) and (b < c) and (a < c) anyway? Sorry if I missed this discussed previously. --Brock - End forwarded message -
Re: Junctive puzzles.
On 2005.02.05.20.33, Autrijus Tang wrote: | (I've just finished the pretty printing part in Pugs, so I'll use actual | command line transcripts below. The leading "?" does not denote boolean | context -- it's just telling pugs to do a big-step evaluation. Also, | boolean literals are written in their Scheme forms.) | | In S06, the meaning of chaining comparison operators is defined as a | derived form: | | (a < b < c) ==> (a < b) and (b < c) unrelated to the overall topic, shouldn't this be (a < b < c) ==> (a < b) and (b < c) and (a < c) anyway? Sorry if I missed this discussed previously. --Brock
Re: Junctive puzzles.
All~
On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> >>Well, we see the same kind of thing with standard interval arithmetic:
> >>
> >>(-1, 1) * (-1, 1) = (-1, 1)
> >>(-1, 1) ** 2 = [0, 1)
> >>
> >>The reason that junctions behave this way is because they don't
> >>collapse. You'll note the same semantics don't arise in
> >>Quantum::Entanglement (when you set the "try to be true" option).
> >>
> >>But you can force a collapse like this:
> >>
> >>my $x = 4 < $j;
> >>if $j < 2 { say "never executed" }
> >>
> >>
> >
> >By which I mean:
> >
> >my $x = 4 < $j;
> >if $x < 2 { say "never executed" }
> >
> >
> >
> Uh, I'm not sure this does what I think you wanted to say it does. ;) $x
> is a boolean, unless < returns a magical object... in which case, the
> magical part of $x ought to be a reference to the original $j, no?
>
> >>I'm wonding if we should allow a method that returns a junction that is
> >>allowed to collapse the original:
> >>
> >>if 4 < $j.collapse and $j.collapse < 2 {
> >>say "never executed";
> >>}
> >>
> >>But that's probably not a good idea, just by looking at the
> >>implementation complexity of Quantum::Entanglement. People will just
> >>have to learn that junctions don't obey ordering laws.
> >>
> >>
> Well, I suspect that junctions will have to be references and just
> collapse every time. Observe:
>
> my $x = any(1, 2, 3, 4, 5);
> print "SHOULD NOT RUN" if (is_prime($x) && is_even($x) && $x > 2);
>
> This only works if $x collapses. Same for matching junctioned strings:
>
> my $a = any ();
> print "Boo!" if $a ~ /a/ and $a ~ /b/ and $a ~ /c/;
>
> (perhaps I meant to use ~~, I don't quite remember :) )
>
> Either way, autocollapsing juntions is a Good Thing IMHO, and the only
> remaining confusion (to go back to my initial post) is that the only
> case that doesn't work is when you instance a junction twice as a pair
> of same literals:
>
> print "SUCCESS, unfortunately" if (is_prime(any(1, 2, 3, 4, 5)) &&
> is_even(any(1, 2, 3, 4, 5)) && any(1, 2, 3, 4, 5) > 2);
>
> Hope I'm making sense. Been a hard day at work. ;)
What if junctions collapsed into junctions of the valid options under
some circumstances, so
my $x = any(1,2,3,4,5,6,7);
if(is_prime($x) # $x = any(2,3,5,7)
and is_even($x) # $x = any(2)
and $x > 2) # $x = any()
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
Re: Junctive puzzles.
[EMAIL PROTECTED] wrote:
Well, we see the same kind of thing with standard interval arithmetic:
(-1, 1) * (-1, 1) = (-1, 1)
(-1, 1) ** 2 = [0, 1)
The reason that junctions behave this way is because they don't
collapse. You'll note the same semantics don't arise in
Quantum::Entanglement (when you set the "try to be true" option).
But you can force a collapse like this:
my $x = 4 < $j;
if $j < 2 { say "never executed" }
By which I mean:
my $x = 4 < $j;
if $x < 2 { say "never executed" }
Uh, I'm not sure this does what I think you wanted to say it does. ;) $x
is a boolean, unless < returns a magical object... in which case, the
magical part of $x ought to be a reference to the original $j, no?
I'm wonding if we should allow a method that returns a junction that is
allowed to collapse the original:
if 4 < $j.collapse and $j.collapse < 2 {
say "never executed";
}
But that's probably not a good idea, just by looking at the
implementation complexity of Quantum::Entanglement. People will just
have to learn that junctions don't obey ordering laws.
Well, I suspect that junctions will have to be references and just
collapse every time. Observe:
my $x = any(1, 2, 3, 4, 5);
print "SHOULD NOT RUN" if (is_prime($x) && is_even($x) && $x > 2);
This only works if $x collapses. Same for matching junctioned strings:
my $a = any ();
print "Boo!" if $a ~ /a/ and $a ~ /b/ and $a ~ /c/;
(perhaps I meant to use ~~, I don't quite remember :) )
Either way, autocollapsing juntions is a Good Thing IMHO, and the only
remaining confusion (to go back to my initial post) is that the only
case that doesn't work is when you instance a junction twice as a pair
of same literals:
print "SUCCESS, unfortunately" if (is_prime(any(1, 2, 3, 4, 5)) &&
is_even(any(1, 2, 3, 4, 5)) && any(1, 2, 3, 4, 5) > 2);
Hope I'm making sense. Been a hard day at work. ;)
Miro
Re: Junctive puzzles.
Luke Palmer writes:
> Miroslav Silovic writes:
> > [EMAIL PROTECTED] wrote:
> > >So Pugs will evaluate that to (#f|#f), by lifting all junctions
> > >out of a multiway comparison, and treat the comparison itself as
> > >a single variadic operator that is evaluated as a chain individually.
> >
> > I think this is correct, however... this is not what I meat in my
> > comment. Note I didn't use chained comparison anywhere.
> >
> > What I meant is that for any form with two parameters (in the example,
> > 4 < ___ and ___ < 2), aparently it's not the same whether the two
> > parameters refer to the same junction or to two equal (but distinct)
> > junctions.
>
> Well, we see the same kind of thing with standard interval arithmetic:
>
> (-1, 1) * (-1, 1) = (-1, 1)
> (-1, 1) ** 2 = [0, 1)
>
> The reason that junctions behave this way is because they don't
> collapse. You'll note the same semantics don't arise in
> Quantum::Entanglement (when you set the "try to be true" option).
>
> But you can force a collapse like this:
>
> my $x = 4 < $j;
> if $j < 2 { say "never executed" }
By which I mean:
my $x = 4 < $j;
if $x < 2 { say "never executed" }
Luke
> I'm wonding if we should allow a method that returns a junction that is
> allowed to collapse the original:
>
> if 4 < $j.collapse and $j.collapse < 2 {
> say "never executed";
> }
>
> But that's probably not a good idea, just by looking at the
> implementation complexity of Quantum::Entanglement. People will just
> have to learn that junctions don't obey ordering laws.
>
> Luke
>
Re: Junctive puzzles.
Miroslav Silovic writes:
> [EMAIL PROTECTED] wrote:
> >So Pugs will evaluate that to (#f|#f), by lifting all junctions
> >out of a multiway comparison, and treat the comparison itself as
> >a single variadic operator that is evaluated as a chain individually.
>
> I think this is correct, however... this is not what I meat in my
> comment. Note I didn't use chained comparison anywhere.
>
> What I meant is that for any form with two parameters (in the example,
> 4 < ___ and ___ < 2), aparently it's not the same whether the two
> parameters refer to the same junction or to two equal (but distinct)
> junctions.
Well, we see the same kind of thing with standard interval arithmetic:
(-1, 1) * (-1, 1) = (-1, 1)
(-1, 1) ** 2 = [0, 1)
The reason that junctions behave this way is because they don't
collapse. You'll note the same semantics don't arise in
Quantum::Entanglement (when you set the "try to be true" option).
But you can force a collapse like this:
my $x = 4 < $j;
if $j < 2 { say "never executed" }
I'm wonding if we should allow a method that returns a junction that is
allowed to collapse the original:
if 4 < $j.collapse and $j.collapse < 2 {
say "never executed";
}
But that's probably not a good idea, just by looking at the
implementation complexity of Quantum::Entanglement. People will just
have to learn that junctions don't obey ordering laws.
Luke
Re: Junctive puzzles.
[EMAIL PROTECTED] wrote: Yup. My mathematic intuition cannot suffer that: 4 < X < 2 to be true in any circumstances -- as it violates associativity. If one wants to violate associativity, one should presumably *not* use the chained comparison notation! So Pugs will evaluate that to (#f|#f), by lifting all junctions out of a multiway comparison, and treat the comparison itself as a single variadic operator that is evaluated as a chain individually. I think this is correct, however... this is not what I meat in my comment. Note I didn't use chained comparison anywhere. What I meant is that for any form with two parameters (in the example, 4 < ___ and ___ < 2), aparently it's not the same whether the two parameters refer to the same junction or to two equal (but distinct) junctions. Miro
Re: Junctive puzzles.
On Tue, Feb 08, 2005 at 11:12:40AM +0800, Autrijus Tang wrote: : This way, both associativity and junctive dimensionality holds, so : I think it's the way to go. Please correct me if you see serious : flaws with this approach. Feels right to me. Larry
Re: Junctive puzzles.
On Tue, 8 Feb 2005 11:12:40 +0800, Autrijus Tang <[EMAIL PROTECTED]> wrote: > On Mon, Feb 07, 2005 at 05:33:06PM +0100, Miroslav Silovic wrote: > > my $a = (0 | 6); > > say 4 < $a and $a < 2; > > Yup. My mathematic intuition cannot suffer that: > > 4 < X < 2 > > to be true in any circumstances -- as it violates associativity. > If one wants to violate associativity, one should presumably *not* > use the chained comparison notation! Indeed. It smells like "relational" algebra, so we can confirm this intuition with a rather familiar example: select * from $a cross join $b cross join $c where a < b and b < c Looks right to me! I look forward to the SQL query construction modules in Perl6. :) Ashley
Re: Junctive puzzles.
On Mon, Feb 07, 2005 at 05:33:06PM +0100, Miroslav Silovic wrote: > my $a = (0 | 6); > say 4 < $a and $a < 2; Yup. My mathematic intuition cannot suffer that: 4 < X < 2 to be true in any circumstances -- as it violates associativity. If one wants to violate associativity, one should presumably *not* use the chained comparison notation! So Pugs will evaluate that to (#f|#f), by lifting all junctions out of a multiway comparison, and treat the comparison itself as a single variadic operator that is evaluated as a chain individually. This way, both associativity and junctive dimensionality holds, so I think it's the way to go. Please correct me if you see serious flaws with this approach. Thanks, /Autrijus/ pgp2YqC1IJS0m.pgp Description: PGP signature
Re: Junctive puzzles.
[EMAIL PROTECTED] wrote: pugs> ? 4 < (0 | 6) < 2 (#t|#f) Here's my take on it. Compare my $a = (0 | 6); say 4 < $a and $a < 2; vs say 4 < (0 | 6) and (0 | 6) < 2; The difference is that in the first case the junction refers to the same object, and the result should probably be expanded only once: (4 < 0 and 0 < 2) | (4 < 6 and 6 < 2) while in the second case, we have two different junctions, and each gets threaded separately: (4 < 0 and 0 < 2) | (4 < 6 and 6 < 2) | (4 < 0 and 6 < 2) | (4 < 6 and 0 < 2) The first expansion gives the correct result, while the other is really a variant on what you have. And I believe this becomes highly dangerous if you start assigning junctions around. :) Miro
Re: Junctive puzzles.
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes: NC> If junctions are sets, and so a|b is identical to b|a, then isn't NC> it wrong for any implementation of junctions to use any NC> short-circuiting logic in its implementation, because if it did, NC> then any active data (such as tied things will side effects) may NC> or may not get called depending on whether a junction happened to NC> be stored internally with a first, or with b first? NC> (unless the implementation can prove to itself that nothing it's NC> dealing with has side effects, so short circuiting will have no NC> effect. Of course, this is an implementation detail, and aside NC> from speed, must not be determinable from outside) it also depends on the junction function :). i would think one() would need to check all the elements. but i agree with you about a junction being an unordered set. you have to treat it that way to make sense since you can add elements to a junction (can someone clue us in with a code example?). on the other hand we expect 'and' and friends to short circuit and execute from left to right and that is taken advantage of in many ways. so i say 'a or b' is not semantically the same as 'a | b' in that there is no guarantee of order in junctions. but there is no guarantee of evaluating all of the elements in a junction, it can short curcuit as soon as it can determine a correct boolean result (assuming a boolean result is wanted). uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Junctive puzzles.
On Sat, Feb 05, 2005 at 06:35:55PM +, Nicholas Clark wrote: > If junctions are sets, and so a|b is identical to b|a, then isn't it wrong > for any implementation of junctions to use any short-circuiting logic in > its implementation, because if it did, then any active data (such as tied > things will side effects) may or may not get called depending on whether a > junction happened to be stored internally with a first, or with b first? It was short-circuiting the "and", collapsing the left hand side junction into a boolean to determine whether to evaluate the right hand side comparison. It is not short-circuiting over individual values. So I agree. All evaluations to sets needs to be done fully. Thanks, /Autrijus/ pgpkA1EAm1PeL.pgp Description: PGP signature
Re: Junctive puzzles.
On Sun, Feb 06, 2005 at 02:30:21AM +0800, Autrijus Tang wrote: > On Sat, Feb 05, 2005 at 02:39:26PM +, Nicholas Clark wrote: > > On Sat, Feb 05, 2005 at 10:04:02PM +0800, Autrijus Tang wrote: > > > On Sat, Feb 05, 2005 at 01:52:05PM +, Nicholas Clark wrote: > > > > > #t and (0 | 6) < 2 # reduction in boolean > > > > > context(!) > > > > > > > > Why is it allowed to do this? > > > > > > Because "and" forces boolean context to determine whether it > > > short-circuits or not. However, I should've make it clear that > > > if the left hand side evaluates to #f, it will return the junction > > > itself, not #f. This is true in both spec and pugs implementation. > > > > (Without understanding the background to the implementation of junctions) > > why are you using a short-circuiting "and"? > > Well, because perl5's "and" is short-circuiting, and I assume perl6's > "and" is no exception... > > > Surely if you take an expression that contains the junction (a|b) and > > convert that to ... a ... and ... b ... then you are implying an order to > > the elements of a junction? I didn't think that junctions had order - I > > thought that they were sets. > > Sure. The question is whether the junctions should autothread over the > whole comparison chain (globally), or only to a specific binary > comparison (locally). OK. So the question I'm asking, which I think is orthogonal to yours, is If junctions are sets, and so a|b is identical to b|a, then isn't it wrong for any implementation of junctions to use any short-circuiting logic in its implementation, because if it did, then any active data (such as tied things will side effects) may or may not get called depending on whether a junction happened to be stored internally with a first, or with b first? (unless the implementation can prove to itself that nothing it's dealing with has side effects, so short circuiting will have no effect. Of course, this is an implementation detail, and aside from speed, must not be determinable from outside) Nicholas Clark
Re: Junctive puzzles.
On Sat, Feb 05, 2005 at 02:39:26PM +, Nicholas Clark wrote: > On Sat, Feb 05, 2005 at 10:04:02PM +0800, Autrijus Tang wrote: > > On Sat, Feb 05, 2005 at 01:52:05PM +, Nicholas Clark wrote: > > > > #t and (0 | 6) < 2 # reduction in boolean > > > > context(!) > > > > > > Why is it allowed to do this? > > > > Because "and" forces boolean context to determine whether it > > short-circuits or not. However, I should've make it clear that > > if the left hand side evaluates to #f, it will return the junction > > itself, not #f. This is true in both spec and pugs implementation. > > (Without understanding the background to the implementation of junctions) > why are you using a short-circuiting "and"? Well, because perl5's "and" is short-circuiting, and I assume perl6's "and" is no exception... > Surely if you take an expression that contains the junction (a|b) and > convert that to ... a ... and ... b ... then you are implying an order to > the elements of a junction? I didn't think that junctions had order - I > thought that they were sets. Sure. The question is whether the junctions should autothread over the whole comparison chain (globally), or only to a specific binary comparison (locally). Thanks, /Autrijus/ pgpjPGowxePCS.pgp Description: PGP signature
Re: Junctive puzzles.
On Sat, Feb 05, 2005 at 10:04:02PM +0800, Autrijus Tang wrote: > On Sat, Feb 05, 2005 at 01:52:05PM +, Nicholas Clark wrote: > > > #t and (0 | 6) < 2 # reduction in boolean context(!) > > > > Why is it allowed to do this? > > Because "and" forces boolean context to determine whether it > short-circuits or not. However, I should've make it clear that > if the left hand side evaluates to #f, it will return the junction > itself, not #f. This is true in both spec and pugs implementation. (Without understanding the background to the implementation of junctions) why are you using a short-circuiting "and"? Surely if you take an expression that contains the junction (a|b) and convert that to ... a ... and ... b ... then you are implying an order to the elements of a junction? I didn't think that junctions had order - I thought that they were sets. Nicholas Clark
Re: Junctive puzzles.
On Sat, Feb 05, 2005 at 08:43:10PM +0800, Autrijus Tang wrote: > On Sat, Feb 05, 2005 at 12:38:57PM +, Nicholas Clark wrote: > > Surely you can do better than that for counterintuitive? :-) > > > > 4 < (0 | 6) < 2 > > pugs> ? 4 < (0 | 6) < 2 > (#t|#f) > > Why is it so? Because: > > 4 < (0 | 6) and (0 | 6) < 2 > (4 < 0 | 4 < 6) and (0 | 6) < 2 # local autothreading > (#f | #t) and (0 | 6) < 2 # evaluation > #t and (0 | 6) < 2 # reduction in boolean context(!) Why is it allowed to do this? > (0 | 6) < 2 # short circuitry > (0 < 2 | 6 < 2) # local autothreading > (#t | #f) # evaluation > > Sick, eh? Yes, indeed. This example would work just as well if the local autothreading were done first on the right and side of the "and". Is there an example where this is not the case? I can't think of one. Nicholas Clark
Re: Junctive puzzles.
On Sat, Feb 05, 2005 at 01:52:05PM +, Nicholas Clark wrote: > > #t and (0 | 6) < 2 # reduction in boolean context(!) > > Why is it allowed to do this? Because "and" forces boolean context to determine whether it short-circuits or not. However, I should've make it clear that if the left hand side evaluates to #f, it will return the junction itself, not #f. This is true in both spec and pugs implementation. Thanks, /Autrijus/ pgpGt6mI3i4SY.pgp Description: PGP signature
Re: Junctive puzzles.
On Sat, Feb 05, 2005 at 12:38:57PM +, Nicholas Clark wrote: > Surely you can do better than that for counterintuitive? :-) > > 4 < (0 | 6) < 2 pugs> ? 4 < (0 | 6) < 2 (#t|#f) Why is it so? Because: 4 < (0 | 6) and (0 | 6) < 2 (4 < 0 | 4 < 6) and (0 | 6) < 2 # local autothreading (#f | #t) and (0 | 6) < 2 # evaluation #t and (0 | 6) < 2 # reduction in boolean context(!) (0 | 6) < 2 # short circuitry (0 < 2 | 6 < 2) # local autothreading (#t | #f) # evaluation Sick, eh? Thanks, /Autrijus/ pgp5MAviWjsuy.pgp Description: PGP signature
Re: Junctive puzzles.
On Sat, Feb 05, 2005 at 08:33:25PM +0800, Autrijus Tang wrote: > With the note that "b" must be evaluated at most once. However, if > taken literally, it gives this rather weird result: > > pugs> ? 2 < (0 | 3) < 4 > (#t|#t) Surely you can do better than that for counterintuitive? :-) 4 < (0 | 6) < 2 > My intuition is that it should be equivalent to this: > > pugs> ? (2 < 0 < 4) | (2 < 3 < 4) > (#f|#t) Which I think would change (#t|#t) to (#f|#f) in my example. Nicholas Clark
