Bitwise methods about proposal-math-extensions HOT 4 OPEN

example: https://gist.github.com/missinglink/59d4ddb377c9f3a08365cffa6a5ec052

function trailingZeros64(a) {
  for(let i=7; i>=0; i--) {
    let lsb = (a[i]) & (-a[i])
    if(lsb > 0) {
      return (32 - 1 - Math.clz32(lsb)) + ((7-i) * 8)
    }
  }
  return 64
}

trailingZeros64([0xff, 0xff, 0xff, 0xff, 0xf0, 0x00, 0x00, 0x00])

from proposal-math-extensions.

Should there also be clo32 and cto32? (Leading and Trailing 1s, respectively). What about popcount32 (Hamming Weight, AKA Bit Sum) and rev32 (reverse 32bit register, reflecting around its absolute center)?

What about non 32bit bitwise functions? Popcount can be implemented internally by doing popcnt on the mantissa and adding 1 (implicit bit). CTZ can be defined as trial division by 2 (internally implemented by exponent masking), it can also be defined for non-int values by returning negative ints that correspond to the 0s after the radix point, like this CTZ(0b0.1) = CTZ(0b1.1) = -1 && CTZ(0b0.01) = -2 && CTZ(0b0.00101) = CTZ(0b0.001) = -3.

The reverse fn would be implemented using a relative axis of reflection, so the flip point would depend on the binary logarithm of the input. The rev32 fn could have a "Byte mode" instead of "bit mode", therefore becoming a big-to-little (and viceversa) endianess converter, although that seems useless for a high-level lang, except when working with an ArrayBuffer and many Views.

By adding these extended methods that aren't restricted to int32s, they can be compatible with both Numbers and BigInts when the BigInt Math proposal gets to Stage 4 (if it actually takes the path of polymorphism, instead of dedicated methods on a different namespace)

from proposal-math-extensions.

What about Math.clmul32? (carryless multiply)

from proposal-math-extensions.

@missinglink That's an interesting implementation! But I'm afraid it won't be accepted by tc39, as it lacks consistency with the existing standards

from proposal-math-extensions.