Re: Tweaking junctions
On 10/22/2010 06:16 AM, Damian Conway wrote: That is, a C$value is an eigenstate of a C$junction if-and-only-if: $value !~~ Junction$value ~~ $junction In general this definition makes it impossible to return a list of eigenstates from the junction. Just think of junctions containing Code objects. Or anything more complicated than the built-in value types. But the C!eigenstates method (as currently defined) does not return a list of such eigenstates. Instead it merely returns a partially-flattened list of the raw internal values of the junction...which is not (usually) the same thing at all. Right; but afaict it's the only thing that can actually be implemented. And because it doesn't make all too much sense, it's specced to be private.
Re: Tweaking junctions
Moritz wrote: $value !~~ Junction $value ~~ $junction In general this definition makes it impossible to return a list of eigenstates from the junction. Just think of junctions containing Code objects. Well, that's a deficiency in smartmatching: that Callable ~~ Code doesn't check for identity between the two objects. Likewise the Regex ~~ Regex doesn't check for identity. Likewise Range ~~ Range testing for identical endpoints. Etc. ;-) The definition of eigenvalues() is supposed to be abstractly descriptive, not specifically constructive. The idea is simply: any leaf state inside the junction to which the junction could collapse. Now the implementation I already provided does currently rely on smartmatching, but that will be fixed pronto, now that you've kindly pointed out that smartmatching is...well...broken on several interesting types of states. :-) Right; but afaict it's the only thing that can actually be implemented. And because it doesn't make all too much sense, it's specced to be private. Fine. But please change the name anyway. If we all agree it's not returning eigenstates, and some of us believe it *can't* every return eigenstates, then it certainly shouldn't be called C.eigenstates. Damian
Re: Tweaking junctions
On 11/01/2010 12:41 PM, Damian Conway wrote: Moritz wrote: $value !~~ Junction$value ~~ $junction In general this definition makes it impossible to return a list of eigenstates from the junction. Just think of junctions containing Code objects. Well, that's a deficiency in smartmatching: that Callable ~~ Code doesn't check for identity between the two objects. Likewise the Regex ~~ Regex doesn't check for identity. Likewise Range ~~ Range testing for identical endpoints. Etc. ;-) Sorry, I disagree. It's exactly what smartmatching was designed to be. If you don't want that kind of behaviour, use infix:eqv or infix:=== instead. The definition of eigenvalues() is supposed to be abstractly descriptive, not specifically constructive. The idea is simply: any leaf state inside the junction to which the junction could collapse. Junctions only collapse to Bool::True or Bool::False. So an attempt to fix your definition could be 'any leaf state inside the junction, which makes the junction collapse to True if compared to the junction as a whole' but begs for a more concrete comparison rule. For which, IMHO smartmatching would be nice, since I mostly use junctions for smartmatching. Which brings us into the dilemma I mentioned before. Right; but afaict it's the only thing that can actually be implemented. And because it doesn't make all too much sense, it's specced to be private. Fine. But please change the name anyway. If we all agree it's not returning eigenstates, and some of us believe it *can't* every return eigenstates, then it certainly shouldn't be called C.eigenstates. Agreed. Cheers, Moritz
Re: Tweaking junctions
Food for thought, a few non-junction solutions:
On 10/22/2010 06:16 AM, Damian Conway wrote:
# Find the list of common elements in two lists...
sub intersection (@list1, @list2) {
(any(@list1) any(@list2).eigenstates;
}
sub intersection(@list1, @list2) {
uniq gather for @list1 X @list2 - $a, $b {
take $a if $a eqv $b
}
}
or
sub interseection(@list1, @list2) {
(@list1 X= @list2).grep({ .key eqv .value}).key.uniq
}
Admittedly it's not as declarative, but it's explicit about the
comparison used (which is a plus, in my eyes).
If you want to use eq or ===, hash based solutions come to mind too.
# Find the factors of a number...
sub factors (Num $n) {
( $n/any(1..$n) ).eigenstates.grep({ $^q.Int == $q });
}
sub factors($n) {
($n X/ 1..$n).grep: { .Int == $_ }
}
or
sub factors($n) {
(1..$n).grep: { %n %% $_ }
}
# Check for an unacceptable password, and list all when warning...
constant UNACCEPTABLE = any Godel Escher Bart etc... ;
if $passwd ~~ UNACCEPTABLE {
say Unacceptable password. Don't use any of these:;
say UNACCEPTABLE.eigenstates¬».fmt(\t%s\n);
}
constant UNACCETABLE = Godel Escher Bach;
if $passwd ~~ any UNCACCEPTABLE {
say Unacceptable password. Don't use any of these:;
say UNACCEPTABLE».fmt(\t%s\n);
}
Re: Tweaking junctions
On Mon, Nov 1, 2010 at 7:24 AM, Moritz Lenz mor...@faui2k3.org wrote: On 10/22/2010 06:16 AM, Damian Conway wrote: That is, a C$value is an eigenstate of a C$junction if-and-only-if: $value !~~ Junction $value ~~ $junction In general this definition makes it impossible to return a list of eigenstates from the junction. Just think of junctions containing Code objects. Or anything more complicated than the built-in value types. [Originally sent to Moritz alone because of Reply not sending to the list] Is it too late in this discussion to point out that, in non-perl usage, eigenstates are associated with the operator, not with the value fed into the operator? [Added at Moritz request] In linear algebra, eigenvectors and eigenvalues are non-trivial solutions to the equation Ax=λx, where x is a vector in a vector space, A is a operator (a function from a vector space to itself) and λ is a member of the field the vector space is defined over. For a given operator A, only certain values of λ allow that equation to be solved, and those values are called the eigenvalues for A. Also, for a given operator A, only certain vectors x will solve the equation, and those vectors are called eigenvectors. It should also be clear that different values of λ work with different sets of vectors x (the solutions to Ax = ax and Ax=bx are different if a != b), so it's typical to talk about the eigenvectors of A associated with a given eigenvalue λ. Since A is linear, if Ax=λx and Ay=λy, then A(ax) = a(Ax) = a(λx) = λ(ax) and A(x+y)=Ax+Ay=λx+λy=λ(x+y), so fir a given eigenvalue λ, there are typically multitudes of eigenvectors which form a vector space of their own. Eigenvectors for different eigenvalues are orthogonal, and any eigenvector can be scaled to be a unit eigenvector. If an operator has a full set of eigenvalues, one can pick a set of unit eigenvectors to act as a natural orthonormal basis for the operator. If operator A has three eigenvalues a, b, c, and three unit eigenvectors x, y, z, such that Ax=ax, Ay=by, and Az=cz, then if w = dx+ey+fz, Aw = a(dx)+b(ey)+c(fz), which is really easy to compute. In quantum mechanics, especially the Heisenberg matrix formulation (but by analogy, also every other formulation, including wave mechanics), quantum states are represented by vectors in a complex vector space, and vectors which differ by a real-valued scaling factor are generally considered equivalent. Transformations (i.e., anything which modifies the quantum state of the system, including but not limited to the passage of time) are represented by (unitary) operators on the state space. (Unitary in this case means that the norm of Ax is the same as the norm of x, for all x.) The standard notation is a bit odd, where the 'ket' |x represents a system in state x (and therefore |x+y a state in a superposition of x and y), The 'bra' x| is the complement of the ket |x, and can be multiplied by a ket to get a braket x|y which represents the probability that a system in state y is also in state x. |x is, naturally, usually normalized such that x|x = 1. Operators act on kets and return kets, so A|x is the braket notation way of writing the linear algebra Ax. Naturally, that means that y|A|x is the probability that a system that starts in state x will be in state y after the transform A. Since A is a linear operator, it has eigenvalues and eigenvectors. In the quantum mechanical world, where vectors represent states, the eigenvectors are called eigenstates. Eigenstates |i, |j of an operator A have the property that i|A|i = j|A|j = 1, but i|A|j = 0 (informally, if you start in an eigenstate of A, then the transform leaves you unchanged). However, A|i+j = |ai+bj, so A can change the nature of a superposition of states. i|i+j = 1/2, j|i+j = 1/2, but i|A|i+j = a/(a+b), j|A|i+j = b/(a+b). Schrodinger's Wave Equation, in matrix notation, is of the form Hx=Ex, where H is the Hamiltonian operator of the system, and E is the energy of the system, so the only allowed solutions of the wave equations are for energy levels E which are eigenvalues of H,and for quantum states which are eigenstates of H. Similar equations exist for virtually every observable, so the only allowable momenta are the eigenvalues or eigenstates of the momentum operator, the only allowable positions are the eigenvalues or eigenstates of the position operator, etc. So asking for the eigenstates of a quantum superposition is asking the wrong object for the property.
Re: Tweaking junctions
Buddha Buck wrote: Is it too late in this discussion to point out that, in non-perl usage, eigenstates are associated with the operator, not with the value fed into the operator? [cut] So asking for the eigenstates of a quantum superposition is asking the wrong object for the property. Probably is, yes :(. I argued the same thing a couple of years back (http://dave.whipp.name/sw/perl6/perl6_xmas_2008.html -- wow, p6/rakudo has advanced a lot since then!) when I suggested bra-ket notation for extracting the values of a junction: $player_value = max | 4..21 |==| $player_value_junc | (in this case, the value of a blackjack hand). Since then, I simplified this idea to use a more perl6ish meta-operator: $player_value = max 4..21 G== $player_value_junc My current belief is that it is likely that there'll eventually be sufficient core functionality that I'll be able to implement something like this as a module. So I don't push it except when someone else starts a thread about the values of a junction :). Dave.
