#9240: applying full_simplify() to gamma functions causes an error
---------------------------------------------------------------+------------
Reporter: tomc |
Owner: tomc
Type: defect |
Status: positive_review
Priority: major |
Milestone: sage-4.7.1
Component: symbolics |
Keywords: gamma function, full_simplify, factorial
Work_issues: |
Upstream: N/A
Reviewer: Dan Drake, Karl-Dieter Crisman, François Bissey |
Author: Tom Coates, Burcin Erocal
Merged: |
Dependencies: #11415
---------------------------------------------------------------+------------
Changes (by kcrisman):
* status: needs_review => positive_review
Comment:
> Francois is right. The `python_func` variable is a bitset, indexed by
the values here:
>
>
https://bitbucket.org/burcin/pynac/src/687b580c8c7c/ginac/function.h#cl-240
>
> If the corresponding bit is on, then we call a python function.
Okay, I finally understand what is going on here. I couldn't implement it
myself, but it's just a [http://www.cplusplus.com/reference/stl/bitset/
really space-saving way] to keep track of booleans like this. So it's
just the way we tell Ginac that a custom `_eval_` method or whatever has
been defined. Good.
> > I am going to have to write down '''exactly''' 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.
>
> Maybe we can add some documentation to the reference manual about the
general design of symbolics and in particular how the functions work.
Absolutely - witness for instance #11143 where a new-ish developer has
been stymied by this, though hopefully I was able to explain at least some
of it to him.
> The number theory people should use the functions from
`sage.rings.arith`. In general, it's a bad idea to use the symbolics
functions in library code unless you know what you're doing.
Yes, I agree, but sometimes the order of imports makes it hard to know
which one is top-level.
> Suppose you have the expression
`factorial(big_number+1)/factorial(big_number)`. This would simplify to
`big_number`. Telling people that they can't possibly work with numbers
that big defeats the purpose of ''symbolic computation''.
Good point!
> Yes. It's quite likely that this is not documented anywhere. :)
A good project as well.
> > * Finally, the big question - WHY this change? I can't find a single
doctest that tells me what broke with Tom's patch but
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.
Good enough for me! Positive review. Long doctests finished passing late
last night :)
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9240#comment:14>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
