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)

trac15200.patch (1.2 KB) - added by eviatarbach 6 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 6 years ago by eviatarbach

  • Dependencies set to #12289

comment:2 Changed 6 years ago by eviatarbach

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 the algorithm 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.

Changed 6 years ago by eviatarbach

comment:3 Changed 6 years ago by eviatarbach

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 vbraun_spam

  • Milestone changed from sage-6.1 to sage-6.2

comment:5 Changed 6 years ago by vbraun_spam

  • Milestone changed from sage-6.2 to sage-6.3

comment:6 Changed 5 years ago by vbraun_spam

  • Milestone changed from sage-6.3 to sage-6.4

comment:7 follow-up: Changed 5 years ago by jdemeyer

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 kcrisman

  • Cc kcrisman added

comment:9 Changed 5 years ago by jdemeyer

  • Dependencies changed from #12289 to #17130

comment:10 in reply to: ↑ 7 ; follow-up: Changed 5 years ago by rws

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:

  1. 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/..?
  2. 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 jdemeyer

  • Dependencies #17130 deleted

Replying to rws:

  1. 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.

  1. 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.

Note: See TracTickets for help on using tickets.