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
