¿BUG de parseo en GNUPLOT?

Pues eso... esta gilipollez lleva toda la tarde volviéndome loco. Es miopía mía, o se trata de un bug de parseo en gnuplot?

La siguiente expresión produce un resultado incorrecto:

t=1
lx=5
ly=5
b=1

splot 0.5*sin(pi*y/ly)*exp(-b*pi*pi*t/(ly*ly))-0.5*sin(pi*y/ly)*cos(2*pi*x/lx)*exp(-b*(1/(ly*ly)+4/(lx*lx))*pi*pi*t)

Pero si reescribimos los denominadores en el exponente como:

splot 0.5*sin(pi*y/ly)*exp(-b*pi*pi*t*(ly**(-2)))-0.5*sin(pi*y/ly)*cos(2*pi*x/lx)*exp(-b*((ly**(-2))+4*(lx**(-2)))*pi*pi*t)

Se ve que las dos expresiones son matemáticamente equivalentes

Entonces sí que obtenemos el resultado adecuado. ¿Alguien lo puede confirmar?
splot 0.5*sin(pi*y/ly)*exp(-b*pi*pi*t/(ly*ly))-0.5*sin(pi*y/ly)*cos(2*pi*x/lx)*exp(-b*(1/(ly*ly)+4/(lx*lx))*pi*pi*t)

splot 0.5*sin(pi*y/ly)*exp(-b*pi*pi*t*(ly**(-2)))-0.5*sin(pi*y/ly)*cos(2*pi*x/lx)*exp(-b*((ly**(-2))+4*(lx**(-2)))*pi*pi*t)

No son equivalentes o no me entero XD hay mas sustituyes ly = -2 ?
pero en el primero vale ly = 1
en gnuplot, cuando haces x**2 estas elevando x al cuadrado.

1/(lx*lx) sería lo mismo que poner lx**(-2), o sea: lx elevado a -2

EDITO: Más sencillo de comprobar

plot exp(((ly**(-2))+4*(lx**(-2)))*x) --------------> BIEN
plot exp((1/(ly*ly)+4/(lx*lx))*x) --------------> MAL

Oh, pollas.... He encontrado la causa. Se trata del redondeo debido a que lx e ly sean números enteros.

Con lx=5 falla. Pero con lx=5.0 funciona bien.

Realmente no es un bug, sino una feature un poco oscura, ocultada a través del uso de variables. Niños! acordaos de definir bien vuestros enteros!
2 respuestas