code review 5655049: spec: clarify implementation restrictions on untyped floats

spec: clarify implementation restrictions on untyped floats

Drop reference to "machine type."  Specify that integer
overflow must be an error.  Drop requirement that exponent
must be 128 bits--that's a lot.  Clarify that floating point
expressions may be rounded, including intermediate values.

This is a reworking of http://codereview.appspot.com/5577068/ .

Fixes issue 2789.

[iant, 2012-02-10 04:38:23]

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

I'd like you to review this change to
https://go.googlecode.com/hg/

[r, 2012-02-10 04:44:48]

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html#newcode598
doc/go_spec.html:598: integer value, it will give an error.  If the compiler is
unable to
to represent an integer value precisely

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html#newcode599
doc/go_spec.html:599: precisely represent a floating-point or complex value, it
may give an
ditto.

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html#newcode600
doc/go_spec.html:600: error or it may round the value.
overflow/underflow are not rounded. there's a little more going on here.

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html#newcode3578
doc/go_spec.html:3578: This rounding may cause a floating-point expression to
not convert to
to fail to convert

or avoid passive

may prevent a floating-point expression from converting to integer type

[rsc, 2012-02-10 04:45:38]

> +<p>
> +This rounding may cause a floating-point expression to not convert to
> +integer type, even if it would convert if the expression were
> +calculated using infinite precision.
> +</p>

This rounding may cause a floating-point constant expression
to be invalid in an integer context, even if it would be integral
when calculated using infinite precision.

[r2, 2012-02-10 04:48:43]

On Feb 10, 2012, at 3:45 PM, Russ Cox wrote:

>> +<p>
>> +This rounding may cause a floating-point expression to not convert to
>> +integer type, even if it would convert if the expression were
>> +calculated using infinite precision.
>> +</p>
> 
> This rounding may cause a floating-point constant expression
> to be invalid in an integer context, even if it would be integral
> when calculated using infinite precision.

good

[iant, 2012-02-10 05:47:33]

PTAL

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html#newcode598
doc/go_spec.html:598: integer value, it will give an error.  If the compiler is
unable to
On 2012/02/10 04:44:48, r wrote:
> to represent an integer value precisely

Done.

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html#newcode599
doc/go_spec.html:599: precisely represent a floating-point or complex value, it
may give an
On 2012/02/10 04:44:48, r wrote:
> ditto.

Done.

http://codereview.appspot.com/5655049/diff/1/doc/go_spec.html#newcode600
doc/go_spec.html:600: error or it may round the value.
On 2012/02/10 04:44:48, r wrote:
> overflow/underflow are not rounded. there's a little more going on here.

Underflow can round to zero; I don't think there is anything else to be said
about that.  Added a clause saying that overflow must give an error.

[rsc, 2012-02-10 05:52:43]

http://codereview.appspot.com/5655049/diff/7001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/7001/doc/go_spec.html#newcode596
doc/go_spec.html:596: value, with a mantissa of at least 128 bits and an
exponent of at
signed exponent?
(To make clear that the sign bit can be one of the 32.)

http://codereview.appspot.com/5655049/diff/7001/doc/go_spec.html#newcode601
doc/go_spec.html:601: floating-point or complex value precisely, it may give an
error or it
I think may give an error is too much here.  We already defined the error for
overflow, which is the important one.  The others should round to the nearest
floating-point value that it can represent.  You don't want const f = 0.1
to be a compiler error.  

... it may round the value to the nearest value it can represent.

[iant, 2012-02-10 06:08:44]

http://codereview.appspot.com/5655049/diff/7001/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/7001/doc/go_spec.html#newcode596
doc/go_spec.html:596: value, with a mantissa of at least 128 bits and an
exponent of at
On 2012/02/10 05:52:43, rsc wrote:
> signed exponent?
> (To make clear that the sign bit can be one of the 32.)

Done.

