Re: Complex Arithmetic

2005-05-20 Thread Edward Cherlin
On Thursday 19 May 2005 09:39, Luke Palmer wrote:
 On 5/19/05, Edward Cherlin [EMAIL PROTECTED] wrote:
  It turns out that the domain and range and the location of
  the cut lines have to be worked out separately for different
  functions. Mathematical practice is not entirely consistent
  in making these decisions, but in programming, there seems
  to be widespread agreement that the shared definitions used
  in the APL, Common LISP, and Ada standards are the best
  available.
 
  Do we want to get into all of this in Perl6?

 I'm not really sure I know what you mean by do we want to get
 into all of this?.  If we're going to have a Complex class,
 we have to. But getting into it might involve saying that
 APL, CL, and Ada are the best, so we use those.  This is the
 kind of problem where, if someone wants to get more precise,
 they turn to CPAN.

 Luke

 Math::Complex - complex numbers and associated mathematical 
functions
http://cpan.uwinnipeg.ca/htdocs/perl/Math/Complex.html

lists the complex functions, but with no information given 
there on domain, range (principal values), and branch cuts. 

The APL standard costs $350 from ANSI or 260 Swiss Francs from 
ISO, but the Common Lisp Hyperspec is available online for free.
http://www.lispworks.com/documentation/HyperSpec/
as is the Ada Reference Manual. The CL and Ada definitions are 
incomplete. I'll have to find a copy of the APL standard.

log(z) 
CL Hyperspec: The branch cut for the logarithm function of one 
argument (natural logarithm) lies along the negative real axis, 
continuous with quadrant II. The domain excludes the origin.
Thus the range would be defined as -pi  Im(log(z)) = pi

sin(z)
CL Hyperspec: Not defined for complex arguments.

Ada RF says:
The functions have their usual mathematical meanings. 
However, the arbitrariness inherent in the placement of branch 
cuts, across which some of the complex elementary functions 
exhibit discontinuities, is eliminated by the following 
conventions: 
(13)

* The imaginary component of the result of the Sqrt and 
Log functions is discontinuous as the parameter X crosses the 
negative real axis. 

(14)

* The result of the exponentiation operator when the left 
operand is of complex type is discontinuous as that operand 
crosses the negative real axis. 

(15)

* The real (resp., imaginary) component of the result of 
the Arcsin and Arccos (resp., Arctanh) functions is 
discontinuous as the parameter X crosses the real axis to the 
left of -1.0 or the right of 1.0. 

(16)

* The real (resp., imaginary) component of the result of 
the Arctan (resp., Arcsinh) function is discontinuous as the 
parameter X crosses the imaginary axis below -i or above i. 

(17)

* The real component of the result of the Arccot function 
is discontinuous as the parameter X crosses the imaginary axis 
between -i and i. 

(18)

* The imaginary component of the Arccosh function is 
discontinuous as the parameter X crosses the real axis to the 
left of 1.0. 

(19)

* The imaginary component of the result of the Arccoth 
function is discontinuous as the parameter X crosses the real 
axis between -1.0 and 1.0. 

(20)
The computed results of the mathematically multivalued 
functions are rendered single-valued by the following 
conventions, which are meant to imply the principal branch: 
(21)

* The real component of the result of the Sqrt and 
Arccosh functions is nonnegative. 

(22)

* The same convention applies to the imaginary component 
of the result of the Log function as applies to the result of 
the natural-cycle version of the Argument function of 
Numerics.Generic_Complex_Types (see G.1.1). 

(23)

* The range of the real (resp., imaginary) component of 
the result of the Arcsin and Arctan (resp., Arcsinh and Arctanh) 
functions is approximately -Pi/2.0 to Pi/2.0. 

(24)

* The real (resp., imaginary) component of the result of 
the Arccos and Arccot (resp., Arccoth) functions ranges from 0.0 
to approximately Pi. 

(25)

* The range of the imaginary component of the result of 
the Arccosh function is approximately -Pi to Pi. 
-- 
Edward Cherlin
Generalist  activist--Linux, languages, literacy and more
A knot! Oh, do let me help to undo it!
--Alice in Wonderland
http://cherlin.blogspot.com


Re: Complex Arithmetic

2005-05-19 Thread Luke Palmer
On 5/19/05, Edward Cherlin [EMAIL PROTECTED] wrote:
 It turns out that the domain and range and the location of the
 cut lines have to be worked out separately for different
 functions. Mathematical practice is not entirely consistent in
 making these decisions, but in programming, there seems to be
 widespread agreement that the shared definitions used in the
 APL, Common LISP, and Ada standards are the best available.
 
 Do we want to get into all of this in Perl6?

I'm not really sure I know what you mean by do we want to get into
all of this?.  If we're going to have a Complex class, we have to. 
But getting into it might involve saying that APL, CL, and Ada are
the best, so we use those.  This is the kind of problem where, if
someone wants to get more precise, they turn to CPAN.

Luke


Re: Complex Arithmetic

2005-05-19 Thread Sam Vilain
Edward Cherlin wrote:
There was a discussion of the principal value of square root on 
this list some time back, making the point that for positive 
   [...]
It turns out that the domain and range and the location of the 
cut lines have to be worked out separately for different 
functions. Mathematical practice is not entirely consistent in 
making these decisions, but in programming, there seems to be 
widespread agreement that the shared definitions used in the 
APL, Common LISP, and Ada standards are the best available.
Do we want to get into all of this in Perl6?
pugs currently has Complex as a built-in type, though it isn't explicitly
listed in S06.  I can't see any tests for them yet, though.
So, testing the Complex number functionality as well as detailed
exploration of the corner cases, and alignment with best practice will
surely be appreciated by people looking at doing Complex math in Perl 6.
I think this applies regardless of whether it ends up a core type
(whatever that means) or not.  Personally I don't think that Complex numbers
are so bizarre an entity that you wouldn't want sqrt(-1) to return one
out of the box.
It's likely that very little implementation changes will need to be done,
as no doubt the mathematically minded folk that write GHC will have been
through that before.  But it will be invaluable in testing compliance of
the different run-time engines.
I suggest you come to the IRC channel at #perl6 on irc.freenode.net, and
ask for a committer account.
Sam.