OMI OP en realidad no quieren np.bitwise_and()
(aka &
) pero en realidad quiere np.logical_and()
porque están comparando los valores lógicos como True
y False
- ver este SO publicar en logical vs. bitwise para ver la diferencia.
>>> x = array([5, 2, 3, 1, 4, 5])
>>> y = array(['f','o','o','b','a','r'])
>>> output = y[np.logical_and(x > 1, x < 5)] # desired output is ['o','o','a']
>>> output
array(['o', 'o', 'a'],
dtype='|S1')
Y equivale manera de hacerlo es con np.all()
estableciendo el argumento axis
adecuadamente.
>>> output = y[np.all([x > 1, x < 5], axis=0)] # desired output is ['o','o','a']
>>> output
array(['o', 'o', 'a'],
dtype='|S1')
por los números:
>>> %timeit (a < b) & (b < c)
The slowest run took 32.97 times longer than the fastest. This could mean that an intermediate result is being cached.
100000 loops, best of 3: 1.15 µs per loop
>>> %timeit np.logical_and(a < b, b < c)
The slowest run took 32.59 times longer than the fastest. This could mean that an intermediate result is being cached.
1000000 loops, best of 3: 1.17 µs per loop
>>> %timeit np.all([a < b, b < c], 0)
The slowest run took 67.47 times longer than the fastest. This could mean that an intermediate result is being cached.
100000 loops, best of 3: 5.06 µs per loop
así que usar np.all()
es más lento, pero &
y logical_and
son aproximadamente la misma.
Eso es bueno .. vecMask = 1
Ralf
omg esto es tan raro –
@JennyYueJin: Sucede debido a la precedencia. (Bitwise) '&' tiene una precedencia mayor que '<' and '>', que a su vez tienen una precedencia mayor que (lógico) 'y'. 'x> 1 yx <5' evacua las desigualdades primero y luego la conjunción lógica; 'x> 1 & x <5' evalúa la conjunción bit a bit de' 1' y (los valores en) 'x', luego las desigualdades. '(x> 1) & (x <5)' fuerza primero las desigualdades para evaluar, de modo que todas las operaciones se realizan en el orden deseado y los resultados están bien definidos. [Consulte los documentos aquí.] (Https://docs.python.org/3/reference/expressions.html#operator-precedence) – calavicci