I wrote the following program in Python 2 to do Newton's method computations for my math problem set, and while it works perfectly, for reasons unbeknownst to me, when I initially load it in ipython with %run -i NewtonsMethodMultivariate.py
, the Python 3 division is not imported. I know this because after I load my Python program, entering x**(3/4)
gives "1". After manually importing the new division, then x**(3/4)
remains x**(3/4)
, as expected. Why is this?
# 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)
I would use Python 3 to avoid this issue, but my Linux distribution only ships SymPy for Python 2. Thanks to the help anyone can provide.
Also, in case anyone was wondering, I haven't yet generalized this script for nxn Jacobians, and only had to deal with 2x2 in my problem set. Additionally, I'm slicing the 2x2 zero matrix instead of using the command (Thanks eryksun for correcting my notation, which fixed the issue with the zeros function.)zeros(2,1)
because SymPy 0.7.1, installed on my machine, complains that "zeros() takes exactly one argument", though the wiki suggests otherwise. Maybe this command is only for the git version.
__future__ module is a built-in module in Python that is used to inherit new features that will be available in the new Python versions.. This module includes all the latest functions which were not present in the previous version in Python. And we can use this by importing the __future__ module.
The future division statement, spelled from __future__ import division , will change the / operator to mean true division throughout the module. A command line option will enable run-time warnings for classic division applied to int or long arguments; another command line option will make true division the default.
from __future__ import absolute_import means that if you import string , Python will always look for a top-level string module, rather than current_package.string . However, it does not affect the logic Python uses to decide what file is the string module.
Both ipython -i
command and run -i
in ipython
interpreter ignore from __future__ import division
in print05.py
script.
$ cat print05.py
from __future__ import division
print(1/2)
In ipython
console:
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
and import
produce the same result:
>>> 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
should not have effect on the source code from different modules, otherwise it would break code in other modules that don't expect its presence.
Here, from __future__ import division
has effect:
$ python -i print05.py
0.5
>>> print 1/2
0.5
>>> division
_Feature((2, 2, 0, 'alpha', 2), (3, 0, 0, 'alpha', 0), 8192)
The module name in this case is __main__
both inside print05.py
and in the prompt.
Here, the first print 1/2
executes in print05
module, the second one in __main__
module so it also works as expected:
$ python -im print05
0.5
>>> print 1/2
0
And here's something wrong:
$ 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
The docs for __future__
say:
If an interpreter is started with the -i option, is passed a script name to execute, and the script includes a future statement, it will be in effect in the interactive session started after the script is executed.
So It might be a bug in ipython
if its -i
option tries to emulate the same python option.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With