Re: Comments on S32/Numeric#Complex
It would be reasonable for perl6 to have .arg to match .angle. [SIGH] ☹ Obviously, I meant to say: It would be reasonable for perl6 to have .arg to match¹ .abs. 1] or to complement, perhaps? ☺ -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: Comments on S32/Numeric#Complex
Doug == Doug McNutt dougl...@macnauchtan.com writes: Any ideas for a good name [for the angle]? Doug In pre-computer times the angle was called the argument. And that is still used. C99, as an example, calls the functions carg(3), cargf(3) and cargl(3), for operations on double complex, float complex and long double complex values, following its convention of using an f suffix for float, l suffix for long double and a c prefix for complex. It would be reasonable for perl6 to have .arg to match .angle. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: Comments on S32/Numeric#Complex
At 17:10 -0500 2009-12-16, Dave Whipp wrote:
define the return value more formally, something like:
our multi method polar (Complex $nim: -- [ Real $mag where 0..Inf,
Real $angle where -¼ ..^ ¼ ]) is export { ... }
In complex analysis it is often legitimate to work with numbers
where the range of $angle is something other than -¼ ..^ ¼,
either because you want the branch cut somewhere else ( 0 ..^ 2¼ )
or you are on some other sheet ( ¼ ..^ 3¼ )
Does the above proposal stand in the way of this sort of work?
Regards,
Todd Olson
Re: Comments on S32/Numeric#Complex
At 19:46 -0500 2009-12-16, Dave Whipp wrote: yary wrote: At 00:15 +0100 12/17/09, Moritz Lenz wrote: Not quite, .abs returns one of the polar coordinates (the magnitude), so only a method is missing that returns the angle. Any ideas for a good name? Would a method called phi with a unicode synonym É be too obtuse? Anything wrong with .angle? In physics and electrical engineering we often speak of the phase Regards, Todd Olson
Re: Comments on S32/Numeric#Complex
Moritz Lenz wrote: Dave Whipp wrote: [cut] Contrast with Rat which has both separate accessors and the nude method (a name that could possibly be improved to avoid adult-content filters) suggestions welcome. Attempting to generalize: what we want is an operator that extracts a Seq of values from an object based on a positive criteria. For string objects, this description matches the Ccomb method. Generalizing: my @words = $line.comb( /\S+/ ); my ($num, $denom) = $num.comb( :Ratio ); my ($mag, $phase) = $z.comb( :Complex::Polar ); my ($re, $im) = $z.comb( :Complex::Cartesian ); my ($x, $y) = $vector.comb( [1,0], [0,1] );
Re: Comments on S32/Numeric#Complex
Dave Whipp wrote: Moritz Lenz wrote: Dave Whipp wrote: [cut] Contrast with Rat which has both separate accessors and the nude method (a name that could possibly be improved to avoid adult-content filters) suggestions welcome. Attempting to generalize: what we want is an operator that extracts a Seq of values from an object based on a positive criteria. For string objects, this description matches the Ccomb method. Generalizing: my @words = $line.comb( /\S+/ ); my ($num, $denom) = $num.comb( :Ratio ); my ($mag, $phase) = $z.comb( :Complex::Polar ); my ($re, $im) = $z.comb( :Complex::Cartesian ); my ($x, $y) = $vector.comb( [1,0], [0,1] ); I like the idea of a general mechanism for producing a list of an object's attributes; but I don't think that .comb() is the way to go about it. Rather, I'd use .^attr(). my ($num, $denom) = $num.^attr; # $num.WHAT == Ratio; my ($mag, $phase) = Complex::Polar($z).^attr; my ($re, $im) = Complex::Cartesian($z).^attr; my ($x, $y) = $vector.^attr »·« ( [1, 0], [0, 1] ); -- Jonathan Dataweaver Lang
Re: Comments on S32/Numeric#Complex
Jon Lang wrote: my ($num, $denom) = $num.^attr; # $num.WHAT == Ratio; my ($mag, $phase) = Complex::Polar($z).^attr; my ($re, $im) = Complex::Cartesian($z).^attr; my ($x, $y) = $vector.^attr »·« ( [1, 0], [0, 1] ); If I'm reading this right, the .^attr is exposing implementation details of the object to get its components. To my mind that is not desirable. And I think there's a Math error in the 4th line: you don't need the components of a vector to do a dot product with that vector -- so it is just my ($x, $y) = $vector «·« ( [1, 0], [0, 1] ); Which makes me wonder if all of them are just the dot-product of an object with a role (i.e. it uses the .^attr of the role, not the object): my ($num, $denom) = $real_number · :Ratio; my ($mag, $phase) = $complex_number · :Complex::Polar; Which has a pleasing symmetry with the dot used for method calls
Re: Comments on S32/Numeric#Complex
Dave Whipp wrote:
Jon Lang wrote:
my ($num, $denom) = $num.^attr; # $num.WHAT == Ratio;
my ($mag, $phase) = Complex::Polar($z).^attr;
my ($re, $im) = Complex::Cartesian($z).^attr;
my ($x, $y) = $vector.^attr »·« ( [1, 0], [0, 1] );
If I'm reading this right, the .^attr is exposing implementation details of
the object to get its components. To my mind that is not desirable.
The reason that HOW is spelled in allcaps is because it can be used in
undesirable ways. In particular, whedn you introspect an object,
you're looking at its implementation details.
And really, my whole point is that the implementation details are
(conceptually) the only thing that distinguishes Complex::Polar from
Complex::Cartesian. More on this below.
And I think there's a Math error in the 4th line: you don't need the
components of a vector to do a dot product with that vector -- so it is just
my ($x, $y) = $vector «·« ( [1, 0], [0, 1] );
True enough.
Which makes me wonder if all of them are just the dot-product of an object
with a role (i.e. it uses the .^attr of the role, not the object):
The role may not have a .^attr; in particular, I'd expect the
following to be true:
role Complex {
...
method re() { ... }
method im() { ... }
method abs() { ... }
method arg() { ... }
} # no has declarations
class Complex::Cartesian does Complex { has $re, $im; ... }
class Complex::Polar does Complex { has $abs, $arg; ... }
There's another problem with my proposal, namely the fact that
introspection of a package's component parts shouldn't be expected to
preserve the order of said components. But setting that aside for the
moment: Complex.^attr ought to return an empty list, since no
attributes were declared in it; Complex::Polar.^attr ought to return a
magnitude and an argument (i.e., an angle); and
Complex::Cartesian.^attr ought to return a real value and an imaginary
value.
--
Jonathan Dataweaver Lang
Re: Comments on S32/Numeric#Complex
At 14:54 -0500 2009-12-17, Jon Lang wrote: Dave Whipp wrote: And really, my whole point is that the implementation details are (conceptually) the only thing that distinguishes Complex::Polar from Complex::Cartesian. All though both e^(i ¼) and e^(i 3 ¼) evaluate to -1 + 0i it is often useful to be able to distinguish them. So perhaps the question is do we really want Perl6 to automatically convert e^(i 3 ¼) to e^(i ¼) internally. If not, then we really do want some sort of access to the implementation details. This is similar to the question for rational numbers if we really want Perl6 to automatically convert 4/8 to 1/2 and 51/68 to 3/4 internally So if you mean that we should have access to the implementation details to see if we have 4/8 rather than 1/2, then I'm with you. Regards, Todd Olson
Re: Comments on S32/Numeric#Complex
At 11:54 -0800 12/17/09, Jon Lang wrote: And I think there's a Math error in the 4th line: you don't need the components of a vector to do a dot product with that vector -- so it is just my ($x, $y) = $vector «·« ( [1, 0], [0, 1] ); True enough. Which makes me wonder if all of them are just the dot-product of an object with a role (i.e. it uses the .^attr of the role, not the object): I became an observer a few years ago when vector operations were being introduced in perl6. I was excited, thinking that perl6 was actually gong to do mathematics. After a while I became resigned to the fact that dot and cross products were not what was being offered. Instead a product of two vectors was to be simply a component by component multiply that produced another vector of the same size as the arguments. It appears that is what is being done in the formula above. OK. Perhaps there really are uses for that operation in the computing world. But please don't call the result a dot product! It will be misinterpreted forever in the same way that the term kilo was forever made ambiguous when computer types decided it meant 2**10 instead of 10**3. Dot and cross products have been around since Newton. Kilo since the mid 1800s. Phase is a good name for the angular part of a polar complex number. It's actually used that way by electrical engineers working with three phase power distribution. But those guys also expect a dot product to be a scalar which is the sum of the products of the vector components. True power is charged for by computing the dot product of voltage and current vectors expressed as complex numbers. That requires the original meaning of the dot product. $dotproduct = @vector1 . @vector2; In scalar context would be nice but it can come later as an add-on. -- -- From the U S of A, the only socialist country that refuses to admit it. --
Re: Comments on S32/Numeric#Complex
Doug McNutt wrote: my ($x, $y) = $vector «·« ( [1, 0], [0, 1] ); After a while I became resigned to the fact that dot and cross products were not what was being offered. Instead a product of two vectors was to be simply a component by component multiply that produced another vector of the same size as the arguments. It appears that is what is being done in the formula above. No, I am assuming that it is a real dot-product: the hypers are there because the RHS is a list of basis vectors; so the output is a list of magnitudes in the directions of those bases. For the UTF-challenged, I'd want an ascii form: my ($x, $y) = $vector dot ( [1, 0], [0, 1] );
Re: Comments on S32/Numeric#Complex
Todd Olson wrote: At 14:54 -0500 2009-12-17, Jon Lang wrote: And really, my whole point is that the implementation details are (conceptually) the only thing that distinguishes Complex::Polar from Complex::Cartesian. All though both e^(i ¼) and e^(i 3 ¼) evaluate to -1 + 0i it is often useful to be able to distinguish them. So perhaps the question is do we really want Perl6 to automatically convert e^(i 3 ¼) to e^(i ¼) internally. If not, then we really do want some sort of access to the implementation details. If I was implementing Complex::Polar I'd probably use an Int64 to represent the phase internally: we can scale it by pi/2**63 in the accessor. That way it automatically collapses onto one cycle. These internal details are why I don't really like the idea of exposing .^attr as the mechanism by which users serialize the object. It would be fine to use it as the default implementation of a generic serialization method, but users of the object shouldn't know that.
Comments on S32/Numeric#Complex
The definition of the Complex type seems a little weak. A few things:
To get the Cartesian components of the value there are two methods (re
and im). In contrast there is just one method polar to return the
polar components of the value I'm not sure that this asymmetry is a good
thing. Contrast with Rat which has both separate accessors and the
nude method (a name that could possibly be improved to avoid
adult-content filters)
The next thing I notice is that the return value of polar is defined
as a Seq (as is the return value of nude), with an English-language
definition of that the (exactly) two members of the sequence are. Surely
it is possible in a perl6 signature to define the return value more
formally, something like:
our multi method polar (Complex $nim: -- [ Real $mag where 0..Inf,
Real $angle where -π ..^ π ]) is export { ... }
Finally, anyone using complex numbers probably wants a conjugate
method and/or operator postfix:* almost as much as they want unary-minus:
$mag = sqrt( $z * $z* );
Dave.
Re: Comments on S32/Numeric#Complex
On Wed, Dec 16, 2009 at 2:10 PM, Dave Whipp d...@dave.whipp.name wrote:
The definition of the Complex type seems a little weak. A few things:
To get the Cartesian components of the value there are two methods (re and
im). In contrast there is just one method polar to return the polar
components of the value I'm not sure that this asymmetry is a good thing.
Contrast with Rat which has both separate accessors and the nude method (a
name that could possibly be improved to avoid adult-content filters)
The next thing I notice is that the return value of polar is defined as a
Seq (as is the return value of nude), with an English-language
definition of that the (exactly) two members of the sequence are. Surely it
is possible in a perl6 signature to define the return value more formally,
something like:
our multi method polar (Complex $nim: -- [ Real $mag where 0..Inf, Real
$angle where -π ..^ π ]) is export { ... }
Finally, anyone using complex numbers probably wants a conjugate method
and/or operator postfix:* almost as much as they want unary-minus:
$mag = sqrt( $z * $z* );
All good points.
IMHO, what we want is a role that defines four separate accessors (two
for cartesian coordinates and two for polar coordinates); a coercion
constructor (i.e., it accepts any object that does the role, and
returns an object using an implementation to be defined by the class);
a postfix:* method; and the usual stuff. And we want a pair of
classes, one of which implements the role using cartesian coordinates
and another that implements it using polar coordinates. I forget if
Perl still allows you to use a fully-defined role as a class; if so,
handle the cartesian implementation within the Complex role, with the
ComplexPolar class overriding enough of that definition to make it
polar instead of cartesian.
--
Jonathan Dataweaver Lang
Re: Comments on S32/Numeric#Complex
Dave Whipp wrote:
The definition of the Complex type seems a little weak. A few things:
To get the Cartesian components of the value there are two methods (re
and im). In contrast there is just one method polar to return the
polar components of the value
Not quite, .abs returns one of the polar coordinates (the magnitude), so
only a method is missing that returns the angle.
Any ideas for a good name?
I'm not sure that this asymmetry is a good
thing. Contrast with Rat which has both separate accessors and the
nude method (a name that could possibly be improved to avoid
adult-content filters)
suggestions welcome.
The next thing I notice is that the return value of polar is defined
as a Seq (as is the return value of nude), with an English-language
definition of that the (exactly) two members of the sequence are. Surely
it is possible in a perl6 signature to define the return value more
formally, something like:
our multi method polar (Complex $nim: -- [ Real $mag where 0..Inf,
Real $angle where -π ..^ π ]) is export { ... }
If you put this into a signature, it is checked on every call to that
method and thus slows down execution. If you want a formalization that's
not part of the signature, you find that in the test suite.
Finally, anyone using complex numbers probably wants a conjugate
method and/or operator postfix:* almost as much as they want unary-minus:
$mag = sqrt( $z * $z* );
$max = abs $z;
I agree that conjugate is a good idea, but please don't use postfix:*
for that. It's defined as a term and as an infix already, and in
signatures also as a prefix. There's also the infix:** and the term
**, and I won't even start to talk about regexes and other DSLs or twigils.
I'm really opposed to giving the asterisk yet another meaning.
Cheers,
Moritz
Re: Comments on S32/Numeric#Complex
At 00:15 +0100 12/17/09, Moritz Lenz wrote: Not quite, .abs returns one of the polar coordinates (the magnitude), so only a method is missing that returns the angle. Any ideas for a good name? In pre-computer times the angle was called the argument. But that offers plenty of room for confusion in the current contest. -- -- So do we celebrate the start of a new decade at the end of this year? Or do the tens start at in January 2011? Was the first year, ACE, assigned Roman numeral I ?--
Re: Comments on S32/Numeric#Complex
At 00:15 +0100 12/17/09, Moritz Lenz wrote: Not quite, .abs returns one of the polar coordinates (the magnitude), so only a method is missing that returns the angle. Any ideas for a good name? Would a method called phi with a unicode synonym φ be too obtuse? -y
Re: Comments on S32/Numeric#Complex
Moritz Lenz wrote:
our multi method polar (Complex $nim: -- [ Real $mag where 0..Inf,
Real $angle where -π ..^ π ]) is export { ... }
If you put this into a signature, it is checked on every call to that
method and thus slows down execution. If you want a formalization that's
not part of the signature, you find that in the test suite.
That feels unfortunate, to me. Could we not have a pragma/trait that
says for this scope, assume all my post-conditions are true (also
affects POST phasers) that has a command-line (or env-var, whatever)
override for debugging? For things in Setting.pm it really should be
safe to set such a flag for general use.
Re: Comments on S32/Numeric#Complex
yary wrote: At 00:15 +0100 12/17/09, Moritz Lenz wrote: Not quite, .abs returns one of the polar coordinates (the magnitude), so only a method is missing that returns the angle. Any ideas for a good name? Would a method called phi with a unicode synonym φ be too obtuse? Anything wrong with .angle?
Re: Comments on S32/Numeric#Complex
On Dec 16, 2009, at 19:46 , Dave Whipp wrote: yary wrote: At 00:15 +0100 12/17/09, Moritz Lenz wrote: Not quite, .abs returns one of the polar coordinates (the magnitude), so only a method is missing that returns the angle. Any ideas for a good name? Would a method called phi with a unicode synonym φ be too obtuse? Anything wrong with .angle? I was thinking, if you want a short name to match .abs, try .dir. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
