On Thu, Apr 22, 2021 at 11:54 AM 'Dan Kortschak' via golang-nuts < golang-nuts@googlegroups.com> wrote:
> > Does anyone know the reason for this? (Looking through other languages, > the situation in general seems to be a mess). > > I looked at OCaml, which provides both variants: Float.max : float -> float -> float Float.max_num : float -> float -> float The `max` function includes NaNs in the computation, while `max_num` omits them. Another important treatment the documentation mentions is `max -0.0 +0.0`. I also looked at Matlab and R. They essentially provide ways to either include the NaN or omit it from the computation, usually when you have a vector of numbers where some of the numbers are unknown. I.e., they take extra (optional) flags to their functions which tells you how to treat NaN values. The "pure" solution is clearly the one where NaN's yield a NaN. It is isomorphic to a Monoid based on optional values with the NaN forming the unknown element, often called the option-monoid or the maybe-monoid. Or said otherwise: for any type a, where a is a monoid, so is 'option a': forall a. Monoid a => Monoid (Option a) Since the max function itself is a monoid with the neutral element taken as the minimal value, -inf, we can thus "lift" NaN values on top and still have some mathematical consistency. But if you have an array of values, where some of them can be NaN, it is probably smart to provide a function which filters the array of NaN values and computes the remaining values. R provides the function `na.omit(..)` for this. So do option types in languages such as OCaml or Haskell. Here, we are not that concerned about what is sound from a formal point of view, but more concerned with data cleanup before we start using the formality. Max of two values is a special case. The generalized version takes an array/vector of values and provides the maximum in the structure. All of this leads me to conclude you probably want both variants in the end. In some situations, it is better to include NaN values in the computation, and in other situations, the right move is to omit/exclude them. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiWw4HpXhG7WzU4dobVP5ai4XPAwJ3r%2BQ--RD9W-Ket%3Dbw%40mail.gmail.com.
