Nathan Wiger wrote:
> what people would want to use the ops for, and it's also more usable to
> us non-PDLers.
I'd like to suggest that it is not a very good idea to start dividing
the world into PDLers and non-PDLers. There are a multitude of reasons
but I am not keen to go into details.
Chr
Doug Hunt wrote:
> You might also look at APL, a language which has been doing really funky
> N-dimensional
> array manipulation for longer than anyone...
I'd say PDL has probably been influenced quite strongly by APL/J in its
PDL threading notion. And with more and more "funny characters" makin
> "NT" == Nathan Torkington <[EMAIL PROTECTED]> writes:
NT> Actually, the only refinement I'd like to see is that boolean operators
NT> (==, &&, ||) be excepted from the distributive rule.
NT> This is to permit:
NT> if (@a == @b) # shallow comparison
NT> and
NT> @a = @b ||
Doug Hunt wrote:
> Jeremy Howard wrote:
>
> > - Mathematica (combines functional, declarative, and procedural styles;
> > implements memoization, lazy lists, and array notation)
> > - Matlab (fast and simple array language)
> > - C++ expression templates such as POOMA and Blitz++ (implicit loop
Jeremy Howard wrote:
> - Mathematica (combines functional, declarative, and procedural styles;
> implements memoization, lazy lists, and array notation)
> - Matlab (fast and simple array language)
> - C++ expression templates such as POOMA and Blitz++ (implicit looping and
> generalised slicin
Jeremy Howard writes:
> > @a = @b || @c; # @a=@b or @a=@c; # ish
> Doesn't work in P5 (try it!)
I know it doesn't, and I'm saying (yet again) that I'd like it to work
in perl6.
Nat
Nathan Torkington wrote:
> Jeremy Howard writes:
> > No, there's no arbitrary decision. *Every* operator is component wise on
> > lists. It is internally consistent, and consistent with most other
languages
> > that provide array/list operators. It's easy to get stuck on the '*'
> > example, becau
Nathan Wiger wrote:
> My main fear is that while this RFC seems really good for math ops, but
> seems too array- and PDL-specific. Here are some examples of mixed
> contexts; how would these be handled under the RFC?
>
> @user_data = @empty || $user;
> %files = scalar(get_files()) || @DEFA
Nathan Wiger wrote:
> The only thing that *really* makes me nervous about the RFC is this
> part:
>
> > > @d = @b * @c; # Returns (2,8,18)
> > >
> > > If the lists are not of equal length, an error is raised.
>
> I really don't like the "error is raised" part, at least not by default.
> Maybe
Nathan Torkington wrote:
>
> Actually, the only refinement I'd like to see is that boolean operators
> (==, &&, ||) be excepted from the distributive rule.
>
> This is to permit:
>
> if (@a == @b) # shallow comparison
>
> and
>
> @a = @b || @c;# @a=@b or @a=@c; # ish
[EMAIL PROTECTED] wrote:
>
> I disagree. You end up with a situation where some
>
>@a * @b;
>
> are in scalar context, some not.
No, everything would be in a scalar context. If you used tie() to
specially tie a variable, then you might be able to overload +, *, -,
etc, but this is no diffe
Jeremy Howard writes:
> No, there's no arbitrary decision. *Every* operator is component wise on
> lists. It is internally consistent, and consistent with most other languages
> that provide array/list operators. It's easy to get stuck on the '*'
> example, because different mathematicians have di
Jeremy Howard wrote:
>
> Not only do you lose consistency here (as Christian already pointed out),
> but also speed. Array functions and operations would be tightly optimised
> loops, and furthermore multiple operations would avoid redundant loops and
> copies. Good luck finding a way of getting
[EMAIL PROTECTED]
> Nathan Wiger wrote:
> >
> > > This RFC proposes that operators in a list context should be applied
> > > element-wise to the elements of their arguments:
> > >
> > > @d = @b * @c; # Returns (2,8,18)
> > >
> > > If the lists are not of equal length, an error is raised.
> >
>
Nathan Wiger wrote:
>
> > This RFC proposes that operators in a list context should be applied
> > element-wise to the elements of their arguments:
> >
> > @d = @b * @c; # Returns (2,8,18)
> >
> > If the lists are not of equal length, an error is raised.
>
> I've been watching this RFC for a
> This RFC proposes that operators in a list context should be applied
> element-wise to the elements of their arguments:
>
> @d = @b * @c; # Returns (2,8,18)
>
> If the lists are not of equal length, an error is raised.
I've been watching this RFC for a while. I would hesitate to change th
16 matches
Mail list logo
