code review 296042: Clarify that conversions to complex are OK.

Clarify that conversions to complex are OK.

[iant, 2010-03-08 21:21:25]

Hello r (cc: golang-dev@googlegroups.com),

I'd like you to review this change.

[r2, 2010-03-08 21:24:16]

LGTM

On Mar 8, 2010, at 1:21 PM, iant@golang.org wrote:

> Reviewers: r,
>
> Message:
> Hello r (cc: golang-dev@googlegroups.com),
>
> I'd like you to review this change.
>
>
> Description:
> Clarify that conversions to complex are OK.
>
> Please review this at http://codereview.appspot.com/296042/show
>
> Affected files:
>  M doc/go_spec.html
>
>
> Index: doc/go_spec.html
> ===================================================================
> --- a/doc/go_spec.html
> +++ b/doc/go_spec.html
> @@ -3262,7 +3262,7 @@
> </li>
> <li>
> A value of complex type may be converted to a different complex type,
> -but there is no conversion between complex and any other type.
> +but there is no conversion from complex to any other type.
> <li>
> When converting a number to a floating-point or complex type,
> the result value is rounded
>
>

[iant, 2010-03-08 21:45:11]

*** Submitted as http://code.google.com/p/go/source/detail?r=fc0c03598d5a ***

Clarify that conversions to complex are OK.

R=r
CC=golang-dev
http://codereview.appspot.com/296042

[rsc, 2010-03-08 21:50:55]

This isn't true.

var f float64
var c = complex(f)  // not allowed

Russ

[iant2, 2010-03-08 22:08:59]

Russ Cox <rsc@golang.org> writes:

> This isn't true.
>
> var f float64
> var c = complex(f)  // not allowed

It works with the current 8g, a similar idea is explicitly permitted
with constant expressions, and it is unambiguous.  Is there a reason
to disallow it?

Ian

[rsc, 2010-03-08 22:12:34]

> It works with the current 8g, a similar idea is explicitly permitted
> with constant expressions, and it is unambiguous.  Is there a reason
> to disallow it?

hmm.
i thought the early proposals being sent around
disallowed it.  (testing with 6g is better
than 8g - 8g just throws everything on
the floor right now - but even 6g allows it.)
i think it's fine to have, i just thought we didn't.

russ

[gri1, 2010-03-09 00:00:21]

The early proposals did disallow it. I think it is confusing. For instance,
it would seem that complex(x) == cmplx(x, 0) for a non-complex number x; but
not quite (I think). complex(x) presumably returns a complex number of type
complex, while cmplx(x) returns the complex corresponding to the precision
of x.

I am still wondering if it would be better to allow complex to be used as a
2-argument conversion and get rid of cmplx.

- Robert

On Mon, Mar 8, 2010 at 2:12 PM, Russ Cox <rsc@golang.org> wrote:

> > It works with the current 8g, a similar idea is explicitly permitted
> > with constant expressions, and it is unambiguous.  Is there a reason
> > to disallow it?
>
> hmm.
> i thought the early proposals being sent around
> disallowed it.  (testing with 6g is better
> than 8g - 8g just throws everything on
> the floor right now - but even 6g allows it.)
> i think it's fine to have, i just thought we didn't.
>
> russ
>

[rsc, 2010-03-09 00:02:09]

I think it would be very confusing for
complex(x,y) to have type complex128, say.
Ken was surprised that complex(f) worked.

Russ

[gri1, 2010-03-09 00:13:38]

What I meant was that complexXX works as follows if it has 2 arguments:

complex(x, y) == cmplx(float(x), float(y))
complex64(x, y) == cmplx(float32(x), float32(y))
complex128(x, y) == cmplx(float64(x), float64(y))

so it's always clear what the result type is. Not clearly better, but I
agree that it is somewhat at odds with the other conversions that complex(x)
cannot be used if x is not a complex variable.

- Robert

On Mon, Mar 8, 2010 at 4:01 PM, Russ Cox <rsc@golang.org> wrote:

> I think it would be very confusing for
> complex(x,y) to have type complex128, say.
> Ken was surprised that complex(f) worked.
>
> Russ
>

[rsc, 2010-03-09 00:15:43]

On Mon, Mar 8, 2010 at 16:13, Robert Griesemer <gri@google.com> wrote:
> What I meant was that complexXX works as follows if it has 2 arguments:
> complex(x, y) == cmplx(float(x), float(y))
> complex64(x, y) == cmplx(float32(x), float32(y))
> complex128(x, y) == cmplx(float64(x), float64(y))
> so it's always clear what the result type is. Not clearly better, but I
> agree that it is somewhat at odds with the other conversions that complex(x)
> cannot be used if x is not a complex variable.

But you also said get rid of cmplx.
Cmplx exists precisely to avoid having to
say what the size of the complex type is,
to play more nicely with ":=".

Russ

[rog, 2010-03-09 11:11:09]

i dislike the spelling of "cmplx" - although i haven't
got a better suggestion. i presume "mkcomplex"
would be considered too long?

[r2, 2010-03-09 17:36:20]

On Mar 9, 2010, at 3:11 AM, roger peppe wrote:

> i dislike the spelling of "cmplx" - although i haven't
> got a better suggestion. i presume "mkcomplex"
> would be considered too long?

Where does 'mk' come from?  Seems just as ugly to me, and longer, not  
to justify 'cmplx' as harmonious.  A better name would be welcome.

-rob

[rog, 2010-03-09 18:11:47]

On 9 March 2010 17:36, Rob 'Commander' Pike <r@google.com> wrote:
>
> On Mar 9, 2010, at 3:11 AM, roger peppe wrote:
>
>> i dislike the spelling of "cmplx" - although i haven't
>> got a better suggestion. i presume "mkcomplex"
>> would be considered too long?
>
> Where does 'mk' come from?  Seems just as ugly to me, and longer, not to
> justify 'cmplx' as harmonious.

i agree "mkcomplex" is just as ugly. i was trying to come up with a name
that reflected to some degree its difference from "complex"
the type name: that it makes a complex number of appropriate
type, rather than casting to a particular type.

>  A better name would be welcome.

hmm.
complexv ?

the v standing for "value".