Re: [go-nuts] Re: Are Go floats smarter?

[Dan Kortschak]

This is not much different. I is the same as

const c = 0.3 - 0.1*3

func BenchmarkUntypedConstants(b *testing.B) {
b.Log(0.3 - 0.1*3)
for i := 0; i < b.N; i++ {
z = c
}
}

On Sun, 2018-09-02 at 20:25 -0700, José Colón wrote:
> Yeah, after posting I realized that the compiler would probably be
> smart 
> enough to optimize that out, so I changed them to:
> 
> func BenchmarkUntypedConstants(b *testing.B) {
> var z float64
> for i := 0; i < b.N; i++ {
> z = 0.3 - 0.1*3
> }
> b.Log(z)
> }

-- 
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.

Re: [go-nuts] Re: Are Go floats smarter?

[José Colón]

Yeah, after posting I realized that the compiler would probably be smart 
enough to optimize that out, so I changed them to:

func BenchmarkUntypedConstants(b *testing.B) {
var z float64
for i := 0; i < b.N; i++ {
z = 0.3 - 0.1*3
}
b.Log(z)
}

func BenchmarkDecimalPackage(b *testing.B) {
var z *decimal.Big
for i := 0; i < b.N; i++ {
x := decimal.New(1, 1)
y := decimal.New(3, 0)
z = decimal.New(3, 1)
z.Sub(z, x.Mul(x, y))
}
b.Log(z)
}

BenchmarkUntypedConstants-8 20   0.29 ns/op
BenchmarkDecimalPackage-8500   256 ns/op

I guess the var declarations inside the loop for the decimal package 
consume some cycles, but anyway the difference is substantial. To be clear, 
my point here is not to demonstrate this decimal package (or any other 
similar) isn't a good option; but rather if the Go internal untyped 
constant code is that fast and easy to use, why not make it available for 
more general purposes (financial, scientific, etc..)?

On Sunday, September 2, 2018 at 9:27:46 PM UTC-4, kortschak wrote:
>
> This is not a benchmark of the untyped constant expression evaluation. 
> The expression in the loop is performed once and thrown away *at 
> compile time*. The benchmark here is really: 
>
> func BenchmarkUntypedConstants(b *testing.B) { 
> b.Log(0.3 - 0.1*3) 
> for i := 0; i < b.N; i++ { 
> } 
> } 
>
> On Sun, 2018-09-02 at 16:53 -0700, José Colón wrote: 
> > Maybe this comparison is completely wrong or unfair, but calculations 
> > with  
> > Go untyped constants is much faster than  
> > the github.com/ericlagergren/decimal package. In the end, they both 
> > produce  
> > the same correct answer: 0 . 
> > 
> > func BenchmarkUntypedConstants(b *testing.B) { 
> > b.Log(0.3 - 0.1*3) 
> > for i := 0; i < b.N; i++ { 
> >  _ = 0.3 - 0.1*3 
> > } 
> > } 
>

-- 
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.

Re: [go-nuts] Re: Are Go floats smarter?

[Dan Kortschak]

This is not a benchmark of the untyped constant expression evaluation.
The expression in the loop is performed once and thrown away *at
compile time*. The benchmark here is really:

func BenchmarkUntypedConstants(b *testing.B) {
b.Log(0.3 - 0.1*3)
for i := 0; i < b.N; i++ {
    }
}

On Sun, 2018-09-02 at 16:53 -0700, José Colón wrote:
> Maybe this comparison is completely wrong or unfair, but calculations
> with 
> Go untyped constants is much faster than 
> the github.com/ericlagergren/decimal package. In the end, they both
> produce 
> the same correct answer: 0 .
> 
> func BenchmarkUntypedConstants(b *testing.B) {
>     b.Log(0.3 - 0.1*3)
>     for i := 0; i < b.N; i++ {
>  _ = 0.3 - 0.1*3
>     }
> }

-- 
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.

[go-nuts] Re: Are Go floats smarter?

[José Colón]

Maybe this comparison is completely wrong or unfair, but calculations with 
Go untyped constants is much faster than 
the github.com/ericlagergren/decimal package. In the end, they both produce 
the same correct answer: 0 .

