python - tangente - Sinusoidal órdenes de magnitud más lentas que el coseno

serie de seno en python

Question

tl; dr

De la misma matriz numpy , el cálculo de np.cos toma 3.2 segundos, mientras que np.sin ejecuta 548 segundos (nueve minutos) en Linux Mint.

Ver este repositorio para el código completo.

Tengo una señal de pulso (vea la imagen a continuación) que necesito modular en un portador de HF, simulando un vibrómetro Doppler láser . Por lo tanto, la señal y su base de tiempo deben volver a muestrearse para coincidir con la mayor tasa de muestreo del operador.

En el siguiente proceso de demodulación se necesitan tanto el cos(omega * t) en la fase cos(omega * t) como el sin(omega * t) portadora de desplazamiento de fase sin(omega * t) . Curiosamente, el tiempo para evaluar estas funciones depende en gran medida de la forma en que se ha calculado el vector de tiempo.

El vector de tiempo t1 se calcula utilizando np.linspace directamente, t2 usa el método implementado en scipy.signal.resample .

pulse = np.load(''data/pulse.npy'')  # 768 samples

pulse_samples = len(pulse)
pulse_samplerate = 960  # 960 Hz
pulse_duration = pulse_samples / pulse_samplerate  # here: 0.8 s
pulse_time = np.linspace(0, pulse_duration, pulse_samples,
                         endpoint=False)

carrier_freq = 40e6  # 40 MHz
carrier_samplerate = 100e6  # 100 MHz
carrier_samples = pulse_duration * carrier_samplerate  # 80 million

t1 = np.linspace(0, pulse_duration, carrier_samples)

# method used in scipy.signal.resample
# https://github.com/scipy/scipy/blob/v0.17.0/scipy/signal/signaltools.py#L1754
t2 = np.arange(0, carrier_samples) * (pulse_time[1] - pulse_time[0]) /
        * pulse_samples / float(carrier_samples) + pulse_time[0]

Como se puede ver en la siguiente imagen, los vectores de tiempo no son idénticos. Con 80 millones de muestras, la diferencia t1 - t2 alcanza 1e-8 .

El cálculo de la portadora en fase y desplazada de t1 toma 3,2 segundos cada uno en mi máquina.
Sin embargo, con t2 , el cálculo de la portadora desplazada lleva 540 segundos . Nueve minutos. Por casi los mismos 80 millones de valores.

omega_t1 = 2 * np.pi * carrier_frequency * t1
np.cos(omega_t1)  # 3.2 seconds
np.sin(omega_t1)  # 3.3 seconds

omega_t2 = 2 * np.pi * carrier_frequency * t2
np.cos(omega_t2)  # 3.2 seconds
np.sin(omega_t2)  # 9 minutes

Puedo reproducir este error tanto en mi computadora portátil de 32 bits como en mi torre de 64 bits, ambas con Linux Mint 17 . En el MacBook de mi compañero de piso, sin embargo, el "seno lento" toma tan poco tiempo como los otros tres cálculos.

Ejecuto un Linux Mint 17.03 en un procesador AMD de 64 bits y Linux Mint 17.2 en un procesador Intel de 32 bits.

Answer 1

No creo que numpy tenga nada que ver con esto: creo que te estás tropezando con un error de rendimiento en la biblioteca matemática de C en tu sistema, uno que afecta el pecado cerca de los múltiplos grandes de pi. (Estoy utilizando "error" en un sentido bastante amplio aquí - por lo que sé, ya que el seno de las flotaciones grandes está mal definido, ¡el "error" es en realidad la biblioteca que se comporta correctamente para manejar casos de esquina!)

En Linux, me sale:

>>> %timeit -n 10000 math.sin(6e7*math.pi)
10000 loops, best of 3: 191 µs per loop
>>> %timeit -n 10000 math.sin(6e7*math.pi+0.12)
10000 loops, best of 3: 428 ns per loop

y otros tipos de uso de Linux del informe de la sala de chat de Python

10000 loops, best of 3: 49.4 µs per loop 
10000 loops, best of 3: 206 ns per loop

y

In [3]: %timeit -n 10000 math.sin(6e7*math.pi)
10000 loops, best of 3: 116 µs per loop

In [4]: %timeit -n 10000 math.sin(6e7*math.pi+0.12)
10000 loops, best of 3: 428 ns per loop

pero un usuario de Mac informó

In [3]: timeit -n 10000 math.sin(6e7*math.pi)
10000 loops, best of 3: 300 ns per loop

In [4]: %timeit -n 10000 math.sin(6e7*math.pi+0.12)
10000 loops, best of 3: 361 ns per loop

para ninguna diferencia de orden de magnitud. Como solución, puede intentar tomar las cosas mod 2 pi primero:

>>> new = np.sin(omega_t2[-1000:] % (2*np.pi))
>>> old = np.sin(omega_t2[-1000:])
>>> abs(new - old).max()
7.83773902468434e-09

que tiene mejor rendimiento:

>>> %timeit -n 1000 new = np.sin(omega_t2[-1000:] % (2*np.pi))
1000 loops, best of 3: 63.8 µs per loop
>>> %timeit -n 1000 old = np.sin(omega_t2[-1000:])
1000 loops, best of 3: 6.82 ms per loop

Tenga en cuenta que, como se esperaba, un efecto similar ocurre para cos , simplemente se desplaza:

>>> %timeit -n 1000 np.cos(6e7*np.pi + np.pi/2)
1000 loops, best of 3: 37.6 µs per loop
>>> %timeit -n 1000 np.cos(6e7*np.pi + np.pi/2 + 0.12)
1000 loops, best of 3: 2.46 µs per loop

Answer 2

Una posible causa de estas enormes diferencias de rendimiento podría ser la forma en que la biblioteca matemática crea o maneja el subdesbordamiento de punto flotante de IEEE (o denorms), que puede producirse por una diferencia de algunos de los bits de mantisa más pequeños durante la aproximación de la función trascendental. Y sus vectores t1 y t2 pueden diferir en estos bits de mantisa más pequeños, así como en el algoritmo utilizado para calcular la función trascendental en las bibliotecas que haya enlazado, así como las denorms aritméticas IEEE o el controlador de flujo insuficiente en cada sistema operativo en particular.