[morelisp]

Zero is gracefully handled; the mean of a zero-sized set is best represented by NaN, and this would be idiomatic in most languages' IEEE754-style handling.

Saturation is not. This is what really bugs me: If I'm going to drag in a billion GPUs of external computation (or a dependency, which is basically the same thing but with human brains), I want it to provide the hard algorithm I can't write, not the easy one I can. I am not limited by typing speed.

I also wonder what a "detection" is.

[julian37]

Agreed about saturation and the choice of variable name, but the code would trigger a division by zero and not result in NaN: https://go.dev/play/p/vYm4tSNEJ7M

(Also, in--say--Ruby and JavaScript 1.0/0.0 is Infinity and not NaN.)

[morelisp]

Your playground link shows a build error. 0.0/0.0 at runtime will be NaN. And in basically every language, 1.0/0.0 is Infinity. But we're talking about 0.0/0.0.

Both good examples of coding where you should be thinking instead, though.

[matthewmacleod]

I think if anything there is far too much thinking going on here, for the tiny example I copied from the window I literally already had open with the function I was working on.

For what it's worth, Copilot (correctly) inferred a loop variable called "detection", I imagine based on similar usage earlier in the function. And there is already a conditional in place to prevent invalid operations; if I remove it I see a new suggestion:

  if len(filtered) > 0 {

This tool is far from perfect, but it very much sounds like you folks haven't used it. If that's the case, I would encourage you to research it like all tooling and draw some informed conclusions about it's applicability instead of making assumptions.