func BenchmarkUntypedConstants(b *testing.B) {
b.Log(0.3 - 0.1*3)
for i := 0; i < b.N; i++ {
 _ = 0.3 - 0.1*3
}
}


func BenchmarkDecimalPackage(b *testing.B) {
x := decimal.New(1, 1)
y := decimal.New(3, 0)
z := decimal.New(3, 1)
for i := 0; i < b.N; i++ {
z.Sub(z, x.Mul(x, y))
}
}


BenchmarkUntypedConstants-8 20   0.29 ns/op
BenchmarkDecimalPackage-8   2000   117 ns/op

On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>
> I read that a common way to demonstrate that floating point numbers suffer 
> from approximation problems is by calculating this: 
>
> 0.3 - 0.1 * 3
>
> which should produce 0 but in Java, Python, and Javascript for example, 
> they produce -5.551115123125783e-17 .
>
> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder why 
> is this so? Is it some higher precision being used versus these other 
> languages? Or is it some extra correcting logic behind the scenes?
>

-- 
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.

Re: [go-nuts] Re: Are Go floats smarter?

[Wojciech S. Czarnecki]

On Sun, 2 Sep 2018 15:54:08 -0700 (PDT)
José Colón  wrote:

> if a package that could provide similar ease of use in performing 
> infinite precision calculations would be a good idea

https://github.com/ericlagergren/decimal

It does not fit into stdlibs imo.

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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.

Re: [go-nuts] Re: Are Go floats smarter?

[Michael Jones]

for money there is a natural limit to the number of digits that are useful,
with certain exceptions

.
add to this the number of digits of fractional precision desired (4? 20?
whatever) and you end with a reasonably small byte size.

64 bit uint, taken as decimal gives you 18 decimal digits.
two of these with an implicit decimal point between high and low quadwords,
gives you 999 quadrillion dollars with inversely fine precision. basic math
ops will be 3x to 8x slower. all rounding will be perfectly and
understandably managed.

no need for arbitrary precision.

On Sun, Sep 2, 2018 at 3:54 PM José Colón  wrote:

> This thread is very similar to what you can find if you do a Web search
> for how to handle financial calculations. From my perspective, and like all
> matters in programming, the answer is "it depends". It depends on your
> goals; do you want the highest performance, the highest precision, comply
> with regulations, code readability / maintainability?  It all depends.
> Languages like Java and Python have their pre-built packages that make
> infinite precision calculations easy for the programmer, but at a
> performance penalty. My original question regarding Go floats, later
> learning that the behavior is not of floats but of untyped constants, makes
> me wonder if a package that could provide similar ease of use in performing
> infinite precision calculations would be a good idea to have in Go's
> standard library (like Java's BigDecimal or Python's decimal module). Or
> then again, maybe this is already provided by the math/big package?
>
>
> On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>>
>> I read that a common way to demonstrate that floating point numbers
>> suffer from approximation problems is by calculating this:
>>
>> 0.3 - 0.1 * 3
>>
>> which should produce 0 but in Java, Python, and Javascript for example,
>> they produce -5.551115123125783e-17 .
>>
>> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder
>> why is this so? Is it some higher precision being used versus these other
>> languages? Or is it some extra correcting logic behind the scenes?
>>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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.

[go-nuts] Re: Are Go floats smarter?

[José Colón]

This thread is very similar to what you can find if you do a Web search for 
how to handle financial calculations. From my perspective, and like all 
matters in programming, the answer is "it depends". It depends on your 
goals; do you want the highest performance, the highest precision, comply 
with regulations, code readability / maintainability?  It all depends. 
Languages like Java and Python have their pre-built packages that make 
infinite precision calculations easy for the programmer, but at a 
performance penalty. My original question regarding Go floats, later 
learning that the behavior is not of floats but of untyped constants, makes 
me wonder if a package that could provide similar ease of use in performing 
infinite precision calculations would be a good idea to have in Go's 
standard library (like Java's BigDecimal or Python's decimal module). Or 
then again, maybe this is already provided by the math/big package?


