python - solving - sympy tutorial
Usar "from__future__ import division" en mi programa, pero no está cargado con mi programa (2)
Escribí el siguiente programa en Python 2 para hacer los cálculos del método de Newton para mi conjunto de problemas matemáticos, y aunque funciona perfectamente, por razones desconocidas para mí, cuando lo cargué inicialmente en ipython con %run -i NewtonsMethodMultivariate.py
, el Python 3 La división no se importa. Lo sé porque después de cargar mi programa Python, al ingresar x**(3/4)
aparece "1". Después de importar manualmente la nueva división, entonces x**(3/4)
permanece x**(3/4)
, como se esperaba. ¿Por qué es esto?
# coding: utf-8
from __future__ import division
from sympy import symbols, Matrix, zeros
x, y = symbols(''x y'')
X = Matrix([[x],[y]])
tol = 1e-3
def roots(h,a):
def F(s):
return h.subs({x: s[0,0], y: s[1,0]})
def D(s):
return h.jacobian(X).subs({x: s[0,0], y: s[1,0]})
if F(a) == zeros((2,1)):
return a
else:
while (F(a)).norm() > tol:
a = a - ((D(a))**(-1))*F(a)
print a.evalf(10)
Usaría Python 3 para evitar este problema, pero mi distribución de Linux solo incluye SymPy para Python 2. Gracias a la ayuda que cualquiera puede proporcionar.
Además, en caso de que alguien se estuviera preguntando, aún no he generalizado este script para nxn jacobianos, y solo tuve que lidiar con 2x2 en mi conjunto de problemas. Además, estoy cortando la matriz cero 2x2 en lugar de usar los zeros(2,1)
comando zeros(2,1)
porque SymPy 0.7.1, instalado en mi máquina, se queja de que "ceros () toma exactamente un argumento", aunque la wiki sugiere lo contrario.Tal vez este comando sea solo para la versión git. (Gracias a eryksun por corregir mi notación, que solucionó el problema con la función de ceros).
SymPy también proporciona un script, isympy, que es un envoltorio para IPython que ejecuta algunos comandos comunes, incluida una importación de división del futuro. Es bastante práctico, y en las versiones más nuevas de IPython (0.11+) también permite la construcción automática de Símbolos (lo cual es bueno como parece que siempre olvido); ejecutarlo con el parámetro -a.
En cuanto a Python 3, hay soporte para él en la versión de desarrollo y la próxima versión lo tendrá; Cuando las distribuciones van a empacar, no lo sé.
Tanto el comando ipython -i
como la run -i
en el intérprete ipython
ignoran from __future__ import division
print05.py
en el script print05.py
.
$ cat print05.py
from __future__ import division
print(1/2)
En la consola ipython
:
In [1]: print 1/2
0
In [2]: run -i print05.py
0.5
In [3]: division
Out[3]: _Feature((2, 2, 0, ''alpha'', 2), (3, 0, 0, ''alpha'', 0), 8192)
In [4]: print 1/2
0
In [5]: from __future__ import division
In [6]: print 1/2
0.5
execfile
e import
producen el mismo resultado:
>>> print 1/2
0
>>> execfile(''print05.py'')
0.5
>>> print 1/2
0
>>> from __future__ import division
>>> print 1/2
0.5
from __future__ import division
no debería tener efecto en el código fuente de diferentes módulos, de lo contrario rompería el código en otros módulos que no esperan su presencia.
Aquí, from __future__ import division
tiene efecto:
$ python -i print05.py
0.5
>>> print 1/2
0.5
>>> division
_Feature((2, 2, 0, ''alpha'', 2), (3, 0, 0, ''alpha'', 0), 8192)
El nombre del módulo en este caso es __main__
tanto dentro de print05.py
como en el indicador.
Aquí, la primera print 1/2
ejecuta en el módulo print05
, la segunda en el módulo __main__
, por lo que también funciona como se esperaba:
$ python -im print05
0.5
>>> print 1/2
0
Y aquí hay algo mal:
$ ipython -i print05.py
0.5
In [1]: division
Out[1]: _Feature((2, 2, 0, ''alpha'', 2), (3, 0, 0, ''alpha'', 0), 8192)
In [2]: print 1/2
0
Los documentos para __future__
dicen:
Si se inicia un intérprete con la opción -i, se le pasa un nombre de script para que se ejecute, y el script incluye una declaración futura, estará vigente en la sesión interactiva iniciada después de que se ejecute el script.
Por lo tanto, podría ser un error en ipython
si su opción -i
intenta emular la misma opción de python.