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 Sets (Was: Re: On Junctions)
On Sun, Mar 29, 2009 at 1:18 PM, John Macdonald j...@perlwolf.com 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:where (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)
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 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 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 Sets (Was: Re: On Junctions)
On Sat, Mar 28, 2009 at 6:39 AM, Daniel Ruoso dan...@ruoso.com 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 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)
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)
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
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
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
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 dan...@ruoso.com 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 markjr...@gmail.com
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)
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)
On Fri, Mar 27, 2009 at 10:27 AM, Moritz Lenz
ml...@physik.uni-wuerzburg.de 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 markjr...@gmail.com
Re: On Sets (Was: Re: On Junctions)
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed markjr...@gmail.com 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 markjr...@gmail.com
