Sage: Ticket #9240: applying full_simplify() to gamma functions causes an error
https://trac.sagemath.org/ticket/9240
<p>
Applying full_simplify() to the gamma function sometimes causes an error. This example works:
</p>
<pre class="wiki">sage: gamma(4/3).full_simplify()
1/3*gamma(1/3)
</pre><p>
but this example does not:
</p>
<pre class="wiki">sage: gamma(1/3).full_simplify()
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
The error message is: ('EOF in multi-line statement', (1254, 0))
---------------------------------------------------------------------------
ValueError Traceback (most recent call last)
/Users/tomc/sage-4.4.1/<ipython console> in <module>()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/symbolic/expression.so in sage.symbolic.expression.Expression.simplify_full (sage/symbolic/expression.cpp:21549)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/symbolic/expression.so in sage.symbolic.expression.Expression.simplify_factorial (sage/symbolic/expression.cpp:22240)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/structure/parent.so in sage.structure.parent.Parent.__call__ (sage/structure/parent.c:6332)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/structure/coerce_maps.so in sage.structure.coerce_maps.NamedConvertMap._call_ (sage/structure/coerce_maps.c:4053)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/interfaces/maxima.pyc in _symbolic_(self, R)
1810 sqrt(2)
1811 """
-> 1812 return R(self._sage_())
1813
1814 def __complex__(self):
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/interfaces/maxima.pyc in _sage_(self)
1791 import sage.calculus.calculus as calculus
1792 return calculus.symbolic_expression_from_maxima_string(self.name(),
-> 1793 maxima=self.parent())
1794
1795 def _symbolic_(self, R):
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/calculus/calculus.pyc in symbolic_expression_from_maxima_string(x, equals_sub, maxima)
1524 # evaluation of maxima code are assumed pre-simplified
1525 is_simplified = True
-> 1526 return symbolic_expression_from_string(s, syms, accept_sequence=True)
1527 except SyntaxError:
1528 raise TypeError, "unable to make sense of Maxima expression '%s' in Sage"%s
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/calculus/calculus.pyc in symbolic_expression_from_string(s, syms, accept_sequence)
1692 global _augmented_syms
1693 _augmented_syms = syms
-> 1694 return parse_func(s)
1695 finally:
1696 _augmented_syms = {}
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.parse_sequence (sage/misc/parser.c:3855)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.parse_sequence (sage/misc/parser.c:3747)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.p_sequence (sage/misc/parser.c:4376)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.p_tuple (sage/misc/parser.c:5032)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.p_eqn (sage/misc/parser.c:5145)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.p_expr (sage/misc/parser.c:5465)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.p_term (sage/misc/parser.c:5690)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.p_factor (sage/misc/parser.c:6053)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/misc/parser.so in sage.misc.parser.Parser.p_power (sage/misc/parser.c:6264)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/symbolic/function.so in sage.symbolic.function.GinacFunction.__call__ (sage/symbolic/function.cpp:6321)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/symbolic/expression.so in sage.symbolic.expression.Expression.factorial (sage/symbolic/expression.cpp:20595)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/symbolic/pynac.so in sage.symbolic.pynac.py_factorial (sage/symbolic/pynac.cpp:9156)()
/Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/rings/arith.pyc in factorial(n, algorithm)
403 """
404 if n < 0:
--> 405 raise ValueError, "factorial -- must be nonnegative"
406 if algorithm == 'gmp':
407 return ZZ(n).factorial()
ValueError: factorial -- must be nonnegative
</pre><p>
I am running Sage 4.4.1 on Mac OS X version 10.6 (Snow Leopard), built from source. But the second example also fails on Sage 4.3.5 on 64-bit Linux, built from source. Looking at the source code suggests that the second example will fail on all platforms.
</p>
<p>
The problem occurs because full_simplify() here runs the following commands in Maxima:
</p>
<pre class="wiki">(%i1) minfactorial(factcomb(makefact(gamma(1/3))));
2
(%o1) (- -)!
3
</pre><p>
and then the Maxima interface converts this to Sage as factorial(-2/3). This causes an error. For Sage, factorial(x) is only defined if x is a non-negative integer, whereas for Maxima factorial(x) is equivalent to gamma(1+x) and so makes sense whenever x is not in {-1, -2, -3, ...}
</p>
<p>
Apply: trac_9240_full_simplify_gamma.patch, trac_9240-factorial_evaluation.patch
</p>
en-usSagehttps://trac.sagemath.org/chrome/site/logo_sagemath_trac.png
https://trac.sagemath.org/ticket/9240
Trac 1.1.6tomcTue, 15 Jun 2010 03:49:32 GMTattachment set
https://trac.sagemath.org/ticket/9240
https://trac.sagemath.org/ticket/9240
<ul>
<li><strong>attachment</strong>
set to <em>trac_9240_full_simplify_gamma.patch</em>
</li>
</ul>
<p>
based on Sage 4.4.1
</p>
TicketddrakeTue, 15 Jun 2010 05:32:22 GMT
https://trac.sagemath.org/ticket/9240#comment:1
https://trac.sagemath.org/ticket/9240#comment:1
<p>
The patch applies cleanly to 4.4.4.alpha0, fixes the problem and includes some nice tests. I would give this a positive review, except that I really don't know the Pynac integration code.
</p>
<p>
Oh, and you say "For Sage, factorial(x) is only defined if x is a non-negative integer", but (with a clean 4.4.4.alpha0), it's defined the same way as Maxima:
</p>
<pre class="wiki">sage: factorial(5)
120
sage: factorial(1/2)
1/2*sqrt(pi)
sage: factorial(1/21)
gamma(22/21)
</pre>
TickettomcTue, 15 Jun 2010 14:47:52 GMT
https://trac.sagemath.org/ticket/9240#comment:2
https://trac.sagemath.org/ticket/9240#comment:2
<p>
OK: I had misunderstood the docstring, which says:
</p>
<pre class="wiki">sage: ? factorial
String Form: factorial
Namespace: Interactive
File: /Users/tomc/sage-4.4.1/local/lib/python2.6/site-packages/sage/functions/other.py
Definition: factorial(self, *args, coerce=True, hold=False, dont_call_method_on_arg=False)
Docstring:
Returns the factorial of n.
INPUT:
* ``n`` - an integer, or symbolic expression
...
</pre><p>
I suppose that non-integer numerical values (rational numbers, real numbers, etc) count as symbolic expressions here, as they can be canonically coerced into the symbolic ring. But then there is definitely a bug in factorial(), because [in an unpatched version of Sage]:
</p>
<pre class="wiki">sage: factorial(-1/2)
ERROR: An unexpected error occurred while tokenizing input
...
ValueError: factorial -- must be nonnegative
</pre><p>
The patch fixes this.
</p>
TicketddrakeWed, 16 Jun 2010 01:56:32 GMT
https://trac.sagemath.org/ticket/9240#comment:3
https://trac.sagemath.org/ticket/9240#comment:3
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9240#comment:2" title="Comment 2">tomc</a>:
</p>
<blockquote class="citation">
<p>
OK: I had misunderstood the docstring,
</p>
</blockquote>
<p>
Well, of course you misunderstood the docstring, since it's wrong, or at least misleading. I've opened <a class="closed ticket" href="https://trac.sagemath.org/ticket/9248" title="defect: docstring for factorial doesn't say that it accepts non-integer, ... (closed: fixed)">#9248</a> to fix the docstring for factorial().
</p>
TicketkcrismanThu, 02 Dec 2010 02:26:19 GMTcc set
https://trac.sagemath.org/ticket/9240#comment:4
https://trac.sagemath.org/ticket/9240#comment:4
<ul>
<li><strong>cc</strong>
<em>kcrisman</em> added
</li>
</ul>
<p>
See also <a class="ext-link" href="http://trac.sagemath.org/sage_trac/ticket/9240"><span class="icon"></span>this thread</a>, where it came up again.
</p>
TicketburcinTue, 10 May 2011 19:13:31 GMTstatus, milestone changed
https://trac.sagemath.org/ticket/9240#comment:5
https://trac.sagemath.org/ticket/9240#comment:5
<ul>
<li><strong>status</strong>
changed from <em>new</em> to <em>needs_review</em>
</li>
<li><strong>milestone</strong>
changed from <em>sage-4.7</em> to <em>sage-4.7.1</em>
</li>
</ul>
<p>
I suppose this needs review.
</p>
TicketddrakeWed, 11 May 2011 00:12:46 GMT
https://trac.sagemath.org/ticket/9240#comment:6
https://trac.sagemath.org/ticket/9240#comment:6
<p>
For some reason, the patchbot isn't applying this patch, but it does apply cleanly and pass doctests in 4.7.rc1. (On 64-bit Ubuntu 10.10)
</p>
<p>
Looking at it again, I might recommend that in the TESTS, the first few examples be moved, since they already work and aren't testing to see if the problem in this ticket has been fixed. Only the <code>full_simplify()</code> tests are, strictly speaking, relevant to this ticket.
</p>
TicketkcrismanWed, 11 May 2011 00:29:15 GMTreviewer, author set
https://trac.sagemath.org/ticket/9240#comment:7
https://trac.sagemath.org/ticket/9240#comment:7
<ul>
<li><strong>reviewer</strong>
set to <em>Dan Drake</em>
</li>
<li><strong>author</strong>
set to <em>Tom Coates</em>
</li>
</ul>
<p>
That's a good point, Dan. It's not bad to add them, but they should be added to the doc for gamma. A friendly reviewer patch from ddrake would probably be sufficient for this :)
</p>
TicketburcinTue, 24 May 2011 19:01:20 GMTattachment set
https://trac.sagemath.org/ticket/9240
https://trac.sagemath.org/ticket/9240
<ul>
<li><strong>attachment</strong>
set to <em>trac_9240-factorial_evaluation.patch</em>
</li>
</ul>
<p>
apply after trac_9240_full_simplify_gamma.patch
</p>
TicketburcinTue, 24 May 2011 19:20:03 GMTdescription, author changed
https://trac.sagemath.org/ticket/9240#comment:8
https://trac.sagemath.org/ticket/9240#comment:8
<ul>
<li><strong>description</strong>
modified (<a href="/ticket/9240?action=diff&version=8">diff</a>)
</li>
<li><strong>author</strong>
changed from <em>Tom Coates</em> to <em>Tom Coates, Burcin Erocal</em>
</li>
</ul>
<p>
<a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9240/trac_9240-factorial_evaluation.patch" title="Attachment 'trac_9240-factorial_evaluation.patch' in Ticket #9240">attachment:trac_9240-factorial_evaluation.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9240/trac_9240-factorial_evaluation.patch" title="Download"></a> adds further doctests and fixes for the evaluation of factorials. It should be applied after <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9240/trac_9240_full_simplify_gamma.patch" title="Attachment 'trac_9240_full_simplify_gamma.patch' in Ticket #9240">attachment:trac_9240_full_simplify_gamma.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9240/trac_9240_full_simplify_gamma.patch" title="Download"></a>.
</p>
<p>
My changes depend on a small patch to pynac, where I somehow used && instead of bitwise and. This patch can be obtained from:
</p>
<p>
<a class="ext-link" href="https://bitbucket.org/burcin/pynac-patches/src/c3c5b3b8b1eb/bitwise.patch"><span class="icon"></span>https://bitbucket.org/burcin/pynac-patches/src/c3c5b3b8b1eb/bitwise.patch</a>
</p>
<p>
This ticket now depends on a new pynac release, which should be coming soon.
</p>
TicketburcinTue, 31 May 2011 15:16:01 GMTdependencies set
https://trac.sagemath.org/ticket/9240#comment:9
https://trac.sagemath.org/ticket/9240#comment:9
<ul>
<li><strong>dependencies</strong>
set to <em>#11415</em>
</li>
</ul>
<p>
Pynac package with the changes required by <a class="attachment" href="https://trac.sagemath.org/attachment/ticket/9240/trac_9240-factorial_evaluation.patch" title="Attachment 'trac_9240-factorial_evaluation.patch' in Ticket #9240">attachment:trac_9240-factorial_evaluation.patch</a><a class="trac-rawlink" href="https://trac.sagemath.org/raw-attachment/ticket/9240/trac_9240-factorial_evaluation.patch" title="Download"></a> is at <a class="closed ticket" href="https://trac.sagemath.org/ticket/11415" title="defect: update pynac to 0.2.3 (closed: fixed)">#11415</a>.
</p>
TicketkcrismanWed, 08 Jun 2011 22:01:31 GMTreviewer changed
https://trac.sagemath.org/ticket/9240#comment:10
https://trac.sagemath.org/ticket/9240#comment:10
<ul>
<li><strong>reviewer</strong>
changed from <em>Dan Drake</em> to <em>Dan Drake, Karl-Dieter Crisman</em>
</li>
</ul>
<p>
Can you explain why the change from && to & was necessary? I don't know much CPP. Would there be a difference between bitwise 'and' and 'and' when the outputs are boolean? Or maybe they are not boolean.
</p>
<p>
Thanks!
</p>
TicketfbisseyThu, 09 Jun 2011 01:04:32 GMT
https://trac.sagemath.org/ticket/9240#comment:11
https://trac.sagemath.org/ticket/9240#comment:11
<p>
Well I am not sure because I don't know the code well. But python_func is an unsigned and used to be a boolean according to comment in the code.
What I think happens here is the code tries to match a precise type of python_func.
0 is just a c++ function but different from 0 it is a python construct and it can take different value depending on the construct. So if I am not mistaken it is bitwise because we are trying to match the construct code. This can be seen in the follwing snippet from function.cpp
</p>
<pre class="wiki">function_options& function_options::eval_func(PyObject* e)
{
python_func |= eval_python_f;
eval_f = eval_funcp(e);
return *this;
}
function_options& function_options::evalf_func(PyObject* ef)
{
python_func |= evalf_python_f;
evalf_f = evalf_funcp(ef);
return *this;
}
function_options& function_options::conjugate_func(PyObject* c)
{
python_func |= conjugate_python_f;
conjugate_f = conjugate_funcp(c);
return *this;
}
function_options& function_options::real_part_func(PyObject* c)
{
python_func |= real_part_python_f;
real_part_f = real_part_funcp(c);
return *this;
}
function_options& function_options::imag_part_func(PyObject* c)
{
python_func |= imag_part_python_f;
imag_part_f = imag_part_funcp(c);
return *this;
}
function_options& function_options::derivative_func(PyObject* d)
{
python_func |= derivative_python_f;
derivative_f = derivative_funcp(d);
return *this;
}
function_options& function_options::power_func(PyObject* d)
{
python_func |= power_python_f;
power_f = power_funcp(d);
return *this;
}
function_options& function_options::series_func(PyObject* s)
{
python_func |= series_python_f;
series_f = series_funcp(s);
return *this;
}
</pre><p>
Notice how they match the bitwise comparison later in the patched code?
</p>
TicketkcrismanThu, 09 Jun 2011 01:39:52 GMTreviewer changed
https://trac.sagemath.org/ticket/9240#comment:12
https://trac.sagemath.org/ticket/9240#comment:12
<ul>
<li><strong>reviewer</strong>
changed from <em>Dan Drake, Karl-Dieter Crisman</em> to <em>Dan Drake, Karl-Dieter Crisman, François Bissey</em>
</li>
</ul>
<p>
Thanks, I think that helps a <em>little</em>. I also found
</p>
<pre class="wiki"> cdef _register_function(self):
# We don't need to add anything to GiNaC's function registry
# However, if any custom methods were provided in the python class,
# we should set the properties of the function_options object
# corresponding to this function
cdef GFunctionOpt opt = g_registered_functions().index(self._serial)
if hasattr(self, '_eval_'):
opt.eval_func(self)
</pre><p>
which I knew about before.
</p>
<p>
I am going to have to write down <strong>exactly</strong> how all this works at Sage Days 31, because I do not want to be rediscovering this from scratch every time like I am now.
</p>
<hr />
<p>
I have some more questions, presumably for Burcin. I don't think they are big deals, but I don't feel comfortable giving positive review without knowing them. Someone else who knows more might!
</p>
<ul><li>why the change from the 'billions of digits' error message to the symbolic answer? This seems like a big change - someone might rely on that type of entry failing in number theory. Note that the multifactorial still has the 'billions of digits' error message, incidentally.
</li><li>what would the problem be if Ginac got symbolic answers back, if it didn't have anything for those before? (Not criticizing, just not understanding. I don't have a problem with them being numeric for ints and floats and longs.)
</li><li>Why did you remove <code>opt.set_python_func() </code>? I assume this has something to do with fbissey's comment.
</li><li>Does <code> return None </code> just mean that Ginac will not try to evaluate things like <code>factorial(sqrt(2))</code> internally?
</li></ul><hr />
<p>
Status:
</p>
<ul><li>Positive review on Tom's patch, from Dan Drake.
</li><li>The log gamma stuff is fine.
</li><li>Apparently Francois is happy with the && to & switch. This is beyond me, though I don't see any problems with it.
</li><li>The actual changes to and new factorial and gamma functions are fine.
</li><li>Need answer to questions, or someone else to review those pieces in lieu of that.
</li><li>Finally, the big question - WHY this change? I can't find a single doctest that tells me what broke with Tom's patch but without Burcin's patch. I feel there must be some very subtle Maxima output that could have come out incorrect, but I cannot find it. All these doctests should have worked before (or were cdef functions so they couldn't be doctested).
</li></ul>
TicketburcinThu, 09 Jun 2011 10:50:44 GMT
https://trac.sagemath.org/ticket/9240#comment:13
https://trac.sagemath.org/ticket/9240#comment:13
<p>
Replying to <a class="ticket" href="https://trac.sagemath.org/ticket/9240#comment:12" title="Comment 12">kcrisman</a>:
</p>
<blockquote class="citation">
<p>
Thanks, I think that helps a <em>little</em>. I also found
</p>
<pre class="wiki"> cdef _register_function(self):
# We don't need to add anything to GiNaC's function registry
# However, if any custom methods were provided in the python class,
# we should set the properties of the function_options object
# corresponding to this function
cdef GFunctionOpt opt = g_registered_functions().index(self._serial)
if hasattr(self, '_eval_'):
opt.eval_func(self)
</pre><p>
which I knew about before.
</p>
</blockquote>
<p>
Francois is right. The <code>python_func</code> variable is a bitset, indexed by the values here:
</p>
<p>
<a class="ext-link" href="https://bitbucket.org/burcin/pynac/src/687b580c8c7c/ginac/function.h#cl-240"><span class="icon"></span>https://bitbucket.org/burcin/pynac/src/687b580c8c7c/ginac/function.h#cl-240</a>
</p>
<p>
If the corresponding bit is on, then we call a python function.
</p>
<p>
When I first implemented this, defining custom evaluation etc. methods in Python was an all or nothing matter. Then I realized that overriding some of these methods and using the others defined in C++ made sense. I switched to the bitset at that point. As the change with <code>&</code> and <code>&&</code> shows, that switch wasn't very successful.
</p>
<blockquote class="citation">
<p>
I am going to have to write down <strong>exactly</strong> how all this works at Sage Days 31, because I do not want to be rediscovering this from scratch every time like I am now.
</p>
</blockquote>
<p>
Maybe we can add some documentation to the reference manual about the general design of symbolics and in particular how the functions work.
</p>
<hr />
<blockquote class="citation">
<p>
I have some more questions, presumably for Burcin. I don't think they are big deals, but I don't feel comfortable giving positive review without knowing them. Someone else who knows more might!
</p>
<ul><li>why the change from the 'billions of digits' error message to the symbolic answer? This seems like a big change - someone might rely on that type of entry failing in number theory. Note that the multifactorial still has the 'billions of digits' error message, incidentally.
</li></ul></blockquote>
<p>
The number theory people should use the functions from <code>sage.rings.arith</code>. In general, it's a bad idea to use the symbolics functions in library code unless you know what you're doing.
</p>
<p>
Suppose you have the expression <code>factorial(big_number+1)/factorial(big_number)</code>. This would simplify to <code>big_number</code>. Telling people that they can't possibly work with numbers that big defeats the purpose of <em>symbolic computation</em>.
</p>
<blockquote class="citation">
<ul><li>what would the problem be if Ginac got symbolic answers back, if it didn't have anything for those before? (Not criticizing, just not understanding. I don't have a problem with them being numeric for ints and floats and longs.)
</li></ul></blockquote>
<p>
We get problems like <a class="closed ticket" href="https://trac.sagemath.org/ticket/9913" title="defect: n() returns symbolic expression (closed: fixed)">#9913</a>. I was being cautious.
</p>
<blockquote class="citation">
<ul><li>Why did you remove <code>opt.set_python_func() </code>? I assume this has something to do with fbissey's comment.
</li><li>Does <code> return None </code> just mean that Ginac will not try to evaluate things like <code>factorial(sqrt(2))</code> internally?
</li></ul></blockquote>
<p>
Yes. It's quite likely that this is not documented anywhere. :)
</p>
<hr />
<blockquote class="citation">
<p>
Status:
</p>
<ul><li>Positive review on Tom's patch, from Dan Drake.
</li><li>The log gamma stuff is fine.
</li><li>Apparently Francois is happy with the && to & switch. This is beyond me, though I don't see any problems with it.
</li><li>The actual changes to and new factorial and gamma functions are fine.
</li><li>Need answer to questions, or someone else to review those pieces in lieu of that.
</li><li>Finally, the big question - WHY this change? I can't find a single doctest that tells me what broke with Tom's patch but without Burcin's patch. I feel there must be some very subtle Maxima output that could have come out incorrect, but I cannot find it. All these doctests should have worked before (or were cdef functions so they couldn't be doctested).
</li></ul></blockquote>
<p>
Tom's patch was great, it fixed the problem at hand. But when I first looked at it, I thought it needed more tests. Sitting down to write the tests, I found all kinds of problems, like the bitwise <code>&</code> issue and the big factorials raising an error. So I fixed those as well. Perhaps it was a mistake to tag these changes on this ticket, but here we are now.
</p>
TicketkcrismanThu, 09 Jun 2011 12:50:52 GMTstatus changed
https://trac.sagemath.org/ticket/9240#comment:14
https://trac.sagemath.org/ticket/9240#comment:14
<ul>
<li><strong>status</strong>
changed from <em>needs_review</em> to <em>positive_review</em>
</li>
</ul>
<blockquote class="citation">
<p>
Francois is right. The <code>python_func</code> variable is a bitset, indexed by the values here:
</p>
<p>
<a class="ext-link" href="https://bitbucket.org/burcin/pynac/src/687b580c8c7c/ginac/function.h#cl-240"><span class="icon"></span>https://bitbucket.org/burcin/pynac/src/687b580c8c7c/ginac/function.h#cl-240</a>
</p>
<p>
If the corresponding bit is on, then we call a python function.
</p>
</blockquote>
<p>
Okay, I finally understand what is going on here. I couldn't implement it myself, but it's just a <a class="ext-link" href="http://www.cplusplus.com/reference/stl/bitset/"><span class="icon"></span>really space-saving way</a> to keep track of booleans like this. So it's just the way we tell Ginac that a custom <code>_eval_</code> method or whatever has been defined. Good.
</p>
<blockquote class="citation">
<blockquote class="citation">
<p>
I am going to have to write down <strong>exactly</strong> how all this works at Sage Days 31, because I do not want to be rediscovering this from scratch every time like I am now.
</p>
</blockquote>
<p>
Maybe we can add some documentation to the reference manual about the general design of symbolics and in particular how the functions work.
</p>
</blockquote>
<p>
Absolutely - witness for instance <a class="closed ticket" href="https://trac.sagemath.org/ticket/11143" title="defect: define symbolic functions for exponential integrals (closed: fixed)">#11143</a> where a new-ish developer has been stymied by this, though hopefully I was able to explain at least some of it to him.
</p>
<blockquote class="citation">
<p>
The number theory people should use the functions from <code>sage.rings.arith</code>. In general, it's a bad idea to use the symbolics functions in library code unless you know what you're doing.
</p>
</blockquote>
<p>
Yes, I agree, but sometimes the order of imports makes it hard to know which one is top-level.
</p>
<blockquote class="citation">
<p>
Suppose you have the expression <code>factorial(big_number+1)/factorial(big_number)</code>. This would simplify to <code>big_number</code>. Telling people that they can't possibly work with numbers that big defeats the purpose of <em>symbolic computation</em>.
</p>
</blockquote>
<p>
Good point!
</p>
<blockquote class="citation">
<p>
Yes. It's quite likely that this is not documented anywhere. :)
</p>
</blockquote>
<p>
A good project as well.
</p>
<blockquote class="citation">
<blockquote class="citation">
<ul><li>Finally, the big question - WHY this change? I can't find a single doctest that tells me what broke with Tom's patch but
</li></ul></blockquote>
</blockquote>
<p>
So you are saying this was just an overhaul, but there is no specific error we know of that the rest fixed, it was just needed.
</p>
<p>
Good enough for me! Positive review. Long doctests finished passing late last night :)
</p>
TicketjdemeyerTue, 14 Jun 2011 19:20:21 GMTstatus changed; resolution, merged set
https://trac.sagemath.org/ticket/9240#comment:15
https://trac.sagemath.org/ticket/9240#comment:15
<ul>
<li><strong>status</strong>
changed from <em>positive_review</em> to <em>closed</em>
</li>
<li><strong>resolution</strong>
set to <em>fixed</em>
</li>
<li><strong>merged</strong>
set to <em>sage-4.7.1.alpha4</em>
</li>
</ul>
Ticket