Re: On Junctions
On Sun, Mar 29, 2009 at 10:57 PM, Mark Lentczner wrote:
> What I see here is that there is a tendency to want to think about, and
> operate on, the eigenstates as a Set, but this seems to destroy the "single
> value" impersonation of the Junction.
In my case, this tendency comes more from a desire to be able to
reverse the creation of a junction: you create a (singular) junction
from a (plural) list ('1|3|5' === 'any 1, 3, 5'); so I naturally want
to be able to (more or less) reverse this process and create a
(plural) Set from a (singular) junction.
> Further, if one ever calls .!eigenstates() on a Junction, then you have
> really bollox'd your code up, as then this code fails if the value you
> thought was a Junction happens to be, actually, just a single value!
> (Unless .!eigenstates() is defined on Object, and returns a Set of self...)
Which is why I'd _want_ eigenstates to be callable on an Object as
described - and, in general, _any other_ function that operates
directly on junctions should be able to accept Objects as well,
treating the Object as a one-eigenstate junction.
Otherwise, the moment you write a function that passes a junction as a
parameter, your code will break if you ever try to pass an Object in
instead. And the only other ways to avoid that would be: 1. to
provide a means of testing whether or not something is a junction, or
2. to forbid anyone from ever using "junction" in a signature.
> I think what is needed is a "single value" threshing function, which can be
> applied to, well, single values. Such a function would take a value and a
> predicate, and if the predicate applied to the value is true, returns the
> value, else it returns... nothing. If such a function were applied to a
> Junction, then the result would be a Junction of just those those
> eigenstates that "passed" this function. The "nothings" would not end up
> contributing to the Junction.
...that could work. The only catch is that if you ever want to get a
list of the cases that passed so that you can operate on them
individually, you'd still need a means of extracting the eigenstates
from the junction.
> Now, I'm not sure I know how to return "nothing" in Perl6, but I'll guess
> that undef can serve the purpose, since I can't think of a useful use of
> undef as part of a Junction.
As Daniel indicated, returning an empty list should work.
--
Jonathan "Dataweaver" Lang
Re: On Junctions
Em Dom, 2009-03-29 às 22:57 -0700, Mark Lentczner escreveu:
> What I see here is that there is a tendency to want to think about,
> and operate on, the eigenstates as a Set, but this seems to destroy
> the "single value" impersonation of the Junction.
> Further, if one ever calls .!eigenstates() on a Junction, then you
> have really bollox'd your code up, as then this code fails if the
> value you thought was a Junction happens to be, actually, just a
> single value! (Unless .!eigenstates() is defined on Object, and
> returns a Set of self...)
++
This is the most important semantic deadlock, thanks for putting it so
clearly.
> I think what is needed is a "single value" threshing function, which
> can be applied to, well, single values. Such a function would take a
> value and a predicate, and if the predicate applied to the value is
> true, returns the value, else it returns... nothing. If such a
> function were applied to a Junction, then the result would be a
> Junction of just those those eigenstates that "passed" this function.
> The "nothings" would not end up contributing to the Junction.
Well, that can be thought as grep.
my @i = 1|11, 9, 1|11;
my @j = 6,9,6;
my $a = [+] @i;
my $b = [+] @j;
my $va = $a.grep: * <= 21;
my $vb = $b.grep: * <= 21;
if ($va && $vb) {
if ($va > $vb) {
# a wins
} elsif ($vb > $va) {
# b wins
} else {
# draw
}
}
If we have grep as a method in Any, the call to grep will autothread,
returning a junction of the values, so, as $a is any(11, 21, 31), $va
would be any(11,21,()), which should collapse as expected.
> Now, I'm not sure I know how to return "nothing" in Perl6, but I'll
> guess that undef can serve the purpose, since I can't think of a
> useful use of undef as part of a Junction.
Well, you return nothing simply by calling "return;" it will produce an
empty capture, which could be seen simply as ().
daniel
Re: On Junctions
What I see here is that there is a tendency to want to think about,
and operate on, the eigenstates as a Set, but this seems to destroy
the "single value" impersonation of the Junction.
Further, if one ever calls .!eigenstates() on a Junction, then you
have really bollox'd your code up, as then this code fails if the
value you thought was a Junction happens to be, actually, just a
single value! (Unless .!eigenstates() is defined on Object, and
returns a Set of self...)
I think what is needed is a "single value" threshing function, which
can be applied to, well, single values. Such a function would take a
value and a predicate, and if the predicate applied to the value is
true, returns the value, else it returns... nothing. If such a
function were applied to a Junction, then the result would be a
Junction of just those those eigenstates that "passed" this function.
The "nothings" would not end up contributing to the Junction.
Now, I'm not sure I know how to return "nothing" in Perl6, but I'll
guess that undef can serve the purpose, since I can't think of a
useful use of undef as part of a Junction.
sub suchthat(Any $v, &predicate) { predicate($v) ?? $v !! undef }
So now:
$a = 1|2|3|4|5
say suchthat($a, odd)
>>> 1|3|5
$b = 1&2&3&4&5
say suchthat($a, odd)
>>> 1&3&5
And in the poker example:
@p = 1|11, 2, 1|11;
@d = 1|11, 3, 1|11;
$pv = suchthat([+] @p, {$_ <= 21})
$dv = suchthat([+] @d, {$_ <= 21})
if $pv and (!$dv or $pv > $dv) { say 'p wins!' };
- MtnViewMark
Mark Lentczner
http://www.ozonehouse.com/mark/
m...@glyphic.com
Re: On Sets (Was: Re: On Junctions)
On Sun, Mar 29, 2009 at 1:18 PM, John Macdonald wrote:
> On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote:
>> That happens because $pa and $pb are a singular value, and that's how
>> junctions work... The blackjack program is an example for sets, not
>> junctions.
>>
>> Now, what are junctions good for? They're good for situation where it's
>> collapsed nearby, which means, it is used in boolean context soon
>> enough. Or where you know it's not going to cause the confusion as in
>> the above code snippet.
>
> Unfortunately, it is extremely common to follow up a boolean "is this
> true" with either "if so, how" and/or "if not, why not". A boolean test
> is almost always the first step toward dealing with the consequences,
> and that almost always requires knowing not only what the result of the
> boolean test were, but which factors caused it to have that result.
True point. Along these lines, I'd like to see at least one
"threshing function" that separates a junction's eigenstates that
passed a boolean test from those that didn't. I can see several
possible semantics for such:
1. It returns a list of the eigenstates that passed the test.
2. It returns a junction composed of only those parts of the
junction which passed the test.
3. It returns a two-item list: the wheat and the chaff. The form
that the items take would conform to one of the first two options.
The "G[op]" proposal could be thought of as one approach to the first
option. Note also that this option can be turned into a generic "list
all of the eigenstates" function by choosing a "test" that every
possible eigenstate is guaranteed to pass; as such, it would be a very
small step from this sort of threshing function to a public
.eigenstates method - e.g., "$j.eigenstates :where { ... }" (to add
optional threshing capabilities to a "list of eigenstates" function)
or "* G~~ $j" (to use a thresher to retrieve all of the eigenstates).
The "infix: (junction, Code --> junction)" proposal that I made
earlier is an example of the second option. This option has the
advantage that it preserves as much of the junction's internal
structure (e.g., composite junctions) as possible, in case said
structure may prove useful later on. (I'm a big fan of not throwing
anything away until you're sure that you don't need it anymore.) The
downside is that if you want a list of the eigenstates that passed the
test, this is only an intermediate step to getting it: you still have
to figure out how to extract a list of eigenstates from the threshed
junction.
The third "option" has the benefit of letting you handle "if so" & "if
not" without having to thresh twice, once for the wheat and again for
the chaff. OTOH, it's bound to be more complicated to work with, and
is overkill if you only care about one of the outcomes. I have no
syntax proposals at this time.
Note further that these aren't necessarily mutually exclusive options:
TIMTOWTDI. I prefer the ones that use some form of "where"; but
that's just because those approaches feel intuitive to me.
> The canonical example of quantum computing is using it to factor huge
> numbers to break an encryption system. There you divide the huge number
> by the superposition of all of the possible factors, and then take the
> eigenstate of the factors that divide evenly to eliminate all of the
> huge pile of potential factors that did not divide evenly. Without
> being able to take the eigenstate, the boolean answer "yes, any(1..n-1)
> divides n" is of very little value.
Right. Something like:
any(2 ..^ $n).eigenstates :where($n mod $_ == 0)
or:
( any(2 ..^ $n) where { $n mod $_ == 0 } ).eigenstates
...might be ways to get a list of the factors of $n. (I'm not sure
how this would be done with junctions and the proposed grep
metaoperator - although I _can_ see how to do it with _just_ the
metaoperator, or with just a grep method. But that's list
manipulation, not junctive processing.) Of course, evaluating this
code could be a massive headache without a quantum processor.
I'm sure that one _could_ come up with a Set-based approach to doing
this; it might even be fairly easy to do. But again, TIMTOWTDI. Perl
has never been about trying to come up with an "ideal" approach and
then forcing everyone to use it - that would be LISP, among others.
Telling people that they must use Sets instead of junctions in cases
such as this runs counter to the spirit of Perl.
--
Jonathan "Dataweaver" Lang
Re: On Sets (Was: Re: On Junctions)
On Sat, Mar 28, 2009 at 10:39:01AM -0300, Daniel Ruoso wrote: > That happens because $pa and $pb are a singular value, and that's how > junctions work... The blackjack program is an example for sets, not > junctions. > > Now, what are junctions good for? They're good for situation where it's > collapsed nearby, which means, it is used in boolean context soon > enough. Or where you know it's not going to cause the confusion as in > the above code snippet. Unfortunately, it is extremely common to follow up a boolean "is this true" with either "if so, how" and/or "if not, why not". A boolean test is almost always the first step toward dealing with the consequences, and that almost always requires knowing not only what the result of the boolean test were, but which factors caused it to have that result. The canonical example of quantum computing is using it to factor huge numbers to break an encryption system. There you divide the huge number by the superposition of all of the possible factors, and then take the eigenstate of the factors that divide evenly to eliminate all of the huge pile of potential factors that did not divide evenly. Without being able to take the eigenstate, the boolean answer "yes, any(1..n-1) divides n" is of very little value.
Re: On Junctions
Jon Lang wrote:
> I stand corrected. That said: with the eigenstates method now
> private, it is now quite difficult to get a list of the eigenstates of
> the above expression.
I thought about that a bit, and I think eigenstates are not hard to
extract (which somehow makes the privateness of .eigstates a bit
absurd), simply by autothreading:
sub e(Object $j) {
my @states;
-> Any $x { @states.push($x) }.($j);
return @states;
}
Cheers,
Moritz
Re: On Sets (Was: Re: On Junctions)
Henry Baragar wrote:
> The blackjack program is an excellent example for junctions (and not so good
> for sets, IMHO). The problem in the example above is that the calculation
> of the value of a hand was not completed. The complete calculation is as
> follows:
>
> my $pa = ([+] @a).eigenstates.grep{$_ <21}.max
Per the recent change to the synopses, eigenstates is now a private
method, rendering the above code invalid.
--
Jonathan "Dataweaver" Lang
Re: On Sets (Was: Re: On Junctions)
Daniel Ruoso wrote:
But even to compare two hands it gets weird...
my @a = 1|11, 9, 1|11;
my @b = 6,9,6;
my $pa = [+] @a;
my $pb = [+] @b;
if ($pa <= 21 && $pb <= 21) {
if ($pa > $pb) {
# B0RK3D
}
}
That happens because $pa and $pb are a singular value, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
The blackjack program is an excellent example for junctions (and not so
good for sets, IMHO). The problem in the example above is that the
calculation of the value of a hand was not completed. The complete
calculation is as follows:
my $pa = ([+] @a).eigenstates.grep{$_ <21}.max
If the result is undef, then the @a hand is a bust, and comparing $pa to
a similarly calculated $pb is sane.
Henry
daniel
Re: On Sets (Was: Re: On Junctions)
Thomas Sandlaß wrote: > Set operations are with parens. Which Synopsis is this in? -- Jonathan "Dataweaver" Lang
Re: On Sets (Was: Re: On Junctions)
On Sat, Mar 28, 2009 at 6:39 AM, Daniel Ruoso wrote: > Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu: >> Daniel Ruoso wrote: >> > The thing is that junctions are so cool that people like to use it for >> > more things than it's really usefull (overseeing that junctions are too >> > much powerfull for that uses, meaning it will lead to unexpected >> > behaviors at some point). >> What are the general boundaries for junctions? > > Junctions are superposition of values with a given collapsing type. > > The most important aspect of junctions is that they are a singular > value, which means that they are transparent to the code using it. You > always use it as a singular value, and that's what keep its semantics > sane. Closely related to this is that junctions autothread. If you type in "foo($a | $b)", it will be processed exactly as if you had typed "foo($a) | foo($b)" - that is, it will call foo twice, once for $a and once for $b, and it won't care which order it uses. And this is true whether or not you know that a junction is involved. Given 'foo($j)', foo will be called once if $j isn't a junction, and will be called multiple times if $j is a junction. If you were dealing with a Set instead, you'd need to make use of 'map' and/or hyperoperators to achieve a similar result. -- Jonathan "Dataweaver" Lang
Re: On Junctions
Patrick R. Michaud wrote:
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the "value of the hand" is:
my $p = ([+] @p).map{.eigenstates}.grep{$_ < 21}.max;
Since the result of [+] is a scalar we don't need to 'map' it.
Assuming that .eigenstates exists it would then be
my $p = ([+] @p).eigenstates.grep({ $_ < 21 }).max
Argh... the multiple personalities of the junction caused me to forget
that there is only one scalar! HB
Pm
Re: On Sets (Was: Re: On Junctions)
HaloO, On Friday, 27. March 2009 12:57:49 Daniel Ruoso wrote: > 1 - multi infix:<+>(Set $set, Num $a) > This would return another set, with each value of $set summed with $a. I think that this mixed case should numify the set to the number of elements to comply with array semantics. infix:<+> should remain a numeric operator and numify other operant types. This operator orientation is a strong feature of Perl 6 and should not be diluted by overloads with non-numeric meanings. > 2 - multi infix:<+>(Set $a, Set $b) > This would return another set, with $a.values X+ $b.values, already > removing duplicated values, as expected from a set. Even the homogeneous case should adhere to numeric semantics. Set operations are with parens. So disjoint union creation is (+). We could try to get a meta parens so that (X+) is conceivably auto-generated. OTOH it collides with (+) visually. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: On Junctions
Daniel Ruoso wrote: > But the semantics of sets are still somewhat blurry... there are some > possibilities: > > 1) Sets are in the same level as junctions, but have no collapsing and > allow you to get its values. The problem is if it autothreads on > method calls or not... It also makes $a > $b confuse... > > 2) Set ~~ Any, and all the inteligence is made implementing multis, > it has the disadvantage that new operators will need to have > explicit implementations in order to get Set DWIMmery... > > I have been unsure about that, but lately I'm mostly thinking option 2 > is the sanest, which means we only get as much DWIMmery as explicitly > implemented (which may or may not be a good idea). My understanding is that Set operates on the same level as Hash and List - indeed, a Set could be thought of as a Hash that only cares about the keys but not the values, and has a few additional methods (i.e., the set operations). That is, a junction is an item with an indeterminate value; but a Set is a collection of values in the same way that a hash is. And the proper sigil for a Set is %, not $. -- Jonathan "Dataweaver" Lang
Re: On Junctions
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
> I believe that there are hands where $p = 15|26 which would not beat a
> hand where $d = 17.
>
> I believe that the correct way to calculate the "value of the hand" is:
>
>my $p = ([+] @p).map{.eigenstates}.grep{$_ < 21}.max;
Since the result of [+] is a scalar we don't need to 'map' it.
Assuming that .eigenstates exists it would then be
my $p = ([+] @p).eigenstates.grep({ $_ < 21 }).max
Pm
Re: On Sets (Was: Re: On Junctions)
Em Sáb, 2009-03-28 às 13:36 +0300, Richard Hainsworth escreveu:
> Daniel Ruoso wrote:
> > The thing is that junctions are so cool that people like to use it for
> > more things than it's really usefull (overseeing that junctions are too
> > much powerfull for that uses, meaning it will lead to unexpected
> > behaviors at some point).
> What are the general boundaries for junctions?
Junctions are superposition of values with a given collapsing type.
The most important aspect of junctions is that they are a singular
value, which means that they are transparent to the code using it. You
always use it as a singular value, and that's what keep its semantics
sane.
The boundary is where you try to use a junction as a plural value, and
that's where the semantics get weird...
> Perhaps, it might help to see some more examples of how junctions should
> be used?
They should be used as a singular value... which means that the
blackjack example is only a good example for junctions, as far as to
know if the user has busted.
my @hand = 1|11, 9, 1|11;
my $sum = [+] @hand;
if ($sum <= 21) {
# valid game
} else {
# busted!
}
The semantic is sane that way because it doesn't make a difference if
there is a junction or not...
my @hand = 6, 9, 6;
my $sum = [+] @hand;
if ($sum <= 21) {
# valid game
} else {
# busted!
}
But even to compare two hands it gets weird...
my @a = 1|11, 9, 1|11;
my @b = 6,9,6;
my $pa = [+] @a;
my $pb = [+] @b;
if ($pa <= 21 && $pb <= 21) {
if ($pa > $pb) {
# B0RK3D
}
}
That happens because $pa and $pb are a singular value, and that's how
junctions work... The blackjack program is an example for sets, not
junctions.
Now, what are junctions good for? They're good for situation where it's
collapsed nearby, which means, it is used in boolean context soon
enough. Or where you know it's not going to cause the confusion as in
the above code snippet.
Sets can provide the cool DWIMmery junction provides for the blackjack
case and still provide sane semantics for you to get its compound
values.
daniel
Re: On Junctions
Em Sáb, 2009-03-28 às 16:17 +1100, Damian Conway escreveu:
> Nested heterogeneous junctions are extremely useful. For example, the
> common factors of two numbers ($x and $y) are the eigenstates of:
> all( any( factors($x) ), any( factors($y) ) )
I think that's the exact case where we should be using sets instead...
my $common_factors = factors($x) ∩ factors($y)
Assuming we have...
multi infix:<∩>(List @a, List @b --> Set) {...}
multi infix:<∩>(Set @a, Set @b --> Set) {...}
... and variants ...
But the semantics of sets are still somewhat blurry... there are some
possibilities:
1) Sets are in the same level as junctions, but have no collapsing and
allow you to get its values. The problem is if it autothreads on
method calls or not... It also makes $a > $b confuse...
2) Set ~~ Any, and all the inteligence is made implementing multis,
it has the disadvantage that new operators will need to have
explicit implementations in order to get Set DWIMmery...
I have been unsure about that, but lately I'm mostly thinking option 2
is the sanest, which means we only get as much DWIMmery as explicitly
implemented (which may or may not be a good idea).
daniel
Re: On Sets (Was: Re: On Junctions)
Daniel Ruoso wrote: The thing is that junctions are so cool that people like to use it for more things than it's really usefull (overseeing that junctions are too much powerfull for that uses, meaning it will lead to unexpected behaviors at some point). What are the general boundaries for junctions? We know that engineering type problems should be solved using floating point variables rather than integers (although it is probable that an integer solution probably would be possible - it would be excessively complicated). Perhaps, it might help to see some more examples of how junctions should be used? Regards, Richard
Re: On Junctions
> I stand corrected. That said: with the eigenstates method now private,
> it is now quite difficult to get a list of the eigenstates of the
> above expression.
Yes, that's a concern. Most of the interesting junction-based algorithms
I've developed in the past rely on two facilities: the ability to
extract eigenstates, and the ability to "thresh" a junction: to
determine which eigenstates caused a boolean expression involving the
junction to be true.
However, I suspect that if these two capabilities prove to be
all("not easy", "very useful") in Perl 6, there will soon be a module
that facilitates them. ;-)
Damian
Re: On Junctions
Damian Conway wrote: > Jon Lang wrote: > >> For that matter, I'm not seeing a difference between: >> >> any( 1&2 ) # any of all of (1, 2) >> >> ...and: >> >> any( 1, 2 ) # any of (1, 2) > > Those two are very different. > > any(1,2) == 2 is true > > any(1&2) == 2 is false > > > Nested heterogeneous junctions are extremely useful. For example, the > common factors of two numbers ($x and $y) are the eigenstates of: > > all( any( factors($x) ), any( factors($y) ) ) I stand corrected. That said: with the eigenstates method now private, it is now quite difficult to get a list of the eigenstates of the above expression. -- Jonathan "Dataweaver" Lang
Re: On Junctions
Jon Lang wrote: > For that matter, I'm not seeing a difference between: > >any( 1&2 ) # any of all of (1, 2) > > ...and: > >any( 1, 2 ) # any of (1, 2) Those two are very different. any(1,2) == 2 is true any(1&2) == 2 is false Nested heterogeneous junctions are extremely useful. For example, the common factors of two numbers ($x and $y) are the eigenstates of: all( any( factors($x) ), any( factors($y) ) ) > If I'm not mistaken on these matters, that means that: > >any( 1|2, 1&2, 5|15, 5&15 ) eqv any(1, 2, 5, 15) No. They have equivalent eigenstates, but they are not themselves equivalent. For example, any( 1|2, 1&2, 5|15, 5&15 ) compares == to 1&2; whereas any(1, 2, 5, 15) doesn't. > And I expect that similar rules hold for other compound junctions. In > short, I won't be surprised if all compound junctions can flatten into > equivalent simple junctions. In general, they can't; not without changing their meaning. Damian
Re: On Junctions
Dave Whipp wrote:
> [I’d been planning to put this suggestion on hold until the spec is
> sufficiently complete for me to attempt to implement it as a module. But
> people are discussing this again, so maybe it's not just me. I apologize if
> I appear to be beating a dead horse...]
>
> Jon Lang wrote:
>
>> Maybe you could have something like a filter function
>
> yes, but
>
>> that takes a
>> junction and a test condition and returns a junction of those
>> eigenstates from the original one that passed the test.
>
> But why is this a useful thing to do? I think that you're proposing, for
> compound junctions:
>
> ok any( 1|2, 1&2, 5|15, 5&15 ) where { $_ < 10 }
> === any( 1|2, 1&2, 5|15 )
...not really, no. The way I was looking at it, the above expression
is ultimately a junction of the values 1, 2, 5, and 15; no matter how
compounded the junction is, these would be its eigenstates. Since 15
would fail the test, anything having to do with it would be filtered
out. Exactly how that would work with a compound junction, I'm not
sure; as I said, I was thinking of the eigenstates as ordinary items,
not "nested junctions". But yes, I _was_ suggesting something that
transforms one junction into another.
That said, I'm also leery of compound junctions. Please tell me the
difference between:
any( 1|2 )
...and:
any( 1, 2 )
If there is no difference, then:
any( 1|2, 1&2, 5|15, 5&15 ) eqv any( 1, 2, 1&2, 5, 15, 5&15 )
For that matter, I'm not seeing a difference between:
any( 1&2 ) # any of all of (1, 2)
...and:
any( 1, 2 ) # any of (1, 2)
If I'm not mistaken on these matters, that means that:
any( 1|2, 1&2, 5|15, 5&15 ) eqv any(1, 2, 5, 15)
And I expect that similar rules hold for other compound junctions. In
short, I won't be surprised if all compound junctions can flatten into
equivalent simple junctions.
> To me, it still feels like you're thinking of a junction as a set of values,
> and inventing an operator specifically for the purpose of messing with those
> values. I do not see "values of a junction" as a meaningful user-level
> concept.
I'm pretty sure that Larry agrees with you here, seeing as how his
latest revision concerning junctions makes direct access to a
junction's eigenstates very difficult to arrange.
> I prefer to turn the problem around, and suggest a different
> operator, motivated by a different issue, and then apply that operator to
> junctions.
> Consider this statement:
>
> say (0..Inf).grep: { $_ < 10 };
>
> I would expect it to take infinite time to complete (or else fail quickly).
> It would be wrong to expect perl to figure out the correct answer
> analytically, because that is impossible in the general case of an arbitrary
> code block. So I instead propose an operator-based grep:
>
> say 0..inf G[<] 10;
> >>> [0..9]
>
> This “grep metaoperator” can be expected to analytically determine the
> result (of grepping an infinite list) in finite time.
>
> It might also be used
> to avoid curlies for simple greps:
>
> say @lines G~~ /foo/;
>
> The operator exists to filter infinite lists in finite time. But it also
> solves the junction problem:
>
> say (-Inf .. Inf) G== 3|4;
> >>> [3,4]
And how would it handle a compound junction (assuming they exist)? That is:
say (-Inf .. Inf) G== any(1|2, 1&2, 5|15, 5&15);
>>> ???
> $score = [+] 1|11, 1|11, 1+11, 1+11, 4;
I assume you meant:
$score = [+] 1|11, 1|11, 4;
> say max( 1..21 G== $score ) // "bust";
> >>> 18
...and the answer to that would be 16, right?
--
Jonathan "Dataweaver" Lang
Re: On Junctions
[I’d been planning to put this suggestion on hold until the spec is
sufficiently complete for me to attempt to implement it as a module. But
people are discussing this again, so maybe it's not just me. I apologize
if I appear to be beating a dead horse...]
Jon Lang wrote:
Maybe you could have something like a filter function
yes, but
that takes a
junction and a test condition and returns a junction of those
eigenstates from the original one that passed the test.
But why is this a useful thing to do? I think that you're proposing, for
compound junctions:
ok any( 1|2, 1&2, 5|15, 5&15 ) where { $_ < 10 }
=== any( 1|2, 1&2, 5|15 )
To me, it still feels like you're thinking of a junction as a set of
values, and inventing an operator specifically for the purpose of
messing with those values. I do not see "values of a junction" as a
meaningful user-level concept. I prefer to turn the problem around, and
suggest a different operator, motivated by a different issue, and then
apply that operator to junctions.
Consider this statement:
say (0..Inf).grep: { $_ < 10 };
I would expect it to take infinite time to complete (or else fail
quickly). It would be wrong to expect perl to figure out the correct
answer analytically, because that is impossible in the general case of
an arbitrary code block. So I instead propose an operator-based grep:
say 0..inf G[<] 10;
>>> [0..9]
This “grep metaoperator” can be expected to analytically determine the
result (of grepping an infinite list) in finite time. It might also be
used to avoid curlies for simple greps:
say @lines G~~ /foo/;
The operator exists to filter infinite lists in finite time. But it also
solves the junction problem:
say (-Inf .. Inf) G== 3|4;
>>> [3,4]
say ^Int G== 3|4; ## assuming ^Int means “any Int value”
>>> [3,4]
$score = [+] 1|11, 1|11, 1+11, 1+11, 4;
say max( 1..21 G== $score ) // "bust";
>>> 18
Re: On Junctions
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new
and different from anything I have encountered, but I cant get rid of
the feeling that there needs to be some more flexibility in their use
to make them a common programming tool.
Background: Imagine a hand of cards. Cards may be Ace, Two, Three. Ace
having either the values 1 or 11, depending on context, the other
cards their face value. Sums of a hand over 21 are invalid.
Hands with multiple junctions become interesting, eg.,
p: Ace, Two, Ace
d: Ace, Three, Ace
Given that Ace has a value of 1 or 11 depending on context, it would
seem natural to use a junction. Hence the two hands can be expressed as:
@p = 1|11, 2, 1|11;
@d = 1|11, 3, 1|11;
If we use [+] to add these, we get
$p = [+] @p; say $p.perl; # any(any(4,14),any(14,24))
$d = [+] @d; say $d.perl; #any(any(5,15),any(15,25))
Since the values of 24 & 25 are greater than 21, they must be
eliminated from consideration.
What we want is for hand @d to beat hand @p because 15 > 14
On #perl6, rouso, masak and moritz_ explained that I am incorrectly
thinking about junctions as sets and that for this task I should be
using another perl idiom, namely lists. Something like:
moritz_ rakudo: ([1,11], 3, [1,11]).reduce({@($^a) X+ @($^b)})
p6eval rakudo bb22e0: RESULT«[5, 15, 15, 25]»
Then the out-of-limit values (in the above case 25) can be stripped
off using grep, viz.,
# here we have ([1,11],3,[1,11]) instead of (1|11, 3, 1|11)
my @dlist = grep { $_ < 21 } ([1,11], 3, [1,11]).reduce({@($^a) X+
@($^b)});
Then the two lists (do the same for @p) can be compared by a junction
comparison of the form
if any(@plist) > all(@dlist) { say 'p wins' };
The problem is not just that [+] @p produces a junction with undesired
(>21) eigenstates, but that the [+] @d produces a junction of the form
any(any(5,15),any(15,25)) which should collapse to any(5,15,25)
whereas we want a junction of the form
all(5,15,25)
After the #perl6 conversation, I thought some more. A junction is a
neat way of expressing the hand, but the junction needs to be
converted to a list to do some processing, and then the lists are
compared using junctions.
I think (I might be wrong) that the conversion from a junction to a
list is specified by the .eigenstates method, but it doesn't seem to
completely flatten a junction yet - it produces the
any(any(4,14),any(14,24)) output shown above.
So my questions to the language list are:
a) Am I trying to fit a square peg in a round hole by applying
junctions to this sort of problem? If so, would it be possible to
explain what the limits are to the junction approach, or another way
of expressing this question: what sort of problems should junctions be
applied to?
b) Why would it be "wrong" to have a method for eliminating
eigenstates from a junction? (The answer to this might naturally arise
out of the answer to a). However, ...
In a wider context, I would conjecture that some algorithms to which
junctions could be applied would be optimised if some states could be
eliminated, a bit like tree-pruning optimisations that eliminate paths
which can never produce a correct answer. Consequently, providing a
filtering method would increase the usefulness of the junction as a
programming tool. Perhaps
$new-junction = $old-junction.grep({ $_ <= 21 }); # not sure if the
parens are needed here
c) On junction algebra, am I wrong or is always true that a junction
of the form
any('x','y','z', any('foo','bar'), 1, 2, 3) should collapse to
any('x','y','z','foo','bar',1,2,3)
In other words, if an 'any' junction is contained in an outer 'any',
the inner 'any' can be factored out?
This would eliminate the nested junctions produced by .eigenstates
d) Am I right in thinking this is also true for nested 'all'
junctions? viz.
all(1,2,3,all('foo', 'bar')) collapses to all(1,2,3,'foo','bar')
e) Conjecture: This true of all junction types, eg.,
junc(..., junc(...)) == junc(..., ...)
f) Would it be possible to have a means to coerce an 'any' junction
into an 'all' junction or vice versa? eg.
my $old-junction = 1|2|3; my $new-junction = all{$old-junction}; say
$old-junction.perl
# all(1,2,3)
Using () creates a new junction all(any(1,2,3))
{} are undefined for junctions.
If my suggestions prove acceptable, then for my problem I would have:
# @p & @d get defined as arrays of junctions, eg.
my @p=1|11,2,1|11;
my @d=1|11,3,1|11;
#later
my $p = ([+] @p).grep { $_ < 21 };
my $d = ([+] @d).grep { $_ < 21 };
if $p > all{$d} { say 'p wins' } else { say 'd wins' };
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the "value of the hand" is:
my $p = ([+] @p).map{.eigenstates}.grep{$_ < 21}.max;
which is exactly how I do it when I am playing Blackjack.
Put another way, the value of a blackjack hand is deterministic and
"sane", and you
Re: On Junctions
On Fri, Mar 27, 2009 at 10:39 AM, Dave Whipp wrote:
> Richard Hainsworth wrote:
>>
>> The following arose out of a discussion on #perl6. Junctions are new and
>> different from anything I have encountered, but I cant get rid of the
>> feeling that there needs to be some more flexibility in their use to make
>> them a common programming tool.
>
> I strongly agree with you, but Larry has repeatedly said that he wants to
> view Junctions as lexical sugar rather than as a powerful programming tool.
> So I'm thinking that we'll need to experiment with modules before anything
> gets admitted to the core language.
Maybe you could have something like a filter function that takes a
junction and a test condition and returns a junction of those
eigenstates from the original one that passed the test. You could
then handle the Blackjack problem by saying something to the effect
of:
$p = [+] @p;
$d = [+] @d;
if $p <= 21 { # Could the total be 21 or less?
$p where= { $_ <= 21 } #[ infix: filters the junction
according to the given criteria. ]
if $p > $d { say "you won!" }
} else { say "you went over." }
--
Jonathan "Dataweaver" Lang
Re: On Junctions
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
I strongly agree with you, but Larry has repeatedly said that he wants
to view Junctions as lexical sugar rather than as a powerful programming
tool. So I'm thinking that we'll need to experiment with modules before
anything gets admitted to the core language.
If my suggestions prove acceptable, then for my problem I would have:
# @p & @d get defined as arrays of junctions, eg.
my @p=1|11,2,1|11;
my @d=1|11,3,1|11;
#later
my $p = ([+] @p).grep { $_ < 21 };
my $d = ([+] @d).grep { $_ < 21 };
if $p > all{$d} { say 'p wins' } else { say 'd wins' };
I think that the all{..} notation is a little too subtle, and somewhat
clumsy (what if there are "one" or "none" junctions in $d? do you want
to splat them all?).
The way I'd view this (before optimization) is:
my $p = (reverse 1..21).first: { $_ == [+] @p };
my $d = (reverse 1..21).first: { $_ == [+] @d };
if! $p{ say "player bust" }
elsif ! $d{ say "dealer bust" }
elsif $p > $d { say "player wins" }
else { say "dealer wins" }
If this is the structure of the problem, the question then becomes how
to move from this brute force implementation to something more elegant
(analytical).
I discuss this on http://dave.whipp.name/sw/perl6/perl6_xmas_2008.html.
I've revised my ideas a little since then (by proposing a more general
grep metaoperator "G[op]" that has applicability beyond junctions) but
the basic concepts mesh with yours, I think.
Re: On Sets (Was: Re: On Junctions)
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed wrote:
> Given two
> junctions $d and $p, just adding $d + $p gives you all the possible
> sums of the eigenstates. Given two sets D and P, is there an equally
> simple op to generate { d + p : d ∈ D, p ∈ } ?
Dropped a P there - should be { d + p : d ∈ D, p ∈ P }
--
Mark J. Reed
Re: On Sets (Was: Re: On Junctions)
On Fri, Mar 27, 2009 at 10:27 AM, Moritz Lenz
wrote:
> Mark J. Reed wrote:
>> From a high-level perspective, the blackjack example seems perfect for
>> junctions. An Ace isn't a set of values - its one or the other at a
>> time. It seems to me if you can't make it work with junctions - f you
>> have to use sets instead - then there's something wrong with the
>> implementation of junctions.
>
> That seems as naiive as saying "regular expressions are for parsing
> text, and if you can't parse XML with regular expressions, there's
> something wrong with them" .
Well, I was being intentionally "naive". As I said, looking down from
above. In thinking about examples for explaining junctions, this one
seems a natural fit.
> Leaving aside that Perl 6 regexes do parse XML ;-)
So do Perl 5 ones - since they're not true formal regexes, but have
more power to e.g. match balanced tags. Plus of course you wouldn't
normally try to write one regex to match an XML document; there'd be
wrapper logic.
Now if you actually parse XML that way, you're being quite silly.
It's far from the best approach. But while maybe junctions aren't
the best approach to the Blackjack problem, either, it seems less
clear to me. Maybe that's just because I have less experience with
junctions.
> The answer is that an any() junction represents just what it says - a
> conjunction of *any*
> values,not some of the any values. The example would perfectly work if there
> was nothing to filter out. You'd need 'some-of-any' junction here, which
> we don't support.
So at the moment you have to explicitly extract the eigenstates you're
interested in, and then construct new junctions from them. Something
like this:
some($d) < 21 && some($p) < 21 && any(grep { $_ < 21 }
$d.eigenstates}) > all(grep { $_ < 21 } $p.eigenstates)
But it still seems that junctions let you do this more cleanly than
sets. Or maybe P6 Sets are more powerful than I think? Given two
junctions $d and $p, just adding $d + $p gives you all the possible
sums of the eigenstates. Given two sets D and P, is there an equally
simple op to generate { d + p : d ∈ D, p ∈ } ?
--
Mark J. Reed
Re: On Sets (Was: Re: On Junctions)
Mark J. Reed wrote: > From a high-level perspective, the blackjack example seems perfect for > junctions. An Ace isn't a set of values - its one or the other at a > time. It seems to me if you can't make it work with junctions - f you > have to use sets instead - then there's something wrong with the > implementation of junctions. That seems as naiive as saying "regular expressions are for parsing text, and if you can't parse XML with regular expressions, there's something wrong with them" . Leaving aside that Perl 6 regexes do parse XML ;-), we could ask ourselves why junctions aren't suited. The answer is that an any() junction represents just what it says - a conjunction of *any* values, not some of the any values. The example would perfectly work if there was nothing to filter out. You'd need 'some-of-any' junction here, which we don't support. Cheers, Moritz -- Moritz Lenz http://perlgeek.de/ | http://perl-6.de/ | http://sudokugarden.de/
Re: On Sets (Was: Re: On Junctions)
Em Sex, 2009-03-27 às 09:17 -0400, Mark J. Reed escreveu: > From a high-level perspective, the blackjack example seems perfect for > junctions. An Ace isn't a set of values - its one or the other at a > time. It seems to me if you can't make it work with junctions - f you > have to use sets instead - then there's something wrong with the > implementation of junctions. It would be a junction if the only question was "is it bigger than 21?"... but that is not the case, it looks more like... Given S as the set of possible sums, Given V as a subset of S where < 21 Given I as a subset of S where > 21 If V is empty, Define X as the minimum value of I Else, Define X as the maximum value in V Which really looks like set operations... daniel
Re: On Sets (Was: Re: On Junctions)
>From a high-level perspective, the blackjack example seems perfect for
junctions. An Ace isn't a set of values - its one or the other at a
time. It seems to me if you can't make it work with junctions - f you
have to use sets instead - then there's something wrong with the
implementation of junctions.
On 3/27/09, Daniel Ruoso wrote:
> Em Sex, 2009-03-27 às 08:57 -0300, Daniel Ruoso escreveu:
>> So I get that we do need some cool support for sets as well, I mean...
>> no collapsing, no autothreading... but maybe some specific behaviors...
>
> As an aditional idea...
>
> multi infix:<⋃>(Set $a, Set $b) {...}
> multi infix:<⋂>(Set $a, Set $b) {...}
> ...as well as the rest of the set theory...
>
> daniel
>
>
--
Sent from my mobile device
Mark J. Reed
Re: On Sets (Was: Re: On Junctions)
Em Sex, 2009-03-27 às 08:57 -0300, Daniel Ruoso escreveu:
> So I get that we do need some cool support for sets as well, I mean...
> no collapsing, no autothreading... but maybe some specific behaviors...
As an aditional idea...
multi infix:<⋃>(Set $a, Set $b) {...}
multi infix:<⋂>(Set $a, Set $b) {...}
...as well as the rest of the set theory...
daniel
On Sets (Was: Re: On Junctions)
Em Sex, 2009-03-27 às 13:36 +0300, Richard Hainsworth escreveu: > On #perl6, rouso, masak and moritz_ explained that I am incorrectly > thinking about junctions as sets and that for this task I should be > using another perl idiom, namely lists. Sorry for not taking each individual point on your mail, but I think this basically narrows down to the fact that we need some more definitions of what kinds of things we would do with sets. The thing is that junctions are so cool that people like to use it for more things than it's really usefull (overseeing that junctions are too much powerfull for that uses, meaning it will lead to unexpected behaviors at some point). So I get that we do need some cool support for sets as well, I mean... no collapsing, no autothreading... but maybe some specific behaviors... taking the blackjack example... # using the set function as illustration only... my @hand = set(1,11),3,set(1,11); my $sum = [+] @hand; This operation could use some magic so $sum could become set(5,15,25) Where it doesn't autothread, nor collapses... but it still provides the DWIMmery people like so much in junctions... So... which magic happened here? 1 - multi infix:<+>(Set $set, Num $a) This would return another set, with each value of $set summed with $a. 2 - multi infix:<+>(Set $a, Set $b) This would return another set, with $a.values X+ $b.values, already removing duplicated values, as expected from a set. So... what do you think? daniel
On Junctions
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
Background: Imagine a hand of cards. Cards may be Ace, Two, Three. Ace
having either the values 1 or 11, depending on context, the other cards
their face value. Sums of a hand over 21 are invalid.
Hands with multiple junctions become interesting, eg.,
p: Ace, Two, Ace
d: Ace, Three, Ace
Given that Ace has a value of 1 or 11 depending on context, it would
seem natural to use a junction. Hence the two hands can be expressed as:
@p = 1|11, 2, 1|11;
@d = 1|11, 3, 1|11;
If we use [+] to add these, we get
$p = [+] @p; say $p.perl; # any(any(4,14),any(14,24))
$d = [+] @d; say $d.perl; #any(any(5,15),any(15,25))
Since the values of 24 & 25 are greater than 21, they must be eliminated
from consideration.
What we want is for hand @d to beat hand @p because 15 > 14
On #perl6, rouso, masak and moritz_ explained that I am incorrectly
thinking about junctions as sets and that for this task I should be
using another perl idiom, namely lists. Something like:
moritz_ rakudo: ([1,11], 3, [1,11]).reduce({@($^a) X+ @($^b)})
p6eval rakudo bb22e0: RESULT«[5, 15, 15, 25]»
Then the out-of-limit values (in the above case 25) can be stripped off
using grep, viz.,
# here we have ([1,11],3,[1,11]) instead of (1|11, 3, 1|11)
my @dlist = grep { $_ < 21 } ([1,11], 3, [1,11]).reduce({@($^a) X+ @($^b)});
Then the two lists (do the same for @p) can be compared by a junction
comparison of the form
if any(@plist) > all(@dlist) { say 'p wins' };
The problem is not just that [+] @p produces a junction with undesired
(>21) eigenstates, but that the [+] @d produces a junction of the form
any(any(5,15),any(15,25)) which should collapse to any(5,15,25)
whereas we want a junction of the form
all(5,15,25)
After the #perl6 conversation, I thought some more. A junction is a neat
way of expressing the hand, but the junction needs to be converted to a
list to do some processing, and then the lists are compared using junctions.
I think (I might be wrong) that the conversion from a junction to a list
is specified by the .eigenstates method, but it doesn't seem to
completely flatten a junction yet - it produces the
any(any(4,14),any(14,24)) output shown above.
So my questions to the language list are:
a) Am I trying to fit a square peg in a round hole by applying junctions
to this sort of problem? If so, would it be possible to explain what the
limits are to the junction approach, or another way of expressing this
question: what sort of problems should junctions be applied to?
b) Why would it be "wrong" to have a method for eliminating eigenstates
from a junction? (The answer to this might naturally arise out of the
answer to a). However, ...
In a wider context, I would conjecture that some algorithms to which
junctions could be applied would be optimised if some states could be
eliminated, a bit like tree-pruning optimisations that eliminate paths
which can never produce a correct answer. Consequently, providing a
filtering method would increase the usefulness of the junction as a
programming tool. Perhaps
$new-junction = $old-junction.grep({ $_ <= 21 }); # not sure if the
parens are needed here
c) On junction algebra, am I wrong or is always true that a junction of
the form
any('x','y','z', any('foo','bar'), 1, 2, 3) should collapse to
any('x','y','z','foo','bar',1,2,3)
In other words, if an 'any' junction is contained in an outer 'any', the
inner 'any' can be factored out?
This would eliminate the nested junctions produced by .eigenstates
d) Am I right in thinking this is also true for nested 'all' junctions? viz.
all(1,2,3,all('foo', 'bar')) collapses to all(1,2,3,'foo','bar')
e) Conjecture: This true of all junction types, eg.,
junc(..., junc(...)) == junc(..., ...)
f) Would it be possible to have a means to coerce an 'any' junction into
an 'all' junction or vice versa? eg.
my $old-junction = 1|2|3; my $new-junction = all{$old-junction}; say
$old-junction.perl
# all(1,2,3)
Using () creates a new junction all(any(1,2,3))
{} are undefined for junctions.
If my suggestions prove acceptable, then for my problem I would have:
# @p & @d get defined as arrays of junctions, eg.
my @p=1|11,2,1|11;
my @d=1|11,3,1|11;
#later
my $p = ([+] @p).grep { $_ < 21 };
my $d = ([+] @d).grep { $_ < 21 };
if $p > all{$d} { say 'p wins' } else { say 'd wins' };
Richard (finanalyst)
Re: .perl and other methods on Junctions?
On Wed, Nov 05, 2008 at 11:28:00AM -0800, Larry Wall wrote: > But it seems to me that if stringification of a junction returns a > correct .perlish syntax, it's probably better to just let that happen > lazily, on the assumption someone might want .perl to autothread for > some reason, perhaps because .perl performs some kind of useful > canonicalization prior to comparison. > > So I think the actual choice is driven by the fact that Str(Junction) > is defined to work like you'd expect .perl to do if .perl did it, > which it doesn't... This all works for me, thanks for the clarification! Pm
Re: .perl and other methods on Junctions?
On Tue, Nov 04, 2008 at 01:33:09PM -0600, Patrick R. Michaud wrote: : Consider the code: : : my $x = 3 | 'foo'; : my $y = $x.perl; : : : Does $y end up as a junction of strings or as a single string? I think it may not actually matter much, if subsequent stringification of the junction produces a result with correct Perl syntax. : Asking more directly, does .perl autothread over a Junction? : If .perl does not autothread, then is there some way of knowing : which methods autothread and which do not? I think it would depend entirely on whether the Junction class defined method .perl, or relied on the authothreading implementation triggered by Object recognizing that it was handed a Junction. But it seems to me that if stringification of a junction returns a correct .perlish syntax, it's probably better to just let that happen lazily, on the assumption someone might want .perl to autothread for some reason, perhaps because .perl performs some kind of useful canonicalization prior to comparison. So I think the actual choice is driven by the fact that Str(Junction) is defined to work like you'd expect .perl to do if .perl did it, which it doesn't... : (The question of method autothreading over junctions came up at : the OSCON 2008 hackathon, but I don't know that it was ever : resolved. If it was and I've just forgotten or overlooked the : resolution, I'll be happy to have it pointed out to me.) Well, at the time we thought there might need to be some kind of VAR-like JUNCTION macro to give access to the Junction object, but if the decision is just based on whether Junction defines the method or not, that's not really necessary. And with this semantics, it's also no problem going the other way. If method .junk is defined in Junction, you can still force it to autothread by saying $junction.Object::junk(). Larry
.perl and other methods on Junctions?
Consider the code: my $x = 3 | 'foo'; my $y = $x.perl; Does $y end up as a junction of strings or as a single string? Asking more directly, does .perl autothread over a Junction? If .perl does not autothread, then is there some way of knowing which methods autothread and which do not? (The question of method autothreading over junctions came up at the OSCON 2008 hackathon, but I don't know that it was ever resolved. If it was and I've just forgotten or overlooked the resolution, I'll be happy to have it pointed out to me.) Thanks! Pm
