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

[coke]

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]

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]

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 [email protected] 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//issues/48#issuecomment-18658404
.

[colomon]

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]

@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]

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

[JJ]

Is there any consensus here?

[lichtkind]

I will need such function for my Math::Matrix.gist but pmichauds suggestion if good enough to me (plus your free about the order and use the same names as for single value) and reals is certainly not that good of a name