Not only did they not stop the shooter, but they actively prevented parents—who were willing to risk their lives—from intervening. They didn't just not help, they proactively ran interference for the shooter.

1. Still just as heavy. The AirPods Max sound quite good, but they are very heavy, to the point of being fairly uncomfortable after listening for any longer amount of time. This release as the exact same weight as the originals (13.6 oz).

2. Still no off button/position. They stay partially on unless you put them in the awkward and useless "case", which means they're constantly out of power when you want to use them. There's even an obvious fix: the ear cups swivel flat, they could just make this the "power off" position. Solved. But they didn't, so presumably these still have the same problem. There's also no mention of magnetic charging via stand, which would be another way to help alleviate this problem.

If these were even a few ounces lighter and powered off properly, I would buy them for sure. Given this announcement, I guess I will look for something else to replace the old AirPods Max.

The only very marginal exception to this is that when both arguments are NaN, the return value will be NaN, but which NaN payload is returned can depend on argument order. But no one ever uses this because it's not specified, so it can't be used reliably for anything useful. The behavior I wish IEEE 754 had specified for this is to define a standard NaN value (or two), and when the return value of an op is NaN, and some of the arguments are non-standard NaNs, then one of those non-standard NaN values must be returned. This doesn't depend on argument order and allows NaN payloads to be reliably propagated, which would let you encode useful debugging information in NaN payloads and know that it will flow through the program.

Double dispatch feels like kind of a hack, tbh, but it is easier to implement and would certainly be an improvement over Python's awkward `__add__` and `__radd__` methods.

[1] https://janvitek.org/pubs/oopsla18b.pdf

- RoundNearest

- RoundNearestTiesAway

- RoundNearestTiesUp

- RoundToZero — rem, div

- RoundFromZero

- RoundUp

- RoundDown — mod, fld (i.e. floor(x/y) but without incorrect corner cases)

Most languages have no way of doing most of these, but then again, they're mostly pretty useless. They're really only useful when you're pairing division with a specific kind of rounding with a remainder that needs to match. Example of whacky remainder behavior in the "familiar" RoundNearest mode (default rounding mode for floating point):

    julia> [k => rem(k, 4, RoundNearest) for k=-6:6]
    13-element Vector{Pair{Int64, Int64}}:
     -6 =>  2
     -5 => -1
     -4 =>  0
     -3 =>  1
     -2 => -2
     -1 => -1
      0 =>  0
      1 =>  1
      2 =>  2
      3 => -1
      4 =>  0
      5 =>  1
      6 => -2