3 ms·

Huh, I'm glad to see generic Min/Max functions, but the fact that they're built-ins is a little odd to me. I would have expected them to put a generic math libr

by Hakkin 3y ago

Huh, I'm glad to see generic Min/Max functions, but the fact that they're built-ins is a little odd to me. I would have expected them to put a generic math library into the stdlib instead. The fact the stdlib math package only works with float64s has always struck me as a poorly thought out decision.

klodolph 3y ago
Making them builtins allows them to work as you’d expect with cases like, func clamp(x float64) float64 { return max(0, min(1, x)) } With ordinary functions, the arguments are assigned types too soon, and you get integer types for 0 and 1 in the above code. In C++ you might make the types explicit: template<typename T> T clamp(T x) { return std::max<T>(0, std::min<T>(1, x)); } That’s not meant to be exactly the way you’d write these functions, but just a little bit of sample code to show how the typing is different.
- Hakkin 3y ago
  That doesn't seem to be true, unless I'm misunderstanding something. https://go.dev/play/p/ymM0tD3aGYg?v=gotip https://go.dev/play/p/ymM0tD3aGYg?v=gotip Obviously these sample functions don't take into account all the intricacies of float min/max functions.
  - klodolph 3y ago
    You can const x = min(a, b) assuming a and b are const.
    - onionisafruit 3y ago
      I can't think of a use case for that. If all the inputs are consts, then you know the values and can just assign it to be the less of a or b. Am I missing something here?
      - nordsieck 3y ago
        > I can't think of a use case for that. It helps to document intent. Probably not so useful for min, but it can be more useful for more complex functions.
      - klodolph 3y ago
        Const are build-time constants, they are not necessarily the same value across all build configurations.
        onionisafruit 3y ago
        That’s a good point.
tjalfi 3y ago
The proposal[0] gives a rationale. Using builtin functions lets them be variadic without allocating a slice. [0] https://github.com/golang/go/issues/59488 https://github.com/golang/go/issues/59488
- morelisp 3y ago
  While I suspect open coding may make the optimization a little easier, there's no reason it couldn't optimize out a slice and fixed 2-3 iteration loop with the same result. The proposal's real conclusion was "the decision cannot be resolved by empirical data or technical arguments."
tinco 3y ago
What sort of use case do you see for non-float64 math operations in a Go application?
- tedunangst 3y ago
  Float32 is pretty popular in graphics.
- Hakkin 3y ago
  Well, the obvious ones are of course Min and Max functions, which is resolved with this. Other ones I commonly find myself wanting to use with integers would be math.Abs and math.Pow I guess. Otherwise they are mostly functions useful with floats, so ultimately I understand the logic, though even in that case, it would be nice if they were usable with float32s as well without casting back and forth. Personally I try to avoid using floats for calculations if I can (unless it's obviously warranted), I've encountered far too many foot guns from using them, though honestly the same can be said about integers in some situations too. I wish there was a package like math/big that was more accessible, I find the current interface for it pretty abysmal.

by Hakkin 3y ago

klodolph 3y ago

Making them builtins allows them to work as you’d expect with cases like, func clamp(x float64) float64 { return max(0, min(1, x)) } With ordinary functions, the arguments are assigned types too soon, and you get integer types for 0 and 1 in the above code. In C++ you might make the types explicit: template<typename T> T clamp(T x) { return std::max<T>(0, std::min<T>(1, x)); } That’s not meant to be exactly the way you’d write these functions, but just a little bit of sample code to show how the typing is different.

Hakkin 3y ago
That doesn't seem to be true, unless I'm misunderstanding something. https://go.dev/play/p/ymM0tD3aGYg?v=gotip https://go.dev/play/p/ymM0tD3aGYg?v=gotip Obviously these sample functions don't take into account all the intricacies of float min/max functions.
- klodolph 3y ago
  You can const x = min(a, b) assuming a and b are const.
  - onionisafruit 3y ago
    I can't think of a use case for that. If all the inputs are consts, then you know the values and can just assign it to be the less of a or b. Am I missing something here?
    - nordsieck 3y ago
      > I can't think of a use case for that. It helps to document intent. Probably not so useful for min, but it can be more useful for more complex functions.
    - klodolph 3y ago
      Const are build-time constants, they are not necessarily the same value across all build configurations.
      - onionisafruit 3y ago
        That’s a good point.

tjalfi 3y ago

The proposal[0] gives a rationale. Using builtin functions lets them be variadic without allocating a slice. [0] https://github.com/golang/go/issues/59488 https://github.com/golang/go/issues/59488

morelisp 3y ago
While I suspect open coding may make the optimization a little easier, there's no reason it couldn't optimize out a slice and fixed 2-3 iteration loop with the same result. The proposal's real conclusion was "the decision cannot be resolved by empirical data or technical arguments."

tinco 3y ago

What sort of use case do you see for non-float64 math operations in a Go application?

tedunangst 3y ago
Float32 is pretty popular in graphics.
Hakkin 3y ago
Well, the obvious ones are of course Min and Max functions, which is resolved with this. Other ones I commonly find myself wanting to use with integers would be math.Abs and math.Pow I guess. Otherwise they are mostly functions useful with floats, so ultimately I understand the logic, though even in that case, it would be nice if they were usable with float32s as well without casting back and forth. Personally I try to avoid using floats for calculations if I can (unless it's obviously warranted), I've encountered far too many foot guns from using them, though honestly the same can be said about integers in some situations too. I wish there was a package like math/big that was more accessible, I find the current interface for it pretty abysmal.