On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>
> I read that a common way to demonstrate that floating point numbers suffer 
> from approximation problems is by calculating this: 
>
> 0.3 - 0.1 * 3
>
> which should produce 0 but in Java, Python, and Javascript for example, 
> they produce -5.551115123125783e-17 .
>
> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder why 
> is this so? Is it some higher precision being used versus these other 
> languages? Or is it some extra correcting logic behind the scenes?
>

-- 
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.

Re: [go-nuts] Re: Are Go floats smarter?

[Michael Jones]

yes. another way to say it is that money is best considered integral in
terms of some chosen "minimum accounting unit" which in the case of USD
might be a dollar, a cent (1/100 dollar), or a finer thing, such as 1/100
or 1/1000 of a cent. This allows crossfooting to work, balances to zero,
and other critical financial expectations to be met even when computing
interest and other fractional matters.

On Fri, Aug 31, 2018 at 8:56 AM Ken MacDonald  wrote:

> Financial applications are, indeed, typically written using some sort of
> integer representation; some that I've worked with require smaller than
> "penny" level representations, say, for commodity pricing. I have seen
> accounting done with floating point. It didn't end well. One of the
> problems is that floating point operations are just "close enough" to LOOK
> correct a lot of the time, and print "correctly" when rounded off, but
> things like interest calculations leave one with very odd fractions of
> pennies that will cause very interesting problems that are not immediately
> obvious. For instance, I earn a bit of interest on my checking account, so
> the floating value stored in the DB is now something like $66.6579423452. I
> look at my statement and my balance prints as $66.66, so I write a check
> for 66.66, and when it's cashed I suddenly display a balance of -0.00, and
> have an overdraft charge. Historical note: I came into contact with the
> "floating accounting" project after it was nearly a year in progress, and
> pointed this out to them, and gave them simple examples to run to prove
> their stuff wouldn't work, and it didn't. They had spent an awful lot of
> money to get to that point, and re-engineering it would have cost a lot
> more - they tried that, but the project - and the company - eventually
> failed. Lesson: financial applications, and generally most applications
> that rely on discrete values, should NOT be written in floating point.
>
> On Thu, Aug 30, 2018 at 12:51 PM José Colón  wrote:
>
>> From what I've seen in the wild and searching for options on the Web,
>> using big integers to store the lowest denomination of any given currency
>> is very popular indeed, and I suspect ir should also perform better as a
>> bonus.
>>
>> On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>>>
>>> I read that a common way to demonstrate that floating point numbers
>>> suffer from approximation problems is by calculating this:
>>>
>>> 0.3 - 0.1 * 3
>>>
>>> which should produce 0 but in Java, Python, and Javascript for example,
>>> they produce -5.551115123125783e-17 .
>>>
>>> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder
>>> why is this so? Is it some higher precision being used versus these other
>>> languages? Or is it some extra correcting logic behind the scenes?
>>>
>> --
>> 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.
>>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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.

Re: [go-nuts] Re: Are Go floats smarter?

[Ken MacDonald]

Financial applications are, indeed, typically written using some sort of
integer representation; some that I've worked with require smaller than
"penny" level representations, say, for commodity pricing. I have seen
accounting done with floating point. It didn't end well. One of the
problems is that floating point operations are just "close enough" to LOOK
correct a lot of the time, and print "correctly" when rounded off, but
things like interest calculations leave one with very odd fractions of
pennies that will cause very interesting problems that are not immediately
obvious. For instance, I earn a bit of interest on my checking account, so
the floating value stored in the DB is now something like $66.6579423452. I
look at my statement and my balance prints as $66.66, so I write a check
for 66.66, and when it's cashed I suddenly display a balance of -0.00, and
have an overdraft charge. Historical note: I came into contact with the
"floating accounting" project after it was nearly a year in progress, and
pointed this out to them, and gave them simple examples to run to prove
their stuff wouldn't work, and it didn't. They had spent an awful lot of
money to get to that point, and re-engineering it would have cost a lot
more - they tried that, but the project - and the company - eventually
failed. Lesson: financial applications, and generally most applications
that rely on discrete values, should NOT be written in floating point.