http://codereview.appspot.com/5655049/diff/7001/doc/go_spec.html#newcode601
doc/go_spec.html:601: floating-point or complex value precisely, it may give an
error or it
On 2012/02/10 05:52:43, rsc wrote:
> I think may give an error is too much here.  We already defined the error for
> overflow, which is the important one.  The others should round to the nearest
> floating-point value that it can represent.  You don't want const f = 0.1
> to be a compiler error.  
> 
> ... it may round the value to the nearest value it can represent.

Done.

[rsc, 2012-02-10 06:10:33]

LGTM

http://codereview.appspot.com/5655049/diff/1002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/1002/doc/go_spec.html#newcode601
doc/go_spec.html:601: floating-point or complex value precisely, it may round
the value to
s/may/will/

(Unless there is something else we want to allow too?)

[r, 2012-02-10 06:11:11]

LGTM but i would like to hear from ken and gri

[iant, 2012-02-10 06:21:50]

http://codereview.appspot.com/5655049/diff/1002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/1002/doc/go_spec.html#newcode601
doc/go_spec.html:601: floating-point or complex value precisely, it may round
the value to
On 2012/02/10 06:10:33, rsc wrote:
> s/may/will/
> 
> (Unless there is something else we want to allow too?)

Done.

[gri, 2012-02-10 18:37:24]

http://codereview.appspot.com/5655049/diff/4/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/4/doc/go_spec.html#newcode3
doc/go_spec.html:3: "Subtitle": "Version of February 9, 2012"
set to current date

http://codereview.appspot.com/5655049/diff/4/doc/go_spec.html#newcode596
doc/go_spec.html:596: value, with a mantissa of at least 128 bits and a signed
exponent of
s/128/256/

For one, our own

math.E = 2.71828182845904523536028747135266249775724709369995957496696763

appears to require 208 bits for the representation of the mantissa (just run
this:

package main
import "math/big"
func main() {
	var x big.Int
	x.SetString("271828182845904523536028747135266249775724709369995957496696763",
0)
	println(x.BitLen())
}

).

Also, 256 bits strikes a better balance with the the exponent of 32 bits; for
instance the IEEE 128 bit floats (1+112bit signficand) have a 15bit exponent
(biased).

A compiler will have to use a library/customized code anyway, and making the
mantissa a bit bigger it not going to be a hardship.

[rsc, 2012-02-10 18:58:01]

> s/128/256/

I disagree.

