#2516: generalized hypergeometric functions should be implemented
-------------------------------------+-------------------------------------
Reporter: ddrake | Owner: cwitty
Type: enhancement | Status: needs_review
Priority: major | Milestone: sage-6.2
Component: symbolics | Resolution:
Keywords: hypergeometric | Merged in:
Authors: Fredrik | Reviewers: Ralf Stephan
Johansson, Eviatar Bach, Ralf | Work issues:
Stephan | Commit:
Report Upstream: N/A | bc1d66efab841c4670bc9e07f6b5c0e4a580e0dd
Branch: | Stopgaps:
u/nbruin/ticket/2516 |
Dependencies: |
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:43 rws]:
> Alternatively this seems to work too:
> {{{
> + if isinstance(type(h),sage.structure.dynamic_class.DynamicMetaclass)
> + return "{%r}" % fn
> }}}
> Wouldn't one of these be safe enough?
I think the distinction should be easier to make. I don't think `__name__`
is reasonable on any expression. Compare:
{{{
sage: h = hypergeometric([], [], x)
sage: s = sin(x)
sage: from sage.ext.fast_callable import ExpressionTreeBuilder
sage: etb = ExpressionTreeBuilder(vars=['x'])
sage: v = h._fast_callable_(etb)
sage: w = s._fast_callable_(etb)
sage: type(v.function())
<class 'sage.functions.hypergeometric.Expression_with_dynamic_methods'>
sage: type(w.function())
<class 'sage.functions.trig.Function_sin'>
}}}
As you can see, with more traditional functions, there's a rather more
dedicated object in the function slot, for which the `__name__` can be
expected to be quite descriptive. For an expression, the `__name__`
attribute, if there's something there at all (and that there is seems a
side-effect of the dynamic classes. Normally, `__name__` doesn't descend
to class instances), can't really be descriptive. Looking at how to tell
them apart:
{{{
sage: type(v.function()).mro()
[sage.functions.hypergeometric.Expression_with_dynamic_methods,
sage.symbolic.expression.Expression,
sage.structure.element.CommutativeRingElement,
sage.structure.element.RingElement,
sage.structure.element.ModuleElement,
sage.structure.element.Element,
sage.structure.sage_object.SageObject,
object]
sage: type(w.function()).mro()
[sage.functions.trig.Function_sin,
sage.symbolic.function.GinacFunction,
sage.symbolic.function.BuiltinFunction,
sage.symbolic.function.Function,
sage.structure.sage_object.SageObject,
object]
}}}
So my guess is that you only need `isinstance(type(h),
sage.symbolic.expression.Expression)`, no need to check for substrings. On
the other hand, your `sage.structure.dynamic_class.DynamicMetaclass` seems
to work too, even though that class doesn't show up in the mro!
I think we're running into a break-down of ducktyping here: the code as
written previously assumed that if a `__name__` attribute is present, then
it's meaningful. This is apparently not true for some dynamic classes and
makes me think that maybe this `__name__` attribute shouldn't be provided
(wherever that happens).
--
Ticket URL: <http://trac.sagemath.org/ticket/2516#comment:44>
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
