Hacker News Reader

Comment by Hakkin | Hacker News Reader

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.

View on HN

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.

That doesn't seem to be true, unless I'm misunderstanding something. 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.

You can

    const x = min(a, b)

assuming a and b are const.

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?

Const are build-time constants, they are not necessarily the same value across all build configurations.

That’s a good point.

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

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

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

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

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.

Float32 is pretty popular in graphics.

Reply on news.ycombinator.com