You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! Based on my experience using Go, there are certain inconveniences associated with the implementation of some functions from the math package. And if earlier it was clear that there were no changes in this package due to the fact that generic functionality was expected, now it looks like nothing prevents us from starting to replace the implementation of some functions. In particular, Abs(), which is often used in the practice of solving individual problems, for example, when learning a language or just try to get a star on "advent of code" =).
All of us know: we could implement someting we need ourselves, but it's really nice not having to think about implementing simple things.
I did a little research on the question and came up with something like this implementation:
funcAbs[T~int|~int8|~int16|~int32|~int64|~float32|~float64](xT) T {
ifx<0 {
return-x
}
returnx
}
and even write a simple benchmark to compare this with current implementation in the math package:
goos: linux
goarch: amd64
pkg: proposal-abs
cpu: Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz
BenchmarkAbsInt64-4 213823255 56.11 ns/op
BenchmarkAbsFloat64-4 211663220 57.91 ns/op
BenchmarkAbsCurrentImplementationFloat64-4 168030234 66.26 ns/op
PASS
ok proposal-abs 35.468s
It's wokrs the same on my opinion on my platform. So, how about include something like that in the math package? Or am I missing something? And also it's possible to make this implementation (and changes like this) much prettier if include "golang.org/x/exp/constraints" in the builtin package.
The text was updated successfully, but these errors were encountered:
Proposal Details
Hello! Based on my experience using Go, there are certain inconveniences associated with the implementation of some functions from the math package. And if earlier it was clear that there were no changes in this package due to the fact that generic functionality was expected, now it looks like nothing prevents us from starting to replace the implementation of some functions. In particular, Abs(), which is often used in the practice of solving individual problems, for example, when learning a language or just try to get a star on "advent of code" =).
I found several issues related indirectly and directly to this problem:
proposal: math: add package math/ints for common operations on integers #41157
proposal: math: add Float, Integer, Complex, Number interfaces #61914
All of us know: we could implement someting we need ourselves, but it's really nice not having to think about implementing simple things.
I did a little research on the question and came up with something like this implementation:
and even write a simple benchmark to compare this with current implementation in the math package:
It's wokrs the same on my opinion on my platform. So, how about include something like that in the math package? Or am I missing something? And also it's possible to make this implementation (and changes like this) much prettier if include "golang.org/x/exp/constraints" in the builtin package.
The text was updated successfully, but these errors were encountered: