2014-06-29 18:18:02 +0100 received badge ● Notable Question (source) 2014-06-29 18:18:02 +0100 received badge ● Famous Question (source) 2014-06-29 18:02:19 +0100 received badge ● Popular Question (source) 2014-06-29 18:02:19 +0100 received badge ● Notable Question (source) 2014-06-29 18:02:19 +0100 received badge ● Famous Question (source) 2013-11-24 12:51:31 +0100 received badge ● Popular Question (source) 2012-01-01 12:28:38 +0100 marked best answer pi and e not evaluated when i use my own classes I don't know why this is happening, but here are some workarounds: one option is to replace self._value(theta_1=item[0],mu_t=item[1],mu_j=item[1])  by self._value(theta_1=item[0],mu_t=item[1],mu_j=item[1], e=e, pi=pi)  A second option: right after the line self._value=self._value(**self.th1_dict)(**self.pre10_dict)(**self.constants).trig_reduce().simplify() #set dictionary values  add the line self._value = self._value(**self.constants)  By the way, you can also replace the "constants" dictionary with  self.constants={ "pi": pi, "e": e }  to give better precision. 2012-01-01 12:28:38 +0100 received badge ● Scholar (source) 2012-01-01 12:28:26 +0100 received badge ● Supporter (source) 2012-01-01 12:28:14 +0100 commented answer pi and e not evaluated when i use my own classes Thanks a million time for this indeed helpfull answer. BTW: that behaviour seems like a bug to me. After adding e=e... in the first of the if loops all the others also work fine. Looks like sage forgets about the constants. Should I try to file a bug here? 2011-12-29 17:18:55 +0100 commented question pi and e not evaluated when i use my own classes The Worksheet now is public at http://www.sagenb.org/home/pub/3912. The calculations failing are in the cell containing ###### 7 ######## and the following cell. Sorry for the dirty hacks in there and thanks in advance ;-) 2011-12-29 17:18:12 +0100 commented question pi and e not evaluated when i use my own classes The big question that remains to me is how to do that after miles of symbolic calculations. I tried using a dictionary and that failes. Copy paste is not a too good solution also since the argument I posted is (by far) the shortest. In that case I'd prefer to copy paste it completely to python, because my calculations are to slow and memory consuming anyway. Second I do not get what the difference of RR(-1/exp(1/10*abs(-0.0555555555556*(pi) - 26714619/51021164)) + 1) and -1/RR(e)^(1/10*abs(-0.0555555555556*RR(pi) - 26714619/51021164)) + 1 should be. 2011-12-22 17:37:56 +0100 commented question Problem with sign / sgn and .n() OK, thanks. This : http://ask.sagemath.org/question/1014/pi-and-e-not-evaluated-when-i-use-my-own-classes might be a related problem. There are also some sage constants that are not evaluated at all. 2011-12-22 16:36:16 +0100 commented question pi and e not evaluated when i use my own classes The problem seems to be related to what is imported. Another version where the object calculating the values are created earlier works fine. I imported matplotlib as plt and numpy as np so no modules of these should be conflicting, right? 2011-12-22 15:38:38 +0100 asked a question pi and e not evaluated when i use my own classes This question might be related to this question: http://ask.sagemath.org/question/966/... I have a symbolic calculation and I do evaluate it numerically. Within one of my classes (within my notebook; no external files) I evaluate this term -1/e^(1/10*abs(-0.0555555555556*pi - 26714619/51021164)) + 1  within a for loop. I am getting the following error: File "", line 1, in File "/tmp/tmpkItECC/___code___.py", line 113, in __temp=MuObject.calcValue((mu_enlacement[i])(**param_dict)) File "/tmp/tmpJuxeqk/___code___.py", line 97, in calcValue self._result[self._k,_sage_const_0 ]=R(self._value(theta_1=item[_sage_const_0 ],mu_t=item[_sage_const_1 ],mu_j=item[_sage_const_1 ])) File "parent.pyx", line 988, in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:7326) File "coerce_maps.pyx", line 156, in sage.structure.coerce_maps.NamedConvertMap._call_ (sage/structure/coerce_maps.c:4235) File "expression.pyx", line 862, in sage.symbolic.expression.Expression._mpfr_ (sage/symbolic/expression.cpp:5117) File "expression.pyx", line 796, in sage.symbolic.expression.Expression._eval_self (sage/symbolic/expression.cpp:4912) TypeError: Cannot evaluate symbolic expression to a numeric value. If I copy paste the expression print (-1/e^(1/10*abs(-0.0555555555556*pi - 26714619/51021164)) + 1).n()  to my notebook it evaluates fine to: 0.0674319647572598  I even tried to replace pi and e using a dictionary but I can't get it working. Any ideas what i am doing wrong? Thanks in advance, Markus P.S.: I can make the notebook public if usefull 2011-12-22 15:28:55 +0100 commented question Problem with sign / sgn and .n() Thanks for the answers. Would you mind explaining me what a SD 35.5. fodder ist? 2011-12-06 15:28:55 +0100 asked a question Problem with sign / sgn and .n() I have an urgent problem with the sign function. I have done a symbolic calculation and want to evaluate the result numerically. The symbolic terms have a sgn() function within, which gives me an error when I try to evaluate the expression numerically. Please find the error below. I do not have the slightest ideas why sage can not evaluate that (simple) expression: sign(1050*cos(61075634/181449129) + 900).n() How can i solve that problem? Thanks a lot in advance, Best Markus Error: Traceback (most recent call last): File "", line 1, in File "_sage_input_60.py", line 10, in exec compile(u'open("___code___.py","w").write("# -*- coding: utf-8 -*-\\n" + ..... execfile(os.path.abspath("___code___.py")) File "", line 1, in File "/tmp/tmp4W3s9l/___code___.py", line 4, in exec compile(u'qwer.n() File "", line 1, in File "expression.pyx", line 4053, in sage.symbolic.expression.Expression._numerical_approx (sage/symbolic/expression.cpp:17894) TypeError: cannot evaluate symbolic expression numerically  edit by kcrisman: Here's a minimal example: sage: M = sgn(cos(3/2)) sage: M.n()  It doesn't suffice to do sgn(cos(1)), because that turns out to be 1.