Re: [go-nuts] Rounding on conversion from float64 to uint64

[minux]

On Fri, Jul 6, 2012 at 1:30 AM, <doug...@rbcon.com> wrote:

It seems that when the uint64() conversion is used on a float, it actually rounds the result to the nearest integer instead of truncating it towards zero.

Essentially, this code (reproducible on the online Go tour):

func main() {

    fp := float64(49.5)
    fmt.Println(int64(fp), uint32(fp), uint64(fp), fp)
}

prints: 49 49 50 49.5

I can't imagine why this behavior might be there though. Any insights, or just a bug?

according to the spec:

When converting a floating-point number to an integer, the fraction is discarded (truncation towards zero).

i think this is bug.

[minux]

curiously, only float64->uint64 conversion exhibits this rounding behavior:

http://play.golang.org/p/OXtuDyEfBm

[Dave Cheney]

quantal(~/src) % uname -a
Linux quantal 3.4.0-202-omap4 #7-Ubuntu SMP PREEMPT Thu Jun 28
19:53:47 UTC 2012 armv7l armv7l armv7l GNU/Linux
quantal(~/src) % go run float.go
39 39 39 39 39.7

And doesn't happen on arm

[minux]

On Fri, Jul 6, 2012 at 3:13 AM, Dave Cheney <da...@cheney.net> wrote:

quantal(~/src) % uname -a
Linux quantal 3.4.0-202-omap4 #7-Ubuntu SMP PREEMPT Thu Jun 28
19:53:47 UTC 2012 armv7l armv7l armv7l GNU/Linux
quantal(~/src) % go run float.go
39 39 39 39 39.7

And doesn't happen on arm

Problem found (only on amd64):

we use CVTSD2SQ to convert float64 to uint64, but its behavior is rounding instead of

truncating, and we should use CVTTSD2SQ (I think this is a typo).

the problem is, should we fix this? some Go 1 program might rely on this (albeit

wrong) behavior.

I've got a quick fix for 6g ready, but I'm not sure what to do.

http://codereview.appspot.com/6352079 (no tests, so not for review now)

[Dave Cheney]

I think you log an issue. If this becomes contentious it would be
useful to be able to direct people to an issue number, rather than a
mailing list thread.

[minux]

On Fri, Jul 6, 2012 at 3:40 AM, Dave Cheney <da...@cheney.net> wrote:

I think you log an issue. If this becomes contentious it would be
useful to be able to direct people to an issue number, rather than a
mailing list thread.

Done.

http://code.google.com/p/go/issues/detail?id=3804 

[Jesse McNelis]

On Fri, Jul 6, 2012 at 5:38 PM, minux <minu...@gmail.com> wrote:

> the problem is, should we fix this? some Go 1 program might rely on this
> (albeit wrong) behavior.

Any code relying on this behaviour is already broken.

"Bugs. If a compiler or library has a bug that violates the
specification, a program that depends on the buggy behavior may break
if the bug is fixed. We reserve the right to fix such bugs."
http://golang.org/doc/go1compat.html

> I've got a quick fix for 6g ready, but I'm not sure what to do.
> http://codereview.appspot.com/6352079 (no tests, so not for review now)

--
=====================
http://jessta.id.au

[Dave Cheney]

Excellent. Sorry my previous reply should have read 'I think you should log an issue'

[minux]

On Fri, Jul 6, 2012 at 3:50 AM, Jesse McNelis <jes...@jessta.id.au> wrote:

On Fri, Jul 6, 2012 at 5:38 PM, minux <minu...@gmail.com> wrote:

> the problem is, should we fix this? some Go 1 program might rely on this
> (albeit wrong) behavior.

Any code relying on this behaviour is already broken.

"Bugs. If a compiler or library has a bug that violates the
specification, a program that depends on the buggy behavior may break
if the bug is fixed. We reserve the right to fix such bugs."
http://golang.org/doc/go1compat.html

I agree. After I put up a test for that, will submit that CL for review.