Re: [go-nuts] floating point question

2019-04-16 Thread Robert Johnstone
There are multiple bit-representations for NaN, so even then, you can't compare for equality. On Monday, 15 April 2019 12:59:28 UTC-4, David Riley wrote: > > On Apr 15, 2019, at 12:47 PM, Miki Tebeka > wrote: > > > > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: > > > >

Re: [go-nuts] floating point question

2019-04-16 Thread Michael Jones
These "floating-point is weird" discussions tend to be unfair to the virtues of floating point. ;-) The numbers in computers are NOT the numbers of mathematics. They do not have the same properties, promises, and definitions. So instead of shaking our fists at the computer when we're reminded of

Re: [go-nuts] floating point question

2019-04-16 Thread David Riley
On Apr 16, 2019, at 2:29 AM, Miki Tebeka wrote: >> >> On Monday, April 15, 2019 at 7:59:28 PM UTC+3, David Riley wrote: >> On Apr 15, 2019, at 12:47 PM, Miki Tebeka wrote: >> > >> > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: >> > >> > 1.1*1.1 and 1.21 are untyped

Re: [go-nuts] floating point question

2019-04-16 Thread Miki Tebeka
I came across this when teaching about floats not being exact, was surprised to see the "true" :) On Monday, April 15, 2019 at 7:59:28 PM UTC+3, David Riley wrote: > > On Apr 15, 2019, at 12:47 PM, Miki Tebeka > wrote: > > > > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: >

Re: [go-nuts] floating point question

2019-04-16 Thread Miki Tebeka
Thanks! On Monday, April 15, 2019 at 7:51:05 PM UTC+3, Jan Mercl wrote: > > > > On Mon, Apr 15, 2019 at 6:47 PM Miki Tebeka > wrote: > > > Does that mean that the Go compiler is using floats with more precision > than the runtime? > > Absolutely: https://golang.org/ref/spec#Constants > >

Re: [go-nuts] floating point question

2019-04-15 Thread Kurtis Rader
On Mon, Apr 15, 2019 at 2:19 AM Miki Tebeka wrote: > Can anyone explain the below? > (When printing out b with %.20f it prints 1.20996447) > > package main > > import "fmt" > > func main() { > a, b := 1.1*1.1, 1.21 > fmt.Println(a == b) // true > fmt.Println(1.1*1.1 == 1.21)

Re: [go-nuts] floating point question

2019-04-15 Thread David Riley
On Apr 15, 2019, at 12:47 PM, Miki Tebeka wrote: > > On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: > > 1.1*1.1 and 1.21 are untyped constants and have much higher precision at > which they are not equal. > Does that mean that the Go compiler is using floats with more

Re: [go-nuts] floating point question

2019-04-15 Thread Jan Mercl
On Mon, Apr 15, 2019 at 6:47 PM Miki Tebeka wrote: > Does that mean that the Go compiler is using floats with more precision than the runtime? Absolutely: https://golang.org/ref/spec#Constants Represent integer constants with at least 256 bits. Represent floating-point constants,

Re: [go-nuts] floating point question

2019-04-15 Thread Miki Tebeka
On Monday, April 15, 2019 at 2:12:18 PM UTC+3, Jan Mercl wrote: 1.1*1.1 and 1.21 are untyped constants and have much higher precision at > which they are not equal. > Does that mean that the Go compiler is using floats with more precision than the runtime? -- You received this message

Re: [go-nuts] floating point question

2019-04-15 Thread Jan Mercl
On Mon, Apr 15, 2019 at 11:19 AM Miki Tebeka wrote: > Can anyone explain the below? a and b have 64b precision and they are assigned the same value, after that value is rounded to the lower precision. 1.1*1.1 and 1.21 are untyped constants and have much higher precision at which they are not

[go-nuts] floating point question

2019-04-15 Thread Miki Tebeka
Hi, Can anyone explain the below? (When printing out b with %.20f it prints 1.20996447) Thanks package main import "fmt" func main() { a, b := 1.1*1.1, 1.21 fmt.Println(a == b) // true fmt.Println(1.1*1.1 == 1.21) // false } -- You received this message because you