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.
Probab
On Mon, Nov 1, 2010 at 7:24 AM, Moritz Lenz 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
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 gat
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 d
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
ch
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 con
Martin D Kealey suggested:
> Well, I think returning or throwing an "Unordered" exception would be
> the appropriate way to handle those, both for complex numbers and for
> junctions.
For complex numbers that might be true, because the order relationship
between two complex numbers isn't expressi
On Thu, 28 Oct 2010, Damian Conway wrote:
> The apparent paradox ... is due to the assumption (employed in the
> second interpretation) that < is identical to !>=. Certainly that is
> true for simple scalar numbers, but not always for vector types such
> as tuples, sets, bags, complex numbers...or
Damian Conway wrote:
If it's about parallel data handling, then we have to be prepared to
(notionally) fork the entire rest of the runtime, even as far as
having a definition of what return value the parent process sees (from
"exit") when those threads are implicitly collapsed at termination.
T
Martin D Kealey asked:
> Or do we not invert junctions, and run the risk of unexpected
> action-at-a-distance instead?
I think our current approach is correct. That is: we "invert"
junctions on operators that are themselves intrinsically inverted
(such as !=, !~~, !<), but do not invert on those
I have to admit to feeling uneasy about the whole action-at-a-distance
effect that junctions are capable of producing. They sit around pretending
to be a scalar, only to pop up and wreak havoc with ones expectations of
linearity when you're not expecting it.
That unexpected-action-at-a-distance i
On 2010-Oct-25, at 15:14, Damian Conway wrote:
> Yes, Ted Z. pointed out to me that, as the name of this construct,
> "every" has ambiguity and synonym issues. Other possibilities are:
>
>select(@values) < one(3..7)
>those(@values) < one(3..7)
>whichever(@values) < one(3..7)
>ite
Jon Lang wrote:
> Personally, I don't think that it should be a public method: one thing
> about junctions is that you can use them interchangeably with ordinary
> scalars; giving them a public method breaks that. In particular, code
> that makes use of a Junction public method would break if you
First off, let me weigh in on Damian's original point: I agree that
Junction!eigenvalues should be renamed to more accurately reflect what
it is (perhaps to something like Junction!seedvalues, since what it's
really trying to produce is a list of the values that it's using to
define the Junction),
Damian Conway wrote:
Yes, Ted Z. pointed out to me that, as the name of this construct,
"every" has ambiguity and synonym issues. Other possibilities are:
select(@values) < one(3..7)
those(@values) < one(3..7)
whichever(@values) < one(3..7)
itemize(@values) < one(3..7)
extra
Dave Whipp noted:
> I think that the two proposals are equivalent, in the sense that either can
> be trivially implemented using the other.
Agreed.
> However, I am a little concerned that the transjunction "magically" changes
> an operator that returns a Boolean value into one that returns a li
Damian Conway wrote:
So I'm going to go on to propose that we create a fifth class of
Junction: the "transjunction", with corresponding keyword C.
[...]
say (^10 G[<] one(3,7));
3 4 5 6
which could also be:
say every(^10) < one(3,7);
# Every value up to 10 that's greater than 3 or
Ben Goldberg asked:
> I'm probably missing something, but wouldn't it have been easier to
> write that module by using eval STRING to create all of those infix
> operators?
Sure. But the module is already slow to start up. I was concerned
that it would get even slower with an embedded eval. But,
On Oct 22, 6:41 pm, dam...@conway.org (Damian Conway) wrote:
> Dave Whipp wrote:
> > When this issue has been raised in the past, the response has been that
> > junctions are not really intended to be useful outside of the narrow purpose
> > for which they were introduced.
>
> Hmm. There are in
> In general I like where this is going but need a little hand holding
> here- I'm not an expert on junctions or anything perl6-
>
>> So I'm going to go on to propose that we create a fifth class of
>> Junction: the "transjunction", with corresponding keyword C.
>
> It seems that by these definitio
In general I like where this is going but need a little hand holding
here- I'm not an expert on junctions or anything perl6-
> So I'm going to go on to propose that we create a fifth class of
> Junction: the "transjunction", with corresponding keyword C.
It seems that by these definitions "every"
Brandon mused:
> It occurs to me: If their purpose is that narrow, why are they wasting
> conceptual space in the core language?
Well, mainly because their purpose isn't narrow at all: it's parallelized data
comparisons (all(@values) < $threshold), and multiway comparisons
(all(@values) ~~ any(@
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/22/10 13:00 , Dave Whipp wrote:
> Damian Conway wrote:
>> I've been thinking about junctions, and I believe we may need a small
>> tweak to (at least) the jargon in one part of the specification.
>
> When this issue has been raised in the past,
Dave Whipp wrote:
> When this issue has been raised in the past, the response has been that
> junctions are not really intended to be useful outside of the narrow purpose
> for which they were introduced.
Hmm. There are intentions, and then there are intentions. I know
what I intended when I
Damian Conway wrote:
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
When this issue has been raised in the past, the response has been that
junctions are not really intended to be useful outside of the narr
I've been thinking about junctions, and I believe we may need a small
tweak to (at least) the jargon in one part of the specification.
Specificially, in S32-setting-library_Containers.pod, we currently have:
=item !eigenstates
method !eigenstates (Junction $j: --> Parcel)
Return
26 matches
Mail list logo
