Rakudo has Complex.reals ... what's spec? #48

Open
coke opened this Issue May 30, 2013 · 5 comments

Comments

Projects
None yet
5 participants
@coke
Contributor

coke commented May 30, 2013

Originally raised on https://rt.perl.org/rt3/Ticket/Display.html?id=83720

is there a method that pulls out .re and .im as a list
.reals
that's so misnamed
what PerlJam said.

  • masak considers getting a #perl6 badge "API naming curmudgeon"
    rakudo: say (1+2i).reals.fmt("%7.3f")
    rakudo cad076: OUTPUT« 1.000 2.000␤»
    wtf, .reals exists?!
    <\TimToady> it should obviously be named .reim
  • masak submits rakudobug
    masak: yeah, I thought he was joking too
    masak++
    whoever named that function, come talk with me at the end of the day. :)

But neither .reals nor .reim in the specs. Need to pick one or the other (or none) before this can be sorted in rakudo.

@colomon

This comment has been minimized.

Show comment
Hide comment
@colomon

colomon May 30, 2013

Member

The idea behind the name .reals is that it was supposed to be a Numeric method that breaks any Numeric type into a list of Reals. As I recall it, the primary idea was to provide an easy way to sort over different Numeric types, including user-created ones.

Quite a while after .reals was created, this approach to sorting was vetoed. The ng branch of Rakudo had Real.reals, so the method was defined for all core numeric types. It seems that only Complex.reals made it into the current Rakudo. Certainly without the corresponding method in other numeric types the name .reals makes absolutely no sense.

It does still seem somewhat important to me that p6 do something sensible when asked to sort a list of numbers, some of which are complex. But it may be that is an issue for another spec ticket.

Member

colomon commented May 30, 2013

The idea behind the name .reals is that it was supposed to be a Numeric method that breaks any Numeric type into a list of Reals. As I recall it, the primary idea was to provide an easy way to sort over different Numeric types, including user-created ones.

Quite a while after .reals was created, this approach to sorting was vetoed. The ng branch of Rakudo had Real.reals, so the method was defined for all core numeric types. It seems that only Complex.reals made it into the current Rakudo. Certainly without the corresponding method in other numeric types the name .reals makes absolutely no sense.

It does still seem somewhat important to me that p6 do something sensible when asked to sort a list of numbers, some of which are complex. But it may be that is an issue for another spec ticket.

@dwhipp

This comment has been minimized.

Show comment
Hide comment
@dwhipp

dwhipp May 30, 2013

Contributor

If someone wants to pull out .re and .im as a list, cannot they simply
write $z.?

On Wed, May 29, 2013 at 7:36 PM, colomon notifications@github.com wrote:

The idea behind the name .reals is that it was supposed to be a Numeric
method that breaks any Numeric type into a list of Reals. As I recall it,
the primary idea was to provide an easy way to sort over different Numeric
types, including user-created ones.

Quite a while after .reals was created, this approach to sorting was
vetoed. The ng branch of Rakudo had Real.reals, so the method was defined
for all core numeric types. It seems that only Complex.reals made it into
the current Rakudo. Certainly without the corresponding method in other
numeric types the name .reals makes absolutely no sense.

It does still seem somewhat important to me that p6 do something sensible
when asked to sort a list of numbers, some of which are complex. But it may
be that is an issue for another spec ticket.


Reply to this email directly or view it on GitHubhttps://github.com/perl6/specs/issues/48#issuecomment-18658404
.

Contributor

dwhipp commented May 30, 2013

If someone wants to pull out .re and .im as a list, cannot they simply
write $z.?

On Wed, May 29, 2013 at 7:36 PM, colomon notifications@github.com wrote:

The idea behind the name .reals is that it was supposed to be a Numeric
method that breaks any Numeric type into a list of Reals. As I recall it,
the primary idea was to provide an easy way to sort over different Numeric
types, including user-created ones.

Quite a while after .reals was created, this approach to sorting was
vetoed. The ng branch of Rakudo had Real.reals, so the method was defined
for all core numeric types. It seems that only Complex.reals made it into
the current Rakudo. Certainly without the corresponding method in other
numeric types the name .reals makes absolutely no sense.

It does still seem somewhat important to me that p6 do something sensible
when asked to sort a list of numbers, some of which are complex. But it may
be that is an issue for another spec ticket.


Reply to this email directly or view it on GitHubhttps://github.com/perl6/specs/issues/48#issuecomment-18658404
.

@colomon

This comment has been minimized.

Show comment
Hide comment
@colomon

colomon May 30, 2013

Member

One thought towards resolving the sorting problem: perhaps the right solution is to promote .re and .im (and presumably .polar and .conj as well) to Numeric or maybe even Cool? That way sorting by the real parts of numbers would be as simple as sort(*.re) ...

Member

colomon commented May 30, 2013

One thought towards resolving the sorting problem: perhaps the right solution is to promote .re and .im (and presumably .polar and .conj as well) to Numeric or maybe even Cool? That way sorting by the real parts of numbers would be as simple as sort(*.re) ...

@leto

This comment has been minimized.

Show comment
Hide comment
@leto

leto May 30, 2013

Member

@colomon if one wants to sort a bunch of numbers, some of which may be Complex, then one should take the absolute value of all of them first. Otherwise, there is no preferred ordering for Compex numbers or any of their "more complex" cousins such as Quaternions and Octonions.

May I humbly suggest that Numeric or Cool learn about a "coef()" method which returns the real coefficients of a Numeric type as an ordered list. This could be nicely generalized to vectors, matrices and beyond.

For instance, (1+2i).coef() should return (1,2), (42).coef() should return (42) and (3i).coef() should return (0,3).

Member

leto commented May 30, 2013

@colomon if one wants to sort a bunch of numbers, some of which may be Complex, then one should take the absolute value of all of them first. Otherwise, there is no preferred ordering for Compex numbers or any of their "more complex" cousins such as Quaternions and Octonions.

May I humbly suggest that Numeric or Cool learn about a "coef()" method which returns the real coefficients of a Numeric type as an ordered list. This could be nicely generalized to vectors, matrices and beyond.

For instance, (1+2i).coef() should return (1,2), (42).coef() should return (42) and (3i).coef() should return (0,3).

@pmichaud

This comment has been minimized.

Show comment
Hide comment
@pmichaud

pmichaud May 30, 2013

Member

@dwhipp: $z.<re im> would be the same as $z{'re', 'im'} (hash slice), not ($z.re, $z.im).

Member

pmichaud commented May 30, 2013

@dwhipp: $z.<re im> would be the same as $z{'re', 'im'} (hash slice), not ($z.re, $z.im).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment