Re: [perl #62528] Match.keys method returns nothing.
Since afaict this is not specced, I'll hand that over to p6l.
Eric Hodges (via RT) wrote:
use v6;
rule test {test};
test ~~ /test/;
say '$/.keys = ', $/.keys.perl;
say '%($/).keys = ', %($/).keys.perl;
# outputs
# $/.keys = []
# %($/).keys = [test]
Same could be said for .values and .kv
It would be very DWIM for it to act like a hash in these cases by default.
Actually I think it would DWIM more in the general case if Match.keys
(and .kv, .pairs, .values etc) would give a list of the array and hash
part, so $/.keys would be @($/).keys, %($/).keys.
Your suggestion would be just a degenerate case of that.
Any thoughts on that?
Cheers,
Moritz
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)
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: Junction Algebra
Richard Hainsworth conjectured:
1) Is the following true for an any junction?
any( ... , any('foo','bar')) === any(...,'foo','bar')
If yes, then
if an 'any' junction is contained in an outer 'any', the inner 'any' can be
factored out?
Yes. More precisely, an 'any' that is directly nested inside another
'any' can be flattened.
By directly, I mean with no intervening levels of non-'any'
junctions. That is, not like: any(...,all(...,any('foo', 'bar')))
2) Also, is the following true for nested 'all' junctions? viz.
all(... , all('foo', 'bar')) === all(...,'foo','bar')
Yes, with a similiar directly caveat, as above.
3) Conjecture: The following is true of all junction types, eg.,
junc(..., junc(...)) === junc(..., ...)
No. As Patrick so ably pointed out, this is not true for 'one' nor for 'none'
Damian
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: [perl #62528] Match.keys method returns nothing.
Moritz Lenz wrote:
Since afaict this is not specced, I'll hand that over to p6l.
Eric Hodges (via RT) wrote:
use v6;
rule test {test};
test ~~ /test/;
say '$/.keys = ', $/.keys.perl;
say '%($/).keys = ', %($/).keys.perl;
# outputs
# $/.keys = []
# %($/).keys = [test]
Same could be said for .values and .kv
It would be very DWIM for it to act like a hash in these cases by default.
Actually I think it would DWIM more in the general case if Match.keys
(and .kv, .pairs, .values etc) would give a list of the array and hash
part, so $/.keys would be @($/).keys, %($/).keys.
Your suggestion would be just a degenerate case of that.
Any thoughts on that?
Take it one step more general: IIRC, Match returns a Capture of the
matches found. What happens if you apply .keys, .values, etc.
directly to a Capture object? I'm thinking that it should return a
multidimensional array: e.g., (@$capture; %$capture).«keys.
--
Jonathan Dataweaver Lang
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 = 12345
say suchthat($a, odd)
135
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