> For one, our own
>
> math.E =
> 2.71828182845904523536028747135266249775724709369995957496696763
>
> appears to require 208 bits for the representation of the mantissa (just
> run this:

That constant was supposed to be more precise than necessary.
If constants are 256 bits internally, I'll have to add more digits.
128 bits is plenty considering that only 64 bits can be exported
into a run-time variable.

> Also, 256 bits strikes a better balance with the the exponent of 32
> bits; for instance the IEEE 128 bit floats (1+112bit signficand) have a
> 15bit exponent (biased).

There is no requirement that these be proportional.
32 bits of exponent is almost certainly overkill; I don't
think we have to overkill the precision to compensate.
If balance is a concern, I'd rather cut the exponent
requirement to 16 bits.

> A compiler will have to use a library/customized code anyway, and making
> the mantissa a bit bigger it not going to be a hardship.

I believe that right now gcc uses 128-bit mantissas.
Part of the goal here is to assume that what the compilers
are already doing is reasonable and define bounds on
the implementation that are already satisfied.

Russ

[gri, 2012-02-10 19:15:06]

On Fri, Feb 10, 2012 at 10:58 AM, Russ Cox <rsc@golang.org> wrote:
>> s/128/256/
>
> I disagree.
>
>> For one, our own
>>
>> math.E =
>> 2.71828182845904523536028747135266249775724709369995957496696763
>>
>> appears to require 208 bits for the representation of the mantissa (just
>> run this:
>
> That constant was supposed to be more precise than necessary.
> If constants are 256 bits internally, I'll have to add more digits.

Sure, but I thought 6g is already using more than 128bits already.

> 128 bits is plenty considering that only 64 bits can be exported
> into a run-time variable.

It's not about what can be represented at run-time, but about how
quickly rounding errors in constant expressions can lead to programs
that one would expect to compile, but that don't. Admittedly, I am not
a numerics expert, but one would expect that choosing more bits
(especially since it's cheap) should ameliorate this.

>
>> Also, 256 bits strikes a better balance with the the exponent of 32
>> bits; for instance the IEEE 128 bit floats (1+112bit signficand) have a
>> 15bit exponent (biased).
>
> There is no requirement that these be proportional.
> 32 bits of exponent is almost certainly overkill; I don't
> think we have to overkill the precision to compensate.
> If balance is a concern, I'd rather cut the exponent
> requirement to 16 bits.

I agree that 32bits is overkill (and if 128 is the mantissa, a 16bit
exponent should be fine, but it's not far away from 128bit floats).

>
>> A compiler will have to use a library/customized code anyway, and making
>> the mantissa a bit bigger it not going to be a hardship.
>
> I believe that right now gcc uses 128-bit mantissas.
> Part of the goal here is to assume that what the compilers
> are already doing is reasonable and define bounds on
> the implementation that are already satisfied.

According to Ian, changing to 256bits would not be hard.
- gri
>
> Russ

[rsc, 2012-02-10 19:15:52]

On Fri, Feb 10, 2012 at 14:15, Robert Griesemer <gri@golang.org> wrote:
> I agree that 32bits is overkill (and if 128 is the mantissa, a 16bit
> exponent should be fine, but it's not far away from 128bit floats).

But we don't have 128-bit floats.  If we were to add them to the
language, we could update this text at the same time.

Russ

[iant2, 2012-02-11 05:33:18]

Robert Griesemer <gri@golang.org> writes:

>> 128 bits is plenty considering that only 64 bits can be exported
>> into a run-time variable.
>
> It's not about what can be represented at run-time, but about how
> quickly rounding errors in constant expressions can lead to programs
> that one would expect to compile, but that don't. Admittedly, I am not
> a numerics expert, but one would expect that choosing more bits
> (especially since it's cheap) should ameliorate this.

Adding more bits doesn't noticeably decrease rounding errors.  All you
need to avoid all rounding errors for most operations is two additional
bits, one of which has to be sticky.  We aren't talking about doing a
sine function, where more bits can make a significant difference; we're
only talking about the four basic math operations.  In the absence of a
sticky bit, I think it's possible to construct cases where more bits
does avoid a rounding error, but you have to set up the calculation very
carefully.

Obviously 128 bits is more than can be actually expressed in a Go
program.  It's more than we need for somebody who needs precise floating
point numbers in their constant expressions.  I don't see a need to
require compilers to support more than 128.  I don't think it will help
any real programmers.  Let's not require more bits just because we can,
or for symmetry reasons.  Let's do it if it makes sense.

Ian

[gri, 2012-02-11 05:46:44]

Fine with me. But then perhaps we should indeed say that the exponent
must be at most 16bits (rather than 32).

- gri

On Fri, Feb 10, 2012 at 9:33 PM, Ian Lance Taylor <iant@google.com> wrote:
> Robert Griesemer <gri@golang.org> writes:
>
>>> 128 bits is plenty considering that only 64 bits can be exported
>>> into a run-time variable.
>>
>> It's not about what can be represented at run-time, but about how
>> quickly rounding errors in constant expressions can lead to programs
>> that one would expect to compile, but that don't. Admittedly, I am not
>> a numerics expert, but one would expect that choosing more bits
>> (especially since it's cheap) should ameliorate this.
>
> Adding more bits doesn't noticeably decrease rounding errors.  All you
> need to avoid all rounding errors for most operations is two additional
> bits, one of which has to be sticky.  We aren't talking about doing a
> sine function, where more bits can make a significant difference; we're
> only talking about the four basic math operations.  In the absence of a
> sticky bit, I think it's possible to construct cases where more bits
> does avoid a rounding error, but you have to set up the calculation very
> carefully.
>
> Obviously 128 bits is more than can be actually expressed in a Go
> program.  It's more than we need for somebody who needs precise floating
> point numbers in their constant expressions.  I don't see a need to
> require compilers to support more than 128.  I don't think it will help
> any real programmers.  Let's not require more bits just because we can,
> or for symmetry reasons.  Let's do it if it makes sense.
>
> Ian

[ken3, 2012-02-11 20:36:42]

the only reason for significantly more than the
native FP is for funny constant expressions involving
subtract and/or shift.

i think 128 is a little small. as i read the code,
gc uses 29*16 bits (=464). it used to be smaller
and i ran into some problems and increased it.
it was a trivial #define, so i probably over did it.

i guess i would vote for >=256
as long as FP is 64.

[iant, 2012-02-12 04:44:10]

Based on Ken's comment I bumped everything to 256 bits.  I didn't see any reason
to change the floating point to 256 without changing the integer also.  Both gc
and gccgo use more than 256 bits for integers anyhow.

Everybody OK with this version?

[gri, 2012-02-12 05:33:20]

LGTM

[r, 2012-02-12 11:07:16]

http://codereview.appspot.com/5655049/diff/5002/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/5002/doc/go_spec.html#newcode592
doc/go_spec.html:592: Implementation restriction: A compiler may implement
numeric constants
Is this an implementation restriction? It includes words like "must".

http://codereview.appspot.com/5655049/diff/5002/doc/go_spec.html#newcode3577
doc/go_spec.html:3577: Implementation restriction: A compiler may round final
and
ditto, kinda.

[iant2, 2012-02-12 19:06:30]

r@golang.org writes:

> http://codereview.appspot.com/5655049/diff/5002/doc/go_spec.html
> File doc/go_spec.html (right):
>
> http://codereview.appspot.com/5655049/diff/5002/doc/go_spec.html#newcode592
> doc/go_spec.html:592: Implementation restriction: A compiler may
> implement numeric constants
> Is this an implementation restriction? It includes words like "must".
>
> http://codereview.appspot.com/5655049/diff/5002/doc/go_spec.html#newcode3577
> doc/go_spec.html:3577: Implementation restriction: A compiler may round
> final and
> ditto, kinda.

It kind of goes both ways.  It's an implementation restriction in the
sense that the implementation is permitted to put some restrictions on
the language.  But the description of those restrictions also puts
limits on the restrictions.  We're kind of saying "the implementation
doesn't have to do all of the above, but it has to do at least this
much."

With that in mind, I rewrote the text to try to say the same thing in a
different way.

PTAL.

Ian

[r, 2012-02-12 20:24:33]

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode608
doc/go_spec.html:608: complex value due to overflow.</li>
again, underflow?
1e-40000: is that an error or just zero?

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode3588
doc/go_spec.html:3588: expressions; see the implementation restriction in the
section
these words seem clear to me.

[r, 2012-02-12 20:26:57]

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode598
doc/go_spec.html:598: <li>Represent integer values with at least 256 bits.</li>
weird. some comments i wrote in the previous round were dropped here. i'll try
again.

s/Represent/Evaluate/ ?
s/values/constant expressions/?

as written, it seems too vague, free of context, and open to interpretation.
since we're locking down the restrictions on the compiler, i want the words to
be clear.

[iant, 2012-02-13 01:03:44]

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode598
doc/go_spec.html:598: <li>Represent integer values with at least 256 bits.</li>
On 2012/02/12 20:26:57, r wrote:
> weird. some comments i wrote in the previous round were dropped here. i'll try
> again.
> 
> s/Represent/Evaluate/ ?
> s/values/constant expressions/?
> 
> as written, it seems too vague, free of context, and open to interpretation.
> since we're locking down the restrictions on the compiler, i want the words to
> be clear.

This part of the spec is about constants, not about constant expressions. 
That's why I am using words like "represent" and "value" here.  If you like I
can pull the later bit about expressions in here as well.

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode608
doc/go_spec.html:608: complex value due to overflow.</li>
On 2012/02/12 20:24:33, r wrote:
> again, underflow?
> 1e-40000: is that an error or just zero?

I think it's just zero.

[iant, 2012-02-13 01:19:59]

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode608
doc/go_spec.html:608: complex value due to overflow.</li>
On 2012/02/13 01:03:44, iant wrote:
> On 2012/02/12 20:24:33, r wrote:
> > again, underflow?
> > 1e-40000: is that an error or just zero?
> 
> I think it's just zero.

Let me clarify that: I think an underflow is just zero.  The value 1e-40000 is
required to be representable as a floating point number, since it only requires
1 bit of mantissa and 16 bits of exponent.

[r2, 2012-02-13 01:24:51]

On Feb 12, 2012, at 5:03 PM, iant@golang.org wrote:

> 
> http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html
> File doc/go_spec.html (right):
> 
> http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode598
> doc/go_spec.html:598: <li>Represent integer values with at least 256
> bits.</li>
> On 2012/02/12 20:26:57, r wrote:
>> weird. some comments i wrote in the previous round were dropped here.
> i'll try
>> again.
> 
>> s/Represent/Evaluate/ ?
>> s/values/constant expressions/?
> 
>> as written, it seems too vague, free of context, and open to
> interpretation.
>> since we're locking down the restrictions on the compiler, i want the
> words to
>> be clear.
> 
> This part of the spec is about constants, not about constant
> expressions.  That's why I am using words like "represent" and "value"
> here.  If you like I can pull the later bit about expressions in here as
> well.

My objection is that "represent values" feels out of place, even misleading, in
the middle of a section about constants. Moreover, the real issue isn't how
constants are represented but how they are evaluated when combined into
expressions.

-rob

[rsc, 2012-02-13 03:42:54]

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode598
doc/go_spec.html:598: <li>Represent integer values with at least 256 bits.</li>
> This part of the spec is about constants, not about constant expressions. 
> That's why I am using words like "represent" and "value" here.  If you like I
> can pull the later bit about expressions in here as well.

s/values/constants/?

Maybe add at the end

"These requirements apply both to literal constants and to the result of
evaluating constant expressions."

[r2, 2012-02-13 03:48:51]

On Feb 13, 2012, at 2:42 PM, rsc@golang.org wrote:
> 
> s/values/constants/?
> 
> Maybe add at the end
> 
> "These requirements apply both to literal constants and to the result of
> evaluating constant expressions."

these edits would address my concerns

[iant, 2012-02-13 05:53:03]

Sounds good.

PTAL.

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html
File doc/go_spec.html (right):

http://codereview.appspot.com/5655049/diff/2005/doc/go_spec.html#newcode598
doc/go_spec.html:598: <li>Represent integer values with at least 256 bits.</li>
On 2012/02/13 03:42:54, rsc wrote:
> > This part of the spec is about constants, not about constant expressions. 
> > That's why I am using words like "represent" and "value" here.  If you like
I
> > can pull the later bit about expressions in here as well.
> 
> s/values/constants/?
> 
> Maybe add at the end
> 
> "These requirements apply both to literal constants and to the result of
> evaluating constant expressions."

Done.

[r, 2012-02-13 05:55:13]

LGTM

[iant, 2012-02-13 18:10:15]

Any last comments from anybody on the current text?

[gri, 2012-02-13 18:12:14]

LGTM

On Mon, Feb 13, 2012 at 10:10 AM,  <iant@golang.org> wrote:
> Any last comments from anybody on the current text?
>
> http://codereview.appspot.com/5655049/

[rsc, 2012-02-13 18:36:08]

LGTM

[ken3, 2012-02-13 19:22:57]

lgtm

[iant, 2012-02-13 19:26:02]

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

spec: clarify implementation restrictions on untyped floats

Drop reference to "machine type."  Specify that integer
overflow must be an error.  Drop requirement that exponent
must be 128 bits--that's a lot.  Clarify that floating point
expressions may be rounded, including intermediate values.

This is a reworking of http://codereview.appspot.com/5577068/ .

Fixes issue 2789.

R=r, rsc, r, gri, ken, ken, iant
CC=golang-dev, remyoudompheng
http://codereview.appspot.com/5655049