On Thu, Aug 30, 2018 at 12:51 PM José Colón  wrote:

> From what I've seen in the wild and searching for options on the Web,
> using big integers to store the lowest denomination of any given currency
> is very popular indeed, and I suspect ir should also perform better as a
> bonus.
>
> On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>>
>> I read that a common way to demonstrate that floating point numbers
>> suffer from approximation problems is by calculating this:
>>
>> 0.3 - 0.1 * 3
>>
>> which should produce 0 but in Java, Python, and Javascript for example,
>> they produce -5.551115123125783e-17 .
>>
>> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder
>> why is this so? Is it some higher precision being used versus these other
>> languages? Or is it some extra correcting logic behind the scenes?
>>
> --
> 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.
>

-- 
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.

[go-nuts] Re: Are Go floats smarter?

[José Colón]

>From what I've seen in the wild and searching for options on the Web, using 
big integers to store the lowest denomination of any given currency is very 
popular indeed, and I suspect ir should also perform better as a bonus.

On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>
> I read that a common way to demonstrate that floating point numbers suffer 
> from approximation problems is by calculating this: 
>
> 0.3 - 0.1 * 3
>
> which should produce 0 but in Java, Python, and Javascript for example, 
> they produce -5.551115123125783e-17 .
>
> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder why 
> is this so? Is it some higher precision being used versus these other 
> languages? Or is it some extra correcting logic behind the scenes?
>

-- 
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.

Re: [go-nuts] Re: Are Go floats smarter?

[Marvin Renich]

* José Colón  [180830 06:53]:
> Very interesting. So would it be a good idea to use these types of untyped 
> constant calculations for financial applications, or instances where one 
> would use the math.big package?

Not likely.  You would have to know at compile time the exact values you
wanted to calculate, so you might as well not even write the program!

If you are writing financial applications or other applications where
rounding and/or precision are important, you must have a much more
thorough understanding of how the computer stores floating point values,
how calculations are performed, how results are represented in the
precision available, and how (and why) those results differ from the
exact values.

Simply learning that Java and Python have rounding errors and that using
Go's untyped constants give you the "human expected" results for some
simple examples is woefully insufficient to write correct floating point
code when such details are important.

On the other hand, there is a wide variety of programs that use floating
point values that don't need to worry about the rounding error in the
least significant bits.

As an example, if you had a set of coordinates, stored as floating point
numbers, representing a graphical figure, it is highly probable that you
could translate and scale those coordinates for display on the screen
without worrying about, or having a deep understanding of, rounding
errors.

...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.

[go-nuts] Re: Are Go floats smarter?

[José Colón]

Very interesting. So would it be a good idea to use these types of untyped 
constant calculations for financial applications, or instances where one 
would use the math.big package?

On Wednesday, August 29, 2018 at 10:33:16 PM UTC-4, José Colón wrote:
>
> I read that a common way to demonstrate that floating point numbers suffer 
> from approximation problems is by calculating this: 
>
> 0.3 - 0.1 * 3
>
> which should produce 0 but in Java, Python, and Javascript for example, 
> they produce -5.551115123125783e-17 .
>
> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder why 
> is this so? Is it some higher precision being used versus these other 
> languages? Or is it some extra correcting logic behind the scenes?
>

-- 
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.

[go-nuts] Re: Are Go floats smarter?

[Tristan Rice]

I believe this is because that expression is handled as an untyped constant 
by the compiler. If you actually create proper variables with the values 
you get the same result as Java, Python, etc.

https://play.golang.org/p/tIMpYT-bFzm

On Wednesday, August 29, 2018 at 7:33:16 PM UTC-7, José Colón wrote:
>
> I read that a common way to demonstrate that floating point numbers suffer 
> from approximation problems is by calculating this: 
>
> 0.3 - 0.1 * 3
>
> which should produce 0 but in Java, Python, and Javascript for example, 
> they produce -5.551115123125783e-17 .
>
> Surprisingly (or not, ;) ), Go produces the correct 0 result! I wonder why 
> is this so? Is it some higher precision being used versus these other 
> languages? Or is it some extra correcting logic behind the scenes?
>

-- 
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.