Opened 6 years ago
Last modified 5 years ago
#15200 new enhancement
_evalf_ handling of backends
Reported by: | eviatarbach | Owned by: | |
---|---|---|---|
Priority: | major | Milestone: | sage-6.4 |
Component: | symbolics | Keywords: | |
Cc: | burcin, kcrisman | Merged in: | |
Authors: | Reviewers: | ||
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description
As per Burcin, with the option of the algorithm
keyword for _evalf_
in #12289,
ATM, if you implement different backends, you need to write a lot of boilerplate code in _evalf_() to parse the algorithm argument, do the right thing if it is not given etc. Can we have a default _evalf_ method, which dispatches to _evalf_<system>_ methods if they exist and raise error if not? Perhaps we can also figure out how to annotate these methods to indicate if they support arbitrary precision evaluation or not.
Attachments (1)
Change History (12)
comment:1 Changed 6 years ago by
- Dependencies set to #12289
comment:2 Changed 6 years ago by
Changed 6 years ago by
comment:3 Changed 6 years ago by
This patch works for BuiltinFunction
. Unfortunately it breaks GinacFunction
(since they often don't define an _evalf_
method, they don't overwrite the _evalf_
in the base class) and gives an error as in #14743 on startup:
Exception AttributeError: "'builtin_function_or_method' object has no attribute 'func_code'" in 'sage.symbolic.function.SymbolicFunction._hash_' ignored
comment:4 Changed 6 years ago by
- Milestone changed from sage-6.1 to sage-6.2
comment:5 Changed 6 years ago by
- Milestone changed from sage-6.2 to sage-6.3
comment:6 Changed 5 years ago by
- Milestone changed from sage-6.3 to sage-6.4
comment:7 follow-up: ↓ 10 Changed 5 years ago by
I think the best solution would be to hardcode a set of common algorithm/parent choices like:
def _evalf_(self, *args, parent=None, algorithm=None): if hasattr(self, '_evalf_scipy_') and (some_condition_on_parent_and_algorithm): return parent(self._evalf_scipy_(*args)) if hasattr(self, '_evalf_mpmath_') and (some_condition_on_parent_and_algorithm): return parent(self._evalf_mpmath_(*args)) [...] return self._evalf_default_(*args, parent=parent, algorithm=algorithm)
comment:8 Changed 5 years ago by
- Cc kcrisman added
comment:9 Changed 5 years ago by
- Dependencies changed from #12289 to #17130
comment:10 in reply to: ↑ 7 ; follow-up: ↓ 11 Changed 5 years ago by
I had a look at Eviatar's patch and got some ideas. First,
Replying to jdemeyer:
I think the best solution would be to hardcode a set of common algorithm/parent choices like:
@Jeroen:
- Does this mean you would find any mechanism doing recognition of implemented algorithms or call dispatch that exists apart from your hardcoded solution dangerous/superfluous/..?
- What is your opinion regarding such a mechanism dealing with
eval
(i.e., non-fp) algorithms? This concerns #17489, with possible implementation in #17531. (This may be fast in__call__
, with only a dictionary lookup.)
comment:11 in reply to: ↑ 10 Changed 5 years ago by
- Dependencies #17130 deleted
Replying to rws:
- Does this mean you would find any mechanism doing recognition of implemented algorithms or call dispatch that exists apart from your hardcoded solution dangerous/superfluous/..?
No, but I think the generic solution should work for most functions.
- What is your opinion regarding such a mechanism dealing with
eval
(i.e., non-fp) algorithms?
I would propose to use this only for _evalf_
but possibly extend _evalf_
to non-fp arguments. See also the discussion about NumberTheoreticFunction
(whatever the name) in #17489.
I think "the right thing if it is not given" is resort to a method
_evalf_default_
. In cases where_evalf_
has already been defined, overwriting the_evalf_
which this patch would define, this will not change anything. The only problem is that for most functions thealgorithm
keyword won't do anything. I can't think of any good solution to this (such as raising a warning or error) that wouldn't involve modifying all the existing symbolic functions.