On Sat, Mar 28, 2009 at 10:19:31AM -0500, Patrick R. Michaud wrote:
> On Sat, Mar 28, 2009 at 02:08:22PM +0300, Richard Hainsworth wrote:
> > 3) Conjecture: The following is true of all junction types, eg.,
> > junc(..., junc(...)) === junc(..., ...)
>
> The conjecture is false for one/none juncti
On Sat, Mar 28, 2009 at 1:48 AM, Timothy S. Nelson wrote:
>Perl 6 has a general language (grammars) for taking some input and a
> grammar, and separating the data from the formatting, as it were.
>
>Ideally, it'd be possible to specify one grammar that would act both
> for parsing
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 02:08:22PM +0300, Richard Hainsworth wrote:
> 3) Conjecture: The following is true of all junction types, eg.,
> junc(..., junc(...)) === junc(..., ...)
The conjecture is false for one/none junctions:
one(0, one(1, 1)) # true
one(0, 1, 1) # fal
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
Included in my 'On junctions' message were some questions that have not
been directly answered. I simplify and expand them here.
Here I use === to mean 'is the same as'.
(I am not sure which of == or === should be used.)
1) Is the following true for an any junction?
any( ... , any('foo','bar'))
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
16 matches
Mail list logo
