1 | initial version |
You have two different beasts here:
The Python function sum
, that returns the sum of a list (or other sequence, IRC :
sage: z=[var("z_{}".format(u)) for u in (1..5)];z
[z_1, z_2, z_3, z_4, z_5]
sage: sum(z)
z_1 + z_2 + z_3 + z_4 + z_5
The Sage function sum
, that returns the summation of a symbolic function of a symbolic variable taking integer values varying between the bounds:
sage: var("j")
j
sage: y=function("y")(j)
sage: sum(y(j),j,1,5)
y(5) + y(4) + y(3) + y(2) + y(1)
But the first one has a list
argument, whereas the second has four arguments belonging in SR. And, no, you can't mix n' match:
sage: sum(z[j],j,2,3)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-24-8e9069a4812d> in <module>()
----> 1 sum(z[j],j,Integer(2),Integer(3))
/usr/local/sage-8/local/lib/python2.7/site-packages/sage/symbolic/expression.pyx in sage.symbolic.expression.Expression.__index__ (build/cythonized/sage/symbolic/expression.cpp:32735)()
5753 [0, 1, 2, 3, 4]
5754 """
-> 5755 return int(self._integer_())
5756
5757 def iterator(self):
/usr/local/sage-8/local/lib/python2.7/site-packages/sage/symbolic/expression.pyx in sage.symbolic.expression.Expression._integer_ (build/cythonized/sage/symbolic/expression.cpp:8663)()
1085 n = self.pyobject()
1086 except TypeError:
-> 1087 raise TypeError("unable to convert %r to an integer" % self)
1088 if isinstance(n, sage.rings.integer.Integer):
1089 return n
TypeError: unable to convert j to an integer
What happens is that, whereas z[1]
is a legal Python expression (whose value is z_2
, a Symbolic Expression) because it designates a Python list indexed by something that has an integer value, z[j]
is illegal : you can't index a Python list by a Symbolic Expression. Since Python evaluates all the arguments of a function call before evaluating the function call itself, it has no way to "know" that j
will eventually be assigned an integer value. Therefore, it barfs.
[ The lack of any kind of "special forms", "macroes" or "lazy evaluation" in Python is, IMNSHO, one of the major design weaknesses of Python. It turns out that it may well be one of its major strengths, according to some... Not being a computer scientist, I'll refrain from commenting further. I'll just user Lisp (or R) (or even C) when I'll need such a construct ]
HTH,
2 | No.2 Revision |
You have two different beasts here:
The Python function sum
, that returns the sum of a list (or other sequence, IRC :
sage: z=[var("z_{}".format(u)) for u in (1..5)];z
[z_1, z_2, z_3, z_4, z_5]
sage: sum(z)
z_1 + z_2 + z_3 + z_4 + z_5
The Sage function sum
, that returns the summation of a symbolic function of a symbolic variable taking integer values varying between the bounds:
sage: var("j")
j
sage: y=function("y")(j)
sage: sum(y(j),j,1,5)
y(5) + y(4) + y(3) + y(2) + y(1)
But the first one has a list
argument, whereas the second has four arguments belonging in SR. And, no, you can't mix n' match:
sage: sum(z[j],j,2,3)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-24-8e9069a4812d> in <module>()
----> 1 sum(z[j],j,Integer(2),Integer(3))
/usr/local/sage-8/local/lib/python2.7/site-packages/sage/symbolic/expression.pyx in sage.symbolic.expression.Expression.__index__ (build/cythonized/sage/symbolic/expression.cpp:32735)()
5753 [0, 1, 2, 3, 4]
5754 """
-> 5755 return int(self._integer_())
5756
5757 def iterator(self):
/usr/local/sage-8/local/lib/python2.7/site-packages/sage/symbolic/expression.pyx in sage.symbolic.expression.Expression._integer_ (build/cythonized/sage/symbolic/expression.cpp:8663)()
1085 n = self.pyobject()
1086 except TypeError:
-> 1087 raise TypeError("unable to convert %r to an integer" % self)
1088 if isinstance(n, sage.rings.integer.Integer):
1089 return n
TypeError: unable to convert j to an integer
What happens is that, whereas z[1]
is a legal Python expression (whose value is z_2
, a Symbolic Expression) because it designates a Python list indexed by something that has an integer value, z[j]
is illegal : you can't index a Python list by a Symbolic Expression. Since Python evaluates all the arguments of a function call before evaluating the function call itself, it has no way to "know" that j
will eventually be assigned an integer value. Therefore, it barfs.
[ The lack of any kind of "special forms", "macroes" or "lazy evaluation" in Python is, IMNSHO, one of the major design weaknesses of Python. It turns out that it may well be one of its major strengths, according to some... Not being a computer scientist, I'll refrain from commenting further. I'll just user Lisp (or R) (or even C) when I'll need such a construct construct.. ]
[ Note also that the evaluation of the arguments before the function call allows for choosing between the built-in Python function and the Sage function based on the type of the arguments... ]
HTH,