[go-nuts] fmt.Fprint or io.WriteString for http.ResponseWriter write?
Hi gophers! Is it better to (w is an http.ResponseWriter) fmt.Fprint(w, "Hello world") or to io.WriteString(w, "Hello world") or doesfmt.Fprint use io.WriteString behind the scenes, and thus they are equivalent? -- 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] Go App Engine 1.11 Multithreaded?
Hello Gophers! Does anybody know if the new Go 1.11 App Engine Standard Environment lift the 1 thread limit previously set for the first generation environment? Although Concurrency is not Parallelism, a little of both wouldn't hurt? ;) -- 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?
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.
[go-nuts] Re: Are Go floats smarter?
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.
[go-nuts] Re: Are Go floats smarter?
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.
[go-nuts] Re: Are Go floats smarter?
>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.
[go-nuts] Re: Are Go floats smarter?
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] Are Go floats smarter?
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.
