On Thu, Nov 17, 2005 at 10:18:19PM +0100, TSa wrote:
: Another idea is to model nums to have a directional bit where the
: polar complex have a full range angle.
This whole thing strikes me as a "units" problem. Much like we
don't care if the internal representation is meters or furlongs,
so long
On Fri, Nov 18, 2005 at 06:54:42PM -0200, Flavio S. Glock wrote:
: 2005/11/11, Larry Wall <[EMAIL PROTECTED]>:
: >
: > While you're there, also think about the gray area between arrays and
hashes,
: > and whether .[...] subscripts are just a specialized form of .{...}
subscripts.
:
: By the way,
2005/11/11, Larry Wall <[EMAIL PROTECTED]>:
>
> While you're there, also think about the gray area between arrays and hashes,
> and whether .[...] subscripts are just a specialized form of .{...}
> subscripts.
By the way, are lazy hash slices allowed?
%h{1...}
I asked this in #perl6 when I wa
HaloO,
Jonathan Lang wrote:
Complex numbers come in two representations: rectilinear coordinates
and polar coordinates:
I think there's also the Riemanian two angle form of the complex
number sphere with r = 0.5 around (0,0,0.5) touching the plane at
the origin (0,0) and reaching up to (0,0,1)
Jonathan Lang wrote:
In the hypothetical module that I'm describing, the principle value
approach _would_ be used - in scalar context. The only time the "list
of all possible results" approach would be used would be if you use
list context. If you have no need of the list feature, then you don
Doug McNutt wrote:
> As for complex operations which have multiple results I think a principle
> value approach makes more sense than a list. It's well established for the
> inverse trigonometric functions. Leave RootOf( ) to Maple and Mathematica.
In the hypothetical module that I'm describing, t
At 15:59 +0100 11/14/05, Michele Dondi wrote:
>I must say that I didn't follow the discussion (complex) very much. But this
>makes me think of this too: the two representations are handy for different
>calculations. It would be nice if they somehow declared what they can do
>better (or at all) a
On Fri, 11 Nov 2005, Jonathan Lang wrote:
That wasn't the intent; the intent was to define a
"something-or-other" C that represents the fact that whatever
does this sometimes behaves like a complexRectilinear and other times
behaves like a complexPolar. Even the underlying information (the
attr
Luke Palmer wrote:
> Just some initial thoughts and syntax issues. I'll come back to it on
> the conceptual side a little later.
I'm looking forward to it.
> Jonathan Lang wrote:
> > method coerce:complexPolar () returns complexPolar {
> > return new complexPolar ($.x * $.x + $.y * $.y, at
On Fri, Nov 11, 2005 at 06:21:53AM +, Luke Palmer wrote:
: Just some initial thoughts and syntax issues. I'll come back to it on
: the conceptual side a little later.
:
: On 11/10/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
: >
: > class complexRectilinear {
: > has $.x, $.y;
:
: Hmm, tha
Just some initial thoughts and syntax issues. I'll come back to it on
the conceptual side a little later.
On 11/10/05, Jonathan Lang <[EMAIL PROTECTED]> wrote:
>
> class complexRectilinear {
> has $.x, $.y;
Hmm, that might need to be
has ($.x, $.y);
However, inlining "has"s isn't possibl
The following is an attempt to put a number of Perl6 concepts into
practice, in order to see how useful and intuitive they actually are.
Complex numbers come in two representations: rectilinear coordinates
and polar coordinates:
class complexRectilinear {
has $.x, $.y;
method infix:+ ($a is c
12 matches
Mail list logo