Re: Fwd: Junctive puzzles.
On Thu, Feb 10, 2005 at 12:02:01PM -0600, Rod Adams wrote: Patrick R. Michaud wrote: Even if you fixed the =/and precedence with parens, to read my $x = (any(2,3,4,5) and any(4,5,6,7)); then I think the result is still that $x contains any(4,5,6,7). Funny. I thought $x would contain 'true' here, since Cand was a boolean operator. But I could be very wrong. The boolean form of Cand is C? . Cand is the low-precedence version of C. Pm
Re: Fwd: Junctive puzzles.
On Thu, Feb 10, 2005 at 12:02:01PM -0600, Rod Adams wrote: [...] If this is the case, then this entire discussion collapses into how to best convert arrays into junctions and junctions into arrays. Perl's existing abilities to edit arrays should be more than sufficient for editing junctions. Converting an array into a junction is easy, use Cany or Call: $x = any(@array); $y = all(@array); Perl 6 and Parrot Essentials says to convert that to convert a junction into a flat array, use the C.values method. (I didn't find an equivalent statement in the synopses/apocalypses/exigeses.) Pm
Fwd: Fwd: Junctive puzzles.
Going to get the hang of this sending to a list thing soon. -- Forwarded message -- From: Thomas Yandell [EMAIL PROTECTED] Date: Fri, 11 Feb 2005 09:40:03 + Subject: Re: Fwd: Junctive puzzles. To: Patrick R. Michaud [EMAIL PROTECTED] If only I could just do something like: perl6 -MData::Dumper -e 'print Dumper(any(2,3,4,5) any(4,5,6,7))' ...then I could easily find out for myself. Until that happy day I will have to ask you guys to clear it up for me. Is there another operator that takes the intersection of two junctions, such that any(2,3,4,5) *some op* any(4,5,6,7) would result in any(4,5)? Tom On Thu, 10 Feb 2005 08:19:44 -0600, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Thu, Feb 10, 2005 at 10:42:34AM +, Thomas Yandell wrote: Is the following comment correct? my $x = any(2,3,4,5) and any(4,5,6,7); # $x now contains any(4,5) Short answer: I don't think so. Long answer: I tend to get very lost when dealing with junctions, so I can be completely wrong. However, watch the precedence and meanings of the operators here -- I would think that my $x = any(2,3,4,5) and any(4,5,6,7); results in $x containing any(2,3,4,5), just as my $y = 2 and 3; results in $y containing 2 (since Cand has lower precedence than C=). Even if you fixed the =/and precedence with parens, to read my $x = (any(2,3,4,5) and any(4,5,6,7)); then I think the result is still that $x contains any(4,5,6,7). It gets interpreted as (from S09): $x = any( 2 and 4, # 4 2 and 5, # 5 2 and 6, # 6 2 and 7, # 7 3 and 4, # 4 3 and 5, # 5 # etc... 5 and 6, # 6 5 and 7, # 7 ); which ultimately boils down to any(4,5,6,7). Pm
Happy day (was: Junctive Puzzles)
On Fri, Feb 11, 2005 at 09:42:06AM +, Thomas Yandell wrote: perl6 -MData::Dumper -e 'print Dumper(any(2,3,4,5) any(4,5,6,7))' ...then I could easily find out for myself. Until that happy day I will have to ask you guys to clear it up for me. Seems today is indeed that happy day: % wget -m -np http://svn.openfoundry.org/pugs/ % cd svn.openfoundry.org/pugs % perl Makefile.PL % make % ./pugs -e (any(2,3,4,5) any(4,5,6,7)).perl ((4 | 5 | 6 | 7)) Thanks, /Autrijus/ pgpcIkqVTCTOV.pgp Description: PGP signature
Re: Happy day (was: Junctive Puzzles)
Very impressive. Has inspired me to learn some Haskell. Thanks, Tom On Fri, 11 Feb 2005 21:17:35 +0800, Autrijus Tang [EMAIL PROTECTED] wrote: On Fri, Feb 11, 2005 at 09:42:06AM +, Thomas Yandell wrote: perl6 -MData::Dumper -e 'print Dumper(any(2,3,4,5) any(4,5,6,7))' ...then I could easily find out for myself. Until that happy day I will have to ask you guys to clear it up for me. Seems today is indeed that happy day: % wget -m -np http://svn.openfoundry.org/pugs/ % cd svn.openfoundry.org/pugs % perl Makefile.PL % make % ./pugs -e (any(2,3,4,5) any(4,5,6,7)).perl ((4 | 5 | 6 | 7)) Thanks, /Autrijus/
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: [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 ab and bc then ac. OTOH... perhaps we are working with partially ordered sets (rather than completely ordered sets)? In that case maybe the above suggestion is useful after all. 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.
[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
Fwd: Junctive puzzles.
Sorry if you get this twice (and slightly different), but I posted it off list by mistake. -- Forwarded message -- From: Thomas Yandell [EMAIL PROTECTED] Date: Thu, 10 Feb 2005 10:22:44 + Subject: Re: Junctive puzzles. To: Matthew Walton [EMAIL PROTECTED] 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). Is it perhaps the comments that are wrong, rather than the code? my $x = any(1,2,3,4,5,6,7); if(is_prime($x) # expression evaluates to any(2,3,5,7) and is_even($x) # expresion evaluates to any(2, 4, 6) # at this point the boolean expression evaluates to any(2) - is this the same as 2? and $x 2) # expression evaluates to any(3,4,5,6,7) # so result is false # $x is still any(1,2,3,4,5,6,7) Is this right? Is the following comment correct? my $x = any(2,3,4,5) and any(4,5,6,7); # $x now contains any(4,5) Tom
Re: Fwd: Junctive puzzles.
On Thu, Feb 10, 2005 at 10:42:34AM +, Thomas Yandell wrote: Is the following comment correct? my $x = any(2,3,4,5) and any(4,5,6,7); # $x now contains any(4,5) Short answer: I don't think so. Long answer: I tend to get very lost when dealing with junctions, so I can be completely wrong. However, watch the precedence and meanings of the operators here -- I would think that my $x = any(2,3,4,5) and any(4,5,6,7); results in $x containing any(2,3,4,5), just as my $y = 2 and 3; results in $y containing 2 (since Cand has lower precedence than C=). Even if you fixed the =/and precedence with parens, to read my $x = (any(2,3,4,5) and any(4,5,6,7)); then I think the result is still that $x contains any(4,5,6,7). It gets interpreted as (from S09): $x = any( 2 and 4, # 4 2 and 5, # 5 2 and 6, # 6 2 and 7, # 7 3 and 4, # 4 3 and 5, # 5 # etc... 5 and 6, # 6 5 and 7, # 7 ); which ultimately boils down to any(4,5,6,7). Pm
Re: Fwd: Junctive puzzles.
Patrick R. Michaud wrote:
Even if you fixed the =/and precedence with parens, to read
my $x = (any(2,3,4,5) and any(4,5,6,7));
then I think the result is still that $x contains any(4,5,6,7).
Funny. I thought $x would contain 'true' here, since Cand was a
boolean operator. But I could be very wrong.
The overall impression I'm getting here is that we need some syntax for
saying:
$x = any(1..1000) such_that is_prime($x);
where such_that acts as a form of junctive grep. so the above might
mean the same as:
$x = any(1..1000 == grep(is_prime($_)));
We then can say that any junction stored in a var stays constant, until
explicitly reassigned. Just like every other kind of thing we store.
Philosophy Question:
What's the difference between a junction and an array containing all the
possible values of the junction? Other than how they are used, of
course. So, on that train of thought, would this make sense:
if $x == @x.any {...}
if $x == @x.none {...}
If this is the case, then this entire discussion collapses into how to
best convert arrays into junctions and junctions into arrays. Perl's
existing abilities to edit arrays should be more than sufficient for
editing junctions.
-- Rod Adams
Re: Fwd: Junctive puzzles.
Patrick Michaud wrote: On Thu, Feb 10, 2005 at 10:42:34AM +, Thomas Yandell wrote: Is the following comment correct? my $x = any(2,3,4,5) and any(4,5,6,7); # $x now contains any(4,5) Short answer: I don't think so. Long answer: decloak Patrick is right on the money here...as usual. (Don't you just *love* that in the guy who's job it is to actually make this stuff work! ;-) Damian recloak
Re: Fwd: Junctive puzzles.
Rod Adams wrote:
The overall impression I'm getting here is that we need some syntax for
saying:
$x = any(1..1000) such_that is_prime($x);
In standard Perl 6 that'd be:
$x = any(grep {is_prime $^x} 1..1000);
or, if you prefer your constraints postfixed:
$x = any( (1..1000).grep({is_prime $^x}) );
If you really wanted a such that operator you could certainly create one
yourself:
multi sub *infix:such_that (Junction $j, Code $constraint) {
return $j.type.new(grep $constraint, $j.values);
}
$x = any(1..1000) such_that {is_prime $^x};
Though, personally, I think a C.where method with an adverbial block might
be neater:
multi method Junction::where (Junction $j: *constraint) {
return $j.type.new(grep constraint, $j.values);
}
$x = any(1..1000).where:{is_prime $^x};
# or...
$x = where any(1..1000) {is_prime $^x};
We then can say that any junction stored in a var stays constant, until
explicitly reassigned. Just like every other kind of thing we store.
Yep. That's exactly what we'll be saying!
Philosophy Question:
What's the difference between a junction and an array containing all the
possible values of the junction?
Junctions have an associated boolean predicate that's preserved across
operations on the junction. Junctions also implicitly distribute across
operations, and rejunctify the results.
So, on that train of thought, would this make sense:
if $x == @x.any {...}
if $x == @x.none {...}
Probably. It's entirely possible that, in addition to being built-in list
operators, Call, Cany, Cone, and Cnone are also multimethods on
Scalar, Array, and List.
Damian
Sets vs Junctions (was Junctive puzzles.)
Damian Conway wrote:
Rod Adams wrote:
The overall impression I'm getting here is that we need some syntax
for saying:
$x = any(1..1000) such_that is_prime($x);
In standard Perl 6 that'd be:
$x = any(grep {is_prime $^x} 1..1000);
or, if you prefer your constraints postfixed:
$x = any( (1..1000).grep({is_prime $^x}) );
Both of those seem way too brutal to me.
We then can say that any junction stored in a var stays constant,
until explicitly reassigned. Just like every other kind of thing we
store.
Yep. That's exactly what we'll be saying!
Good.
Philosophy Question:
What's the difference between a junction and an array containing all
the possible values of the junction?
Junctions have an associated boolean predicate that's preserved across
operations on the junction. Junctions also implicitly distribute
across operations, and rejunctify the results.
My brain is having trouble fully grasping that. Let me attempt a paraphrase:
Junctions exist to be tested for something.
When a test is performed, the junction is evaluated in terms of that
test. A result junction is created, which contains only the elements
of the original junction which will pass that given test. If the result
junction is empty, the test fails.
Looking at the S09 C substr(camel, 0|1, 23) example explains a lot.
So, on that train of thought, would this make sense:
if $x == @x.any {...}
if $x == @x.none {...}
Probably. It's entirely possible that, in addition to being built-in
list operators, Call, Cany, Cone, and Cnone are also
multimethods on Scalar, Array, and List.
okay.
--
Now that I've gotten some feedback from my original message (on list and
off), and have had some time to think about it some more, I've come to a
some conclusions:
Junctions are Sets. (if not, they would make more sense if they were.)
Sets are not Scalars, and should not be treated as such.
If we want Sets in Perl, we should have proper Sets.
Let's first define what a Set is:
- A Set is an unordered collection of elements in which duplicates are
ignored.
- There are really only two questions to ask of a Set: Is X a member of
you?, and What are all your member?
- Typically, all members of a set are of the same data type. (I'm in no
way committed to this being part of the proposal, but it makes sense if
it is)
Sets and Lists are two different things. Lists care about order and
allow duplicates. Iterating a Set produces a List, and one can convert a
List into a Set fairly easily.
Sets and Hashes are quite similar, but in other ways different. The keys
of a Hash are a Set of type String. In addition to the String
constraint, each element of the set has an additional scalar value
associated with it. Hashes can be multidimensioned. I have no idea what
a multidimensional Set is. It may be possible to represent Sets as
lightweight Hashes if the Strings for keys constraint is lifted or
altered, but I see several advantages to Sets being distinct, for
reasons I'll outline below.
So I propose making Sets a first class data type right up there with
Arrays, Hashes, and Scalars. For the purposes of this posting, I will
assume that they get a sigil of #. (to get a comment, you need
whitespace after the #). I harbor no expectations that it will stay as
this, but I needed something, and didn't feel like remapping my keyboard
at the moment. Interestingly, on US keyboards, @#$% is shift-2345.
With that, we can now make existing operators do nifty things:
#a = #b + #c;# Union (Junctive $b or $c)
#a = #b - #c;# Difference( $b and not $c)
#a = #b * #c;# Intersection ( $b and $c)
#a == #b;# Do sets contain the same values?
#a #b;# Is #a a subset of #b? likewise , =, =
$a ~~ #b;# Membership
#a += $b;# Add value to set
#a = @b; # Create a set from an array/list
#a = (1,2,3);
$ref = #{1..10}; # an anonymous Set reference
@a = #b; # One way to iterate the members.
It's probably best to define binary | and as Set Creation with
Union/Intersection, so we have:
#a = 1|3|7;
#a + @b == #a | @b;
We also add some methods here and there:
@a = #b.values;
#b = @a.as_set;
$a = #b.elems;
my str #a = %b.keys;
I also envision virtual sets, which cannot be iterated, but can be
tested for membership against. These would be defined by a closure or
coderef.
#natural_numbers = { $^a == int($^a) $^a 0 };
#primes = is_prime;
Set operations with virtual sets should be able to define new closures
based on the former ones:
#a = #b + #c; == #a = {$^a ~~ #b || $^a ~~ #c};
#a = #b * #c; == #a = {$^a ~~ #b $^a ~~ #c};
#a = #b - #c; == #a = {$^a ~~ #b $^a !~ #c};
#a = #b + 3; == #a = {$^a == 3 || $^a ~~ #b};
So now, some sample code:
$x = any( (1..1000).grep({is_prime $^x}) ); # Damian's example from above
vs
#x = (1..1000) * #primes;
if $x == 1|2|3 {...}
vs
if $x ~~ 1|2|3 {...}
or
if $x ~~ #{1,2,3} {...}
$x = (any(2,3,4,5) and any(4,5,6,7));
# where $x ==
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 ab and bc then ac. OTOH... perhaps we are working with partially ordered sets (rather than completely ordered sets)? In that case maybe the above suggestion is useful after all. --Brock
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 (a b c);
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: 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 (a b c);
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.
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, xyz does not mean y is between x and z, which is how
most people probably read it. Instead, because of chain association,
it means xy and yz. Our problem then comes from using y in two
different terms instead of a single 'between' term: If we had a
'between' operator, y between [x,z] would work even for junctions.
The chain-association thing puzzled me a bit, because in the back of
my mind I was still thinking of comparative operators as doing their
chainy magic by returning a value to be applied to the following term
(sort of like +) -- no 'and's involved. In 462, the 46 returns 6
but true, and then we're left with 62, which is false.
Similarly, 4(0|6)2 first evaluates 4(0|6) aka 40 | 46.
Booleating a junction returns the elements that fit, in this case 6.
Then we move on to evaluate 62, which again is false, just as we
wanted.
http://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 Cundefs on-sight (i.e. Cundef can never be a
member of a junction).
* Comparison operators return Cundef if they fail, and their
left-hand side Cbut true 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$j2 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 | (45));
$petticoat.conjunctions; # list containing (1|2|3|(45))
$petticoat.disjunctions; # list containing 1, 2, 3, (45)
($petticoat.disjunctions)[-1].conjunctions;# list 4, 5
- David guilty by list association Green
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.
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.
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.
[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 (a b c);
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.
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 (a b c);
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.
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: [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.
[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.
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/ pgpbnBpjxcFNh.pgp Description: PGP signature
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 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 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/ pgpotskZohEWZ.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 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/ pgpQWUaVT16VQ.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 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/ pgpAlnZw2wjvl.pgp Description: PGP signature
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
Junctive puzzles.
(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) 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) My intuition is that it should be equivalent to this: pugs ? (2 0 4) | (2 3 4) (#f|#t) That is, the autothreading should operate on the whole comparison chain, treating it as a large variadic function with short-circuiting semantics. Is this perhaps saner than the blind rewrite suggested in the spec? Also, consider this: pugs ? 1|2 = 3|4 (((1 = 3)|(1 = 4))|((2 = 3)|(2 = 4))) Since junctions are documented to only flatten on boolean context, here the pair-building arrow has been autothreaded. Is it the intended semantic? What about the list-building semicolon? Thanks, /Autrijus/ pgp876hJTXK2E.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
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/ pgpcWDsiCDerP.pgp Description: PGP signature
