[EMAIL PROTECTED] wrote:
What if junctions collapsed into junctions of the valid options under
some circumstances, so
my $x = any(1,2,3,4,5,6,7);
if(is_prime($x) # $x = any(2,3,5,7)
and is_even($x) # $x = any(2)
and $x > 2) # $x = any()
This is Just Wrong, IMO. How confusing is it going to be to f
[EMAIL PROTECTED] wrote:
Yes... but perhaps instead of the above transform we should just make
sure that < is transitive in the first place... so that no matter what
if a
Partial ordering relations are also transitive by definition.
Of course, you can overload '<' to be something other than orde
Matt Fowles wrote:
This is Just Wrong, IMO. How confusing is it going to be to find that
calling is_prime($x) modifies the value of $x despite it being a very
simple test operation which appears to have no side effects?
As far as I can see it, in the example, it's perfectly logical for
is_prime($x)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Luke
Palmer) wrote:
>Well, we see the same kind of thing with standard interval arithmetic:
>[...]
It didn't bother me that junctions weren't ordered transitively.
(Ordering had better work transitively for ordinary numbers, but
junctions aren'
All~
On Wed, 09 Feb 2005 22:48:00 +, Matthew Walton
<[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
> > All~
> >
> > On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]>
> > wrote:
> >
> >>[EMAIL PROTECTED] wrote:
> >>
> >>
> Well, we see the same kind of thing with s
Matt Fowles wrote:
All~
On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
Well, we see the same kind of thing with standard interval arithmetic:
(-1, 1) * (-1, 1) = (-1, 1)
(-1, 1) ** 2 = [0, 1)
The reason that junctions behave this way is
On 2005.02.08.19.07, Matt Fowles wrote:
| Brock~
|
|
| On Tue, 8 Feb 2005 12:08:45 -0700, Brock <[EMAIL PROTECTED]> wrote:
| >
| > Hm. I take that back... it was a silly comment to make and not very
| > mathematically sound. Sorry.
| >
| > --Brock
| >
| > - Forwarded message from Brock <[E
Cc: perl6-language@perl.org
Subject: Re: Junctive puzzles.
User-Agent: Mutt/1.5.6+20040907i
On 2005.02.05.20.33, Autrijus Tang wrote:
| (I've just finished the pretty printing part in Pugs, so I'll use actual
| command line transcripts below. The leading "?" does not denote boole
Brock~
On Tue, 8 Feb 2005 12:08:45 -0700, Brock <[EMAIL PROTECTED]> wrote:
>
> Hm. I take that back... it was a silly comment to make and not very
> mathematically sound. Sorry.
>
> --Brock
>
> - Forwarded message from Brock <[EMAIL PROTECTED]> -
>
> (a < b < c) ==> (a
On 2005.02.05.20.33, Autrijus Tang wrote:
| (I've just finished the pretty printing part in Pugs, so I'll use actual
| command line transcripts below. The leading "?" does not denote boolean
| context -- it's just telling pugs to do a big-step evaluation. Also,
| boolean literals are written in t
All~
On Tue, 08 Feb 2005 17:51:24 +0100, Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> >>Well, we see the same kind of thing with standard interval arithmetic:
> >>
> >>(-1, 1) * (-1, 1) = (-1, 1)
> >>(-1, 1) ** 2 = [0, 1)
> >>
> >>The reason that junctions be
[EMAIL PROTECTED] wrote:
Well, we see the same kind of thing with standard interval arithmetic:
(-1, 1) * (-1, 1) = (-1, 1)
(-1, 1) ** 2 = [0, 1)
The reason that junctions behave this way is because they don't
collapse. You'll note the same semantics don't arise in
Quantum::Entanglement (whe
Luke Palmer writes:
> Miroslav Silovic writes:
> > [EMAIL PROTECTED] wrote:
> > >So Pugs will evaluate that to (#f|#f), by lifting all junctions
> > >out of a multiway comparison, and treat the comparison itself as
> > >a single variadic operator that is evaluated as a chain individually.
> >
> > I
Miroslav Silovic writes:
> [EMAIL PROTECTED] wrote:
> >So Pugs will evaluate that to (#f|#f), by lifting all junctions
> >out of a multiway comparison, and treat the comparison itself as
> >a single variadic operator that is evaluated as a chain individually.
>
> I think this is correct, however...
[EMAIL PROTECTED] wrote:
Yup. My mathematic intuition cannot suffer that:
4 < X < 2
to be true in any circumstances -- as it violates associativity.
If one wants to violate associativity, one should presumably *not*
use the chained comparison notation!
So Pugs will evaluate that to (#f|#f), by
On Tue, Feb 08, 2005 at 11:12:40AM +0800, Autrijus Tang wrote:
: This way, both associativity and junctive dimensionality holds, so
: I think it's the way to go. Please correct me if you see serious
: flaws with this approach.
Feels right to me.
Larry
On Tue, 8 Feb 2005 11:12:40 +0800, Autrijus Tang <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 07, 2005 at 05:33:06PM +0100, Miroslav Silovic wrote:
> > my $a = (0 | 6);
> > say 4 < $a and $a < 2;
>
> Yup. My mathematic intuition cannot suffer that:
>
> 4 < X < 2
>
> to be true in any circumstan
On Mon, Feb 07, 2005 at 05:33:06PM +0100, Miroslav Silovic wrote:
> my $a = (0 | 6);
> say 4 < $a and $a < 2;
Yup. My mathematic intuition cannot suffer that:
4 < X < 2
to be true in any circumstances -- as it violates associativity.
If one wants to violate associativity, one should presuma
[EMAIL PROTECTED] wrote:
pugs> ? 4 < (0 | 6) < 2
(#t|#f)
Here's my take on it.
Compare
my $a = (0 | 6);
say 4 < $a and $a < 2;
vs
say 4 < (0 | 6) and (0 | 6) < 2;
The difference is that in the first case the junction refers to the same
object, and the result should probably be expanded on
> "NC" == Nicholas Clark <[EMAIL PROTECTED]> writes:
NC> If junctions are sets, and so a|b is identical to b|a, then isn't
NC> it wrong for any implementation of junctions to use any
NC> short-circuiting logic in its implementation, because if it did,
NC> then any active data (such as
On Sat, Feb 05, 2005 at 06:35:55PM +, Nicholas Clark wrote:
> If junctions are sets, and so a|b is identical to b|a, then isn't it wrong
> for any implementation of junctions to use any short-circuiting logic in
> its implementation, because if it did, then any active data (such as tied
> thing
On Sun, Feb 06, 2005 at 02:30:21AM +0800, Autrijus Tang wrote:
> On Sat, Feb 05, 2005 at 02:39:26PM +, Nicholas Clark wrote:
> > On Sat, Feb 05, 2005 at 10:04:02PM +0800, Autrijus Tang wrote:
> > > On Sat, Feb 05, 2005 at 01:52:05PM +, Nicholas Clark wrote:
> > > > > #t and
On Sat, Feb 05, 2005 at 02:39:26PM +, Nicholas Clark wrote:
> On Sat, Feb 05, 2005 at 10:04:02PM +0800, Autrijus Tang wrote:
> > On Sat, Feb 05, 2005 at 01:52:05PM +, Nicholas Clark wrote:
> > > > #t and (0 | 6) < 2 # reduction in boolean
> > > > context(!)
> > >
> >
On Sat, Feb 05, 2005 at 10:04:02PM +0800, Autrijus Tang wrote:
> On Sat, Feb 05, 2005 at 01:52:05PM +, Nicholas Clark wrote:
> > > #t and (0 | 6) < 2 # reduction in boolean context(!)
> >
> > Why is it allowed to do this?
>
> Because "and" forces boolean context to determ
On Sat, Feb 05, 2005 at 01:52:05PM +, Nicholas Clark wrote:
> > #t and (0 | 6) < 2 # reduction in boolean context(!)
>
> Why is it allowed to do this?
Because "and" forces boolean context to determine whether it
short-circuits or not. However, I should've make it clear t
On Sat, Feb 05, 2005 at 08:43:10PM +0800, Autrijus Tang wrote:
> On Sat, Feb 05, 2005 at 12:38:57PM +, Nicholas Clark wrote:
> > Surely you can do better than that for counterintuitive? :-)
> >
> > 4 < (0 | 6) < 2
>
> pugs> ? 4 < (0 | 6) < 2
> (#t|#f)
>
> Why is it so? Because:
>
>
On Sat, Feb 05, 2005 at 12:38:57PM +, Nicholas Clark wrote:
> Surely you can do better than that for counterintuitive? :-)
>
> 4 < (0 | 6) < 2
pugs> ? 4 < (0 | 6) < 2
(#t|#f)
Why is it so? Because:
4 < (0 | 6) and (0 | 6) < 2
(4 < 0 | 4 < 6) and (0 | 6) < 2 # local
On Sat, Feb 05, 2005 at 08:33:25PM +0800, Autrijus Tang wrote:
> With the note that "b" must be evaluated at most once. However, if
> taken literally, it gives this rather weird result:
>
> pugs> ? 2 < (0 | 3) < 4
> (#t|#t)
Surely you can do better than that for counterintuitive? :-)
4
28 matches
Mail list logo
