On Sun, Mar 29, 2009 at 10:57 PM, Mark Lentczner wrote:
> 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.
In my case, this tendency comes more from a desir
Em Dom, 2009-03-29 às 22:57 -0700, Mark Lentczner escreveu:
> 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(
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
On Sun, Mar 29, 2009 at 1:18 PM, John Macdonald 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 j
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
> col
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 .eig
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
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
Thomas Sandlaß wrote:
> Set operations are with parens.
Which Synopsis is this in?
--
Jonathan "Dataweaver" Lang
On Sat, Mar 28, 2009 at 6:39 AM, Daniel Ruoso 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
>>
Patrick R. Michaud wrote:
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
I believe that there are hands where $p = 15|26 which would not beat a
hand where $d = 17.
I believe that the correct way to calculate the "value of the hand" is:
my $p = ([+] @p).map{.eigenstate
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:<+> sho
Daniel Ruoso wrote:
> But the semantics of sets are still somewhat blurry... there are some
> possibilities:
>
> 1) Sets are in the same level as junctions, but have no collapsing and
> allow you to get its values. The problem is if it autothreads on
> method calls or not... It also makes
On Fri, Mar 27, 2009 at 05:49:02PM -0400, Henry Baragar wrote:
> I believe that there are hands where $p = 15|26 which would not beat a
> hand where $d = 17.
>
> I believe that the correct way to calculate the "value of the hand" is:
>
>my $p = ([+] @p).map{.eigenstates}.grep{$_ < 21}.max;
S
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 unex
Em Sáb, 2009-03-28 às 16:17 +1100, Damian Conway escreveu:
> Nested heterogeneous junctions are extremely useful. For example, the
> common factors of two numbers ($x and $y) are the eigenstates of:
> all( any( factors($x) ), any( factors($y) ) )
I think that's the exact case where we should b
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 jun
> 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.
Yes, that's a concern. Most of the interesting junction-based algorithms
I've developed in the past rely on two facilities: the ability t
Damian Conway wrote:
> Jon Lang wrote:
>
>> For that matter, I'm not seeing a difference between:
>>
>> any( 1&2 ) # any of all of (1, 2)
>>
>> ...and:
>>
>> any( 1, 2 ) # any of (1, 2)
>
> Those two are very different.
>
> any(1,2) == 2 is true
>
> any(1&2) == 2 is false
>
>
> Nest
Jon Lang wrote:
> For that matter, I'm not seeing a difference between:
>
>any( 1&2 ) # any of all of (1, 2)
>
> ...and:
>
>any( 1, 2 ) # any of (1, 2)
Those two are very different.
any(1,2) == 2 is true
any(1&2) == 2 is false
Nested heterogeneous junctions are extremely u
Dave Whipp wrote:
> [I’d been planning to put this suggestion on hold until the spec is
> sufficiently complete for me to attempt to implement it as a module. But
> people are discussing this again, so maybe it's not just me. I apologize if
> I appear to be beating a dead horse...]
>
> Jon Lang wro
[I’d been planning to put this suggestion on hold until the spec is
sufficiently complete for me to attempt to implement it as a module. But
people are discussing this again, so maybe it's not just me. I apologize
if I appear to be beating a dead horse...]
Jon Lang wrote:
Maybe you could hav
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new
and different from anything I have encountered, but I cant get rid of
the feeling that there needs to be some more flexibility in their use
to make them a common programming tool.
Background: Imag
On Fri, Mar 27, 2009 at 10:39 AM, Dave Whipp wrote:
> Richard Hainsworth wrote:
>>
>> The following arose out of a discussion on #perl6. Junctions are new and
>> different from anything I have encountered, but I cant get rid of the
>> feeling that there needs to be some more flexibility in their u
Richard Hainsworth wrote:
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
I strongly agree w
On Fri, Mar 27, 2009 at 11:45 AM, Mark J. Reed 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 :
On Fri, Mar 27, 2009 at 10:27 AM, Moritz Lenz
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
>>
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
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 inste
>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 junc
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
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
32 matches
Mail list logo
