* 'Axel Wagner' via golang-nuts <golang-nuts@googlegroups.com> [180112 05:11]: > Hm, this thread has actually opened up a question I don't have a good > answer to. > > On Fri, Jan 12, 2018 at 9:47 AM, <d...@veryhaha.com> wrote: > > an untyped interger literal/constant is representable float64 type for > > sure. > > an untyped floating-point literal/constant is representable complex128 > > type for sure. > > > > Now, this is where I don't have a good answer. The answer to both of these > is actually "no", but the compiler still allows it. > > For example, the integer constant (1<<54)+1 is not representable as a > float64, contradicting the first statement. > Also, the floating-point constant math.Pi is not representable as a float64 > and thus can't be represented by a complex128 either (as that has a float64 > real part). > In both cases, the compiler rounds to the nearest representable value, but > does not complain. I tried reading in the spec why exactly, but so far I > couldn't.
Perhaps the following explains the intent (found at https://golang.org/ref/spec#Constants): Implementation restriction: Although numeric constants have arbitrary precision in the language, a compiler may implement them using an internal representation with limited precision. That said, every implementation must: ∙ Represent integer constants with at least 256 bits. ∙ Represent floating-point constants, including the parts of a complex constant, with a mantissa of at least 256 bits and a signed binary exponent of at least 16 bits. ∙ Give an error if unable to represent an integer constant precisely. ∙ Give an error if unable to represent a floating-point or complex constant due to overflow. ∙ Round to the nearest representable constant if unable to represent a floating-point or complex constant due to limits on precision. These requirements apply both to literal constants and to the result of evaluating constant expressions. It seems that by "representable", when converting to a floating point type, the spec means "can be rounded to, but must not overflow". I think the last bullet makes this explicit (i.e. every implementation "must"...round to the nearest...). ...Marvin